Greenplum 的一次緊急恢復

[toc]

客戶的gp節點磁碟遭遇損壞，導致資料丟失。gprecoverseg命令無法恢復節點後做的一次非常規greenplum恢復操作。

在某次緊急運維下，我發現使用者gp的某乙個primary節點的狀態異常，已經顯示down掉，在確認所在的機器和磁碟沒有異常後，我使用gprecoverseg命令去同步已經down的primary節點。但是失敗了，在使用gpstate -e檢視到的同步進度中看到同步了一會兒，但是隨後失敗了。（失敗的原因是因為該mirror節點的磁碟曾經壞過，做過恢復，但是恢復的資料不是很完全，導致同步時校驗出錯），在該mirror節點的日誌資訊中檢視到下面這段資訊：

2019-03-16 21:30:35.341666 cst,,,p108637,th-1138622144,,,,0,,cmd126,seg-1,,,,,"error","58p01","could not open relation 1663/43186/8782691: no such file or directory",,,,,,"(null)",0,,"md.c",1371,"stack trace: 1 0xaf75c6 postgres errstart + 0x1f6 2 0x9f62ca postgres + 0x9f62ca

3 0x9f7980 postgres mdnblocks + 0xf0

gprecoverseg命令會去從mirror節點獲取資料去恢復primary節點，獲取的資料多少在gp master的元資料表中都有記錄，但是此時，mirror上的資料已經丟失，同步資料的程序到這裡出錯，因為找不到要找的表的資料，就直接退出，不再同步資料了，導致命令失敗。

這種情況下，其實greenplum的一主一備的高可用已經被破壞。資料已經永久丟失了，greenplum本身沒有什麼好的辦法恢復集群的狀態了。

客戶機器在mirror的支援下，依然是可以執行的，資料庫的使用是正常的，但是客戶擔憂負載在一台機器磁碟上，依然會有風險，需要把gp恢復到完備的狀態，其實我們還是有乙個強行恢復greenplum的方法

因為greenplum的primary和mirror的檔案目錄的資訊是完全一致的，不論是引數檔案還是資料檔案。我們完全可以手動將mirror上的檔案目錄拷貝過來，作為primary使用。但是要想讓greenplum在下次啟動時預設primary是好的去執行，還得做一些操作，完整如下：

將資料庫先關閉，保證業務停止，mirror的資料目錄不再有資料變化

gpstop -m fast

將mirror的資料目錄完整傳送到primary的目錄

scp -r gpseg12 @sdw2:/data/primary/gpseg12           :示例

完成之後，再單獨將master節點啟動

gpstart -m

進入到master資料庫中（其實master資料庫有三個template0，template1和postgres，這三個是全域性的，進哪乙個都一樣）

pgoptions='-c gp_session_role=utility' psql template1

獲取系統表的dml許可權，以便後續修改狀態

set allow_system_table_mods='dml';

預防起見，將資料庫的該系統表做一次備份

create table  16_gp_segment_configuration  as select * from gp_segment_configuration

將壞的節點全部狀態資訊改為正常，人為修改它的狀態

update gp_segment_configuration set status='u' where dbid=3;

退出後關閉master節點

gpstop -m

最後將資料庫正常啟動

gpstart -a

啟動完成之後，再看看集群的狀態全部正常了。資料庫也正常執行了。

此種恢復的方法，關鍵點在於需要保證mirror作為資料目錄，是可以正常執行的，也得保證將此目錄完整的拷貝到primary中。

Greenplum 的一次緊急恢復

記一次緊急故障的維修

只有一次只有一次

第一次出現一次的字元

Greenplum 的一次緊急恢復

記一次緊急故障的維修

只有一次 只有一次

第一次出現一次的字元

相關推薦

只有一次只有一次