Greenplum-- recovery after segment crash

First, the backup principle:

GPDB4.x: based on file replication synchronization. If individual segment is down, the entire database can still run. When Mirror is down, Primary will record the data blocks that have changed in the files at this stage. When Mirror is restored, the data blocks will be copied over. When the Primary goes down, the Mirror node will replace the Primary and record the data blocks of the file changes. When the Primary is restored, it will become Mirror and the lost data will be copied. Although it can continue to run here, there is a problem that Primary and Mirror have been exchanged, resulting in more Primary of individual machines than other machines and uneven load. It is best to restore it to the normal corresponding relationship.

2. Restore: 2.1.Use sql to query segment status:

Testdb=# select * from gp_segment_configuration

When there is a partial segment downmachine, when the GPDB is closed, we can see

The same is true when starting again, GPDB will ignore the segment of the downmachine and turn on the mirror standby.

2.1. Generate recovery files using configuration files

You can see that the generated configuration file contains the segment nodes that need to be restored

2.2. Start restoring the machine using the configuration file

Open another window to check the recovery status: gpstate-m

Resynchronizing: it is in the process of recovery. We must wait for all of them to be Synchronized.

2.4.Existence: Acting as Primary, which means that mirror is used as primary. You must wait for all recovery to be completed before switching over. During the exchange process, GPDB will be restarted.

Execute the command: gprecoverseg-r

2.5.After all swapping, check the status of the standby mirror gpstate-m

2.6. sql queries the information of each node, all of which are up status.