什么是高可用

?高可用HA(High Availability)是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一，它通常是指，通過設(shè)計(jì)減少系統(tǒng)不能提供服務(wù)的時(shí)間。假設(shè)系統(tǒng)一直能夠提供服務(wù)，我們說系統(tǒng)的可用性是100%，很多公司的高可用目標(biāo)是4個(gè)9，也就是99.99%，這就意味著，系統(tǒng)的年停機(jī)時(shí)間為0.876個(gè)小時(shí)。

如何做到高可用

高可用系統(tǒng)最大的勁敵就是單點(diǎn)故障。任何一個(gè)單點(diǎn)故障都是不可避免的，如果系統(tǒng)是單點(diǎn)架構(gòu)的，當(dāng)單點(diǎn)出現(xiàn)故障則會(huì)導(dǎo)致系統(tǒng)不可用。所以，實(shí)現(xiàn)高可用的本質(zhì)就是冗余。冗余部署服務(wù)，當(dāng)單點(diǎn)出現(xiàn)故障后，及時(shí)發(fā)現(xiàn)并用備份系統(tǒng)替換。

Greenplum高可用的實(shí)現(xiàn)

Greenplum是一個(gè)高可用數(shù)據(jù)庫系統(tǒng)，同樣是通過冗余部署來實(shí)現(xiàn)高可用。

Greenplum系統(tǒng)中包含了一個(gè)主節(jié)點(diǎn)和若干個(gè)子節(jié)點(diǎn)。Greenplum正是通過對(duì)每個(gè)節(jié)點(diǎn)提供冗余來實(shí)現(xiàn)高可用。在數(shù)據(jù)庫系統(tǒng)里，通過復(fù)制技術(shù)來實(shí)現(xiàn)冗余。

復(fù)制

Greenplum通過復(fù)制來實(shí)現(xiàn)冗余。在執(zhí)行寫操作時(shí)，會(huì)產(chǎn)生xlog事務(wù)日志。xlog既可以作為數(shù)據(jù)庫Crash時(shí)進(jìn)行數(shù)據(jù)恢復(fù)的依據(jù)，同時(shí)也可以作為增量更新傳遞給從節(jié)點(diǎn)。xlog存儲(chǔ)在數(shù)據(jù)目錄的pg_xlog目錄下。

在主節(jié)點(diǎn)上會(huì)存在wal-sender進(jìn)程，從節(jié)點(diǎn)上會(huì)存在wal-receiver進(jìn)程，wal-sender進(jìn)程會(huì)將產(chǎn)生的寫日志同步給wal-receiver進(jìn)程來實(shí)現(xiàn)冗余。

Primary節(jié)點(diǎn)和Mirror節(jié)點(diǎn)上的wal sender和wal receiver進(jìn)程可以通過ps命令看到

同步復(fù)制、異步復(fù)制

復(fù)制只是將xlog拷貝到從節(jié)點(diǎn)，復(fù)制分為同步復(fù)制和異步復(fù)制。

對(duì)于同步復(fù)制來說，commit操作在xlog同步到從節(jié)點(diǎn)后才返回。

對(duì)于異步復(fù)制，xlog刷新到本地磁盤即返回，并不等待從節(jié)點(diǎn)提交完，所以xlog同步到從節(jié)點(diǎn)是異步的，可能立刻完成，也可能有很大延遲。

同步復(fù)制保證了主從的一致性，但是增加了事務(wù)提交的延遲，另外如果從節(jié)點(diǎn)出現(xiàn)了故障，則事務(wù)將一會(huì)hang住無法提交。異步復(fù)制降低了延遲，但是可能存在主從不一致。

為了保證高可用性，目前Greenplum采用的是同步復(fù)制。通過GUC synchronous_commit和synchronous_standby_names來控制。其中synchronous_standby_names配置設(shè)置同步的子節(jié)點(diǎn)信息，通常設(shè)置成’*’來表示在所有從節(jié)點(diǎn)上使用同步復(fù)制(目前最多只支持一個(gè)從節(jié)點(diǎn))。synchronous_commit則必須設(shè)置成on。

Greenplum?高可用部署圖

綜上，對(duì)于一個(gè)高可用的greenplum集群，master節(jié)點(diǎn)會(huì)對(duì)應(yīng)備份的standby節(jié)點(diǎn)，每個(gè)primary子節(jié)點(diǎn)會(huì)有與之對(duì)應(yīng)的mirror子節(jié)點(diǎn)。目前的greenplum只支持一主一從，暫時(shí)不支持一主多從。

gp_segment_configuration(節(jié)點(diǎn)元數(shù)據(jù)的catalog表)

Greenplum通過catalog表gp_segment_configuration來維護(hù)包括master,standby在內(nèi)的，所有節(jié)點(diǎn)的信息。這也是DBA了解集群狀態(tài)最直觀的方式。

下面是一個(gè)實(shí)例，該集群包含3個(gè)節(jié)點(diǎn)。

Primary-Mirror的故障恢復(fù)— FTS

FTS(Fault Tolerance Service)是greenplum提供的對(duì)于子節(jié)點(diǎn)的故障檢測(cè)與恢復(fù)的服務(wù)。FTS是一個(gè)隸屬于master的子進(jìn)程，通過定期輪詢每個(gè)primary的狀態(tài)來獲取每個(gè)primary-mirror組的狀態(tài)。該進(jìn)程只在master上存在，進(jìn)程名為ftsprobe process。

這里需要注意的一點(diǎn)是，FTS并不直接連接mirror，對(duì)于mirror的狀態(tài)，FTS也是通過primary來獲取。Primary則通過wal-sender進(jìn)程的狀態(tài)來獲取mirror存活和同步狀態(tài)。

FTS在滿足如下三個(gè)條件的時(shí)候會(huì)觸發(fā)輪詢

1. 到時(shí)間了，gp_fts_probe_interval

2. 用戶手動(dòng)執(zhí)行select gp_request_fts_probe_scan()

3. 查詢執(zhí)行過程中發(fā)現(xiàn)節(jié)點(diǎn)異常

輪詢過程圖如下：

對(duì)于每個(gè)primary-mirror組來說一般會(huì)有如下幾種狀態(tài)。

1. primary正常，mirror正常

2. primary正常，mirror異常

3. primary異常，mirror正常

4. primary異常，mirror異常

Greenplum目前是一主一從架構(gòu)，所以對(duì)于第四種primary-mirror都出故障的情況是解決不了的，在這種情況下只能通過人工干預(yù)解決。對(duì)于第一種都正常的情況也不需要做任何處理。所以下面對(duì)二三兩種情況做詳細(xì)介紹。

故障1：primary掛掉

這是最常見，也是高可用解決的最主要的問題。一旦FTS發(fā)現(xiàn)某個(gè)primary已經(jīng)宕機(jī)，此時(shí)，如果Mirror是同步的，則將把對(duì)應(yīng)的Mirror Promote成primary，并更新catalog。

Promote后catalog可以看到如下更新。

通過role可以看出，mirror成了primary，preferred_role沒有變，同時(shí)原primary被標(biāo)記成了mirror，但status是d。mode也被標(biāo)記成了n。

故障2：mirror掛掉

如果mirror掛掉了，意味著primary與mirror的復(fù)制不可能同步了，所以primary會(huì)hang住，直到FTS來通知primary執(zhí)行Sync-off來關(guān)閉同步復(fù)制。關(guān)閉同步復(fù)制的方法即將synchronous_standby_names設(shè)置成空。

可以看到catalog表的變化，mode已經(jīng)變成不同步，mirror的狀態(tài)也標(biāo)記成down。

注意：FTS在輪詢的時(shí)候，如果Primary節(jié)點(diǎn)發(fā)現(xiàn)Mirror存活并且復(fù)制方式是非同步，則會(huì)強(qiáng)制設(shè)置為同步復(fù)制，即更新synchronous_standby_names為’*’。

FTS相關(guān)GUC

Master的故障恢復(fù)

FTS與實(shí)現(xiàn)了segments節(jié)點(diǎn)的故障自動(dòng)恢復(fù)，那么Master如何恢復(fù)呢。在Greenplum6里并沒有實(shí)現(xiàn)Master故障的自動(dòng)切換機(jī)制，Master節(jié)點(diǎn)如果出故障，只能通過手動(dòng)方式運(yùn)行g(shù)pactivatestandy來Promote standby。

同時(shí)，在Master節(jié)點(diǎn)上，synchronous_standby_names配置一直為空，即使Standby掛掉或網(wǎng)絡(luò)故障造成同步延遲，請(qǐng)求不會(huì)被阻塞。因?yàn)闆]有自動(dòng)通知Master做關(guān)閉同步復(fù)制的服務(wù)。

高可用相關(guān)運(yùn)維工具gpactivatestandby

gpactivatestandby會(huì)激活standby成master。

例如：

gpactivatestandby -d /gpdata/standby

該命令會(huì)激活運(yùn)行在/gpdata/standby目錄下的standby為master。gpinitstandby

gpinitstandby會(huì)基于當(dāng)前master初始化一個(gè)新的standby。通常是在master掛掉，standby提升成master后，來生成一個(gè)新的standby作為master的備份用。

例如：

gpinitstandby -s myhost -S /gpdata/standby -P 2222

該命令會(huì)在myhost機(jī)器上的/gpdata/standby目錄，生成一個(gè)運(yùn)行端口為2222的standby節(jié)點(diǎn)。

通過運(yùn)行如下命令也可以在standby宕機(jī)后，重新啟動(dòng)standby

gpinitstandby -ngprecoverseg

gprecoverseg工具可以恢復(fù)一個(gè)已經(jīng)宕機(jī)的mirror。

可以通過執(zhí)行g(shù)precoverseg -F來徹底重建已經(jīng)宕機(jī)的mirror。獲得Greenplum更多干貨內(nèi)容，歡迎前往Greenplum中文社區(qū)網(wǎng)站

總結(jié)

以上是生活随笔為你收集整理的greenplum配置高可用_Greenplum 的高可用是怎么做到的？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。