Pivotal Greenplum Database (GPDB) all versions
Pivotal Greenplum Database uses Massively Parallel Processing (MPP) architecture to distribute workloads to segments hosts. Each segment host runs server multiple primary and mirror segment database instances. That database instance may fail due to multiple reasons such as hardware failure, networking outage, queries ran out of memory etc. Administrators can use a tool, gprecoverseg, to recover the failed segments.
We noticed that many GPDB administrators have the following types of questions:
- What is the impact on the production when I run gprecoverseg?
- When should I run gprecoverseg?
- What exactly does gprecoverseg do?
How it works
“gprecoverseg” normally has no impact on live queries running in production. This utility resyncs the delta data by copying the data from the live segments to their mirror pairs and will update the catalog table once the resync completes. However, please keep in mind is that since the data resync utilizes disk IO, network bandwidth, memory and CPU resources etc, this extra burden may slow down the GPDB cluster performance if the data that needs to be resynced is large and the workload on the cluster is high.
On the other hand, “gprecoverseg –r” is used to rebalance the cluster in case the primary segments are down and the primary role and mirror role is switched during the failover. This utility will switch the segments back to their preferred roles by changing the acting primary segment back to mirror and acting mirror segment back to primary segment. Both primary and mirror segment instances will be restarted during this process. As a result, the running live transactions will be interrupted.
You can run "gprecoverseg" to bring up the down segment at any time. In fact, we recommend you to run it as soon as you can so you have the backup for your data and the delta needs to be synced has a smaller size.
You should schedule a downtime to run “gprecoverseg –r”. This process normally takes 5-10 min to run.