Greenplum -- segment 死機(jī)后恢復(fù)

一、備份原理：

GPDB4.x中：是基于文件復(fù)制同步，如果個別segment宕機(jī)，整個數(shù)據(jù)庫依然可以運(yùn)行，當(dāng)Mirror宕機(jī)時，Primary會記錄在這個階段文件變化的數(shù)據(jù)塊，等到Mirror恢復(fù)了，再把數(shù)據(jù)塊復(fù)制過去；當(dāng)Primary宕機(jī)了，那么對于的Mirror節(jié)點(diǎn)就會替換Primary，記錄文件變化的數(shù)據(jù)塊，等到Primary恢復(fù)了，它就變成了Mirror，丟失的數(shù)據(jù)就會被復(fù)制過來，這里雖然可以繼續(xù)運(yùn)行，但是存在一個問題，那就是Primary和Mirror調(diào)換了，導(dǎo)致個別機(jī)器Primary比其他機(jī)器多，負(fù)載不均衡，最好還是把它從新恢復(fù)過正常對應(yīng)關(guān)系來

二、恢復(fù)：

2.1、使用sql查詢segment狀態(tài)：

testdb=# select * from gp_segment_configuration;
存在部分segment down機(jī)的時候，在關(guān)閉的GPDB的時候，我們可以看到

再次啟動時也一樣，GPDB會忽略掉down機(jī)的segment，同時開啟mirror備用

2.1、使用配置文件生成恢復(fù)文件

可以看到生成的配置文件里包含了需要恢復(fù)的segment節(jié)點(diǎn)

2.2、使用配置文件開始恢復(fù)機(jī)器

2.3、開啟另外一個窗口，查看恢復(fù)狀態(tài)：gpstate -m

Resynchronizing：正在恢復(fù)中，必須等待所有的都Synchronized才行

2.4、存在：Acting as Primary，說明有將mirror當(dāng)primary使用了，必須等待所有恢復(fù)完畢之后，才能調(diào)換過來，調(diào)換過程會重啟GPDB

執(zhí)行命令：gprecoverseg -r

2.5、全部交換之后，查看備用mirror的狀態(tài) gpstate -m

2.6、sql查詢各節(jié)點(diǎn)信息，都為up狀態(tài)