Any system upgrade has a quantitative change to a qualitative transition: when the version is small, it is usually very simple, the version is a big difference, is a nightmare. But when the version is small, we tend to be complacent. This article actually records from GP4.2.7.2 to 4.3.5.0 upgrade process, from the version number see little difference, but the GP version of the name, the second change is already a big upgrade. Another thing to note is that the upgrade of the GP database size is not small, more users, management chaos, plus GP is a bit fragile (compared to Oracle, etc.), so encountered a lot of metadata problems (please participate in the first 4).
Starting point
- Database version: Greenplum database 4.2.7.2 build 1 (PostgreSQL 8.2.15)
- Custom functions: $GPHOME/lib have Oracle custom functions compiled with uuid-1.6.2.tar.gz
- No append-only tables.
- ETL in the use of external tables
- No extensions is used, but Pljava and PLR are installed, not installed Madlib
- Graphical management Interface version: Greenplum Command Center 1.2.0.1 Build 2
- There are standby master, there are mirror
Goal
- Database version: Greenplum database 4.3.5.0 build 1 (PostgreSQL 8.2.15)
- Graphical management Interface version: Greenplum Command Center 1.3.0.0 Build 91
Preparing the Media
- GP Database server: Greenplum-db-4.3.5.0-build-1-rhel5-x86_64.zip
- GP Management graphical Interface: Greenplum-cc-web-1.3.0.0-build-91-rhel5-x86_64.zip
- ETL needs Gpfdist Toolkit: greenplum-connectivity-4.3.5.0-build-1-winxp-x86_32. MSI and Greenplum-loaders-4.3.5.0-build-1-winxp-x86_32.msi
- R Language Extension Pack: plr-ossv8.3.0.15_pv2.1_gpdb4.3orca-rhel5-x86_64.gppkg
- Java language Extension Pack: pljava-ossv1.4.0_pv1.2_gpdb4.3orca-rhel5-x86_64.gppkg
- Madlib Expansion pack: Madlib-ossv1.7.1_pv1.9.3_gpdb4.3orca-rhel5-x86_64.tar
- Script to estimate upgrade time: Estimate_42_to_43_migrate_time.zip
- Source code and compile release steps for Oracle Compatibility Pack: uuid-1.6.2.tar.gz
Time Estimate
Log in to master node, upload and unzip estimate_42_to_43_migrate_time.zip, get estimate_42_to_43_migrate_time.sql, switch to gpadmin user
$ psql-d databasename-f estimate_42_to_43_migrate_time.sql$ psql-d databasename-c"Select Estimate_42_to_43_migrate_time ();"WARNING:"Work_mem": Setting isDeprecated andMay be removedinchA future release. Estimate_42_to_43_migrate_time----------------------------------------------------------------------------------------------------------- ---------------------------------------------------------Estimate_42_to_43_migrate_time ()version:0.3 Run at -- to- - -: the: -Gpdbversion: PostgreSQL8.2. the(Greenplum Database4.2. 7. 2Build1) onX86_64-unknown-linux-gnu, compiled byGCC gcc (GCC)4.4. 2Compiled onFeb - the -: to:GenevaDatabase:databasename number ofPrimary segments: theNum ofAO objects:0Num ofHeap objects:102593Estimated Migrate Time: on: -: -(7Rows
If you have multiple databases, you need to run the above script for each data, plus the time.
File backup
Notifies all database users to back up files that they copy to the server
Data consistency check
This check is very important, although the official document is written in the recommendation, but as long as there are errors, basically can not upgrade, must find a way to solve. The official document written "A few weeks" before the recommendation to perform this operation, it is necessary that the GP library to a certain level, the error is almost inevitable, to resolve these errors is really to spend the time of week.
- Use GP Admin user Login Master
- Restart data to restricted mode
$ gpstop -M fast$ gpstart -R
- Perform a database consistency check, if you do find errors, Gpcheckcat will generate error correction script, with the database user to confirm the content after the script error correction, and then repeat the check, if there is no error-correcting script generated, you can only rely on yourself, if you are lucky, your error may be in my list of several errors. Resolve and check repeatedly until no errors occur
- "How to Solve Greenplum's gpcheckcat about persistent's mistakes"
- "How to troubleshoot metadata errors that cannot be repaired by standard commands in Greenplum"
- "How to solve Greenplum master node and SEG node metadata inconsistency"
$ $GPHOME/bin/lib/gpcheckcat 5432
- Use GP Admin user Login master, perform gpstate check seg node status, if failed seg, perform gprecoverseg and gprecoverseg-r repair
Greenplum Database Upgrade Practice (top)