Overview
Greenplum 7 is built on a newer PostgreSQL than Greenplum 6, so objects, SQL and extensions that depend on 6 behavior have to be found before the upgrade window, not during it.
Challenge
The warehouse supports claims analytics and had run on Greenplum 6 for several years. The team had deferred the upgrade because they could not say what would break. A catalog with years of drift, a set of legacy backup scripts, and several dozen reporting views and external table definitions made the risk hard to size, and the maintenance window was one weekend.
Environment
Greenplum 6 on AWS EC2 with EBS-backed segments, a standby coordinator, gpbackup to S3, and PXF external tables reading from object storage.
Approach
AceMQ built a compatibility inventory first, then rehearsed the upgrade twice on a restored copy of production before agreeing the window. The rehearsals produced the real list of changes and timings, and a rollback that had been run end to end.
Solution
- Ran gpcheckcat and cleaned catalog inconsistencies before any upgrade step
- Inventoried SQL, views, functions, extensions and external tables against Greenplum 7 behavior and removed or rewrote the incompatible ones
- Replaced legacy backup scripts with gpbackup and gprestore jobs, tested with a real restore
- Rehearsed the upgrade twice on a copy restored from backup, recording timings for each stage
- Wrote and tested a rollback to the Greenplum 6 cluster, including the decision point after which rollback is no longer cheap
- Planned the cutover window, a post-upgrade analyze run and a query plan comparison on the twenty most expensive reports
Outcome
The upgrade ran inside a single weekend window and the rollback was never needed. The post-upgrade plan comparison found two regressed queries, both fixed before Monday.