The restoration of a Greengage DB cluster involves managing three data components: actual data, identity, and behavior. While data is identical for primary and mirror segments, identity parameters like gp_dbid, gp_contentid, and port must be remapped for the target environment. Behavior settings, including pg_hba.conf and pg_ident.conf, require manual adjustment to match the new infrastructure.
Standard recovery using gprecoverseg -aF is sequential, as mirrors are rebuilt via pg_basebackup from primary segments after the latter are restored. This process increases Recovery Time Objective (RTO) and creates extra load. An optimized approach involves restoring primary and mirror segments in parallel from the same backup set, treating each as an independent task.
Parallel restoration requires specific steps to maintain consistency. After replaying WAL to the same recovery point, the replication slot internal_wal_replication_slot must be recreated on primary segments, as it is dropped during archive recovery. Additionally, mirrors must be configured to follow the latest timeline, and the cluster topology must be updated in gp_segment_configuration.
This manual optimization is recommended for large clusters where reducing downtime is critical. The process demands rigorous verification of dbid and content mappings, local configurations, and replication states. The same identity-remap technique allows for restoring one cluster from the backup of another, provided the number of primary segments remains consistent.
