gs_replace修復(fù)節(jié)點時容易遇到的坑

本帖使用的環(huán)境均為測試環(huán)境，不涉及客戶信息

該節(jié)點需要修復(fù)的實例，對端所在的機(jī)器上，所有主dn實例的postgresql.conf文件不能有損壞

以下圖為例，如果dn6002的磁盤出現(xiàn)問題，需要gs_replace對linux180125節(jié)點進(jìn)行修復(fù)時，對端為6001，此時就要求linux180123節(jié)點上面6001,6003的postgresql.conf文件都是正常的，而不是只要6001正常就可以

gs_replace時，要考慮磁盤空間

如果linux180123的data1磁盤發(fā)生故障，此時6001和6008不可用，6002會升主開始主從復(fù)制，6007也會開始主從復(fù)制

在磁盤修復(fù)之前，6002和6007都會有大量的xlog積壓

由于6002和6007分別在兩個不同的盤，所以磁盤可能壓力不是很大，但是gs_replace修復(fù)時，6001和6008是在同一塊盤的，這時將6002和6007的數(shù)據(jù)拷貝過來就有可能導(dǎo)致磁盤空間不足；所以要提前計算空間

如果計算后發(fā)現(xiàn)空間確實不足，可以在dn6002和6007查找已經(jīng)失效的主備復(fù)制槽，并刪除，然后做checkpoint，這樣再做gs_replace時就不會拷貝大量的積壓xlog了

這里手動將6001停掉，作為例子

切到linux180125節(jié)點，登錄到dn6002上（dn6002端口是25490，查端口號的方法不在這里贅述）

執(zhí)行select * from pg_get_replication_slots();

可以看到主備復(fù)制槽已經(jīng)失效（active為f）

刪掉這個主備復(fù)制槽

select pg_drop_replication_slot('dn_6001_6002');

連接到cn，執(zhí)行多次checkpoint

這時再對dn6001做全量build就可以恢復(fù)，并且不會拷貝大量的積壓xlog

（所有dn的復(fù)制槽都處理完之后做gs_replace也一樣，gs_replace實質(zhì)還是調(diào)全量build）

Gauss AP EI企業(yè)智能 數(shù)據(jù)倉庫服務(wù) GaussDB(DWS)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。