GPDB43 Administrator Guide--第五章 高可用

第五章 高可用

一、高可用概述

GREENPLUM可以透過一系列方案保證系統的高可用。主要措施有：

1. 硬體RAID保護資料
2. segment映象
3. master映象
4. 雙叢集（dual cluster）

        可以透過維護兩個Greenplum資料庫叢集儲存相同資料來提供另一種冗餘級別。兩種方法保持雙叢集同步資料，即“雙ETL”和“備份/恢復”。雙ETL提供了完整的standby叢集，與primary叢集具有相同的資料。 ETL（提取，轉換和載入）是指清洗，轉化，驗證並裝載資料到資料倉儲。具有雙ETL，這個過程是並行執行兩次，每個群集一次，並每次都驗證。它也允許查詢兩個群集上的資料，查詢吞吐量加倍。應用程式可以利用這兩個叢集的優勢，也保證了ETL成功，並透過兩個叢集驗證。用備份/恢復方法維持雙群集，先建立主群集的備份，然後在輔助群集上恢復它們。這種方法比雙ETL策略需要更長的時間同步資料，但需要開發較少的應用程式邏輯。填充第二叢集，資料修改情況下備份是非常適合的，日常執行ETL。

      5.備份與恢復

        建議將備份檔案轉移到專門的儲存空間中，防止segment主機空間不足。可選的地方有：data domain、Netbackup、NFS。

•      關於增量備份

        Greenplum的資料庫允許在append-optimized分割槽表與column-oriented表進行增量備份。當您執行增量備份，只有自上次備份以來發生更改的append-optimized分割槽和column-oriented的表進行備份。 （堆表始終要備份）還原增量備份需要恢復以前的完全備份和後續增量備份。

        增量備份是有益的，只有當資料庫中含有大量，分割槽表，其中所有，但一個或幾個分割槽保持備份之間不變。增量備份只儲存更改分割槽和堆表。透過不備份不變分割槽，備份大小和時間可顯著減少。

        如果一個大的事實表未分割槽，和一個單一的行被新增或改變時，整個表被備份，並且在備份大小或時間沒有積蓄。因此，增量備份只建議在大型的，分割槽表和相對較小的維表的資料庫。

        如果你保持雙叢集和使用增量備份，你可以用增量備份填充第二叢集。使用--noplan選項來實現這一點，從而允許更快地施加從主站點的備份。

 

（一）segment例項映象

        如果primary segment故障，資料庫查詢故障轉移到mirror segment；

        對於堆疊表，資料塊是儲存在記憶體緩衝區中的，直到為新的更新塊騰挪空間才重新整理到磁碟。

        Append-optimized表不使用記憶體快取機制；

        如果primary segment發生故障，檔案複製程式停止，mirror segment自動啟動為活動段例項。現在的活動映象的系統狀態變成更改跟蹤（change tracking ），這意味著維護mirror系統表和所有修改的資料塊change-log更改日誌。當故障的主段修復並準備重新聯機，管理員啟動恢復過程和系統進入重新同步狀態。在恢復過程應用更改日誌記錄到需要修復的primary segment。當恢復過程完成後系統狀態變為已同步（Synchronized）。

 

Figure 7: Segment Data Mirroring in Greenplum Database

 

（二）master例項映象

        master mirror叫standby master，可以在同一主機或不同主機上。standby master通常為warm standby。

        primary master與standby master是保持同步的。主要是透過walsender和walreceiver兩個程式實現，walsender在primary master上，walreceiver在standby master上；方法是透過wal 的streaming replication實現同步；

        如果primary master出現故障，在複製過程停止，並且管理員可以啟用standby master。在啟用standby master的，複製的日誌重建在最後成功提交交易時的第一主機的狀態。啟用standby master作用是作為Greenplum的資料庫primary master，當standby master被初始化後，則接受指定埠上的連線。

 

 

（三）故障檢測與恢復

        ftsprobe程式負責各故障檢測，它會週期性的連線和掃描所有segment和資料庫程式；這個週期性也是可以配置的；如果ftsprobe不能連線則標記segment為down狀態，這個segment就不能操作直到管理員恢復；如果有映象則會故障遷移啟用mirror。要恢復segment可以使用gprecoverseg工具。如果沒有mirror，則整個greenplum資料庫會shutdown，直到管理員手動恢復；

 

二、GREENPLUM資料庫映象

（一）配置segment映象

1.增加segment mirror，與primary在同一主機

        a.分配儲存空間

        b.gpssh-exkeys，保證所有segment hosts 等效性

        c.gpaddmirrors工具執行，-p選項指導埠

2.增加segment mirror，與primary在不同主機

        a.所有節點安裝軟體greenplum

        b.分配儲存空間

        c.gpssh-exkeys，保證等效性

        d.建立配置檔案，gpaddmirrors工具執行， -o選項指導配置檔案filename

            $ gpaddmirrors -o filename

配置檔案格式：

filespaceOrder=[filespace1_fsname[:filespace2_fsname:...]

mirror[content]=content:address:port:mir_replication_port:

pri_replication_port:fselocation[:fselocation:...]

例子:

filespaceOrder=

mirror0=0:sdw1:sdw1-1:52001:53001:54001:/gpdata/mir1/gp0

mirror1=1:sdw1:sdw1-2:52002:53002:54002:/gpdata/mir1/gp1

mirror2=2:sdw2:sdw2-1:52001:53001:54001:/gpdata/mir1/gp2

mirror3=3:sdw2:sdw2-2:52002:53002:54002:/gpdata/mir1/gp3

        e.建立mirror，gpaddmirrors -i mirror_config_file

（二）配置master映象

        master mirror 即standby master；兩種方法建立standby master：一是建立新的greenplum資料庫時，透過工具gpinitsystem；二是在已有系統上，透過工具gpinitstandby。

        切換primary與standby，參考Recovering a Failed Master章節；

        檢查standby master程式狀態：$ psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;'

三、segment故障檢測

        ERROR: All segment databases are unavailable ，以上錯誤說明資料庫不可用，查詢訪問不到所有資料。postgres的postmaster程式會fork一個ftsprobe程式，即FTS，Fault Tolerance Server程式，透過這個程式檢查所有的segment狀態；gp_segment_configuration中有所有segment的狀態，角色等資訊

dbid	content	role	preferred_role	mode	status	port	hostname	address	replication_port	san_mounts
1	-1	p	p	s	u	5432	gp1	mdw
6	-1	m	m	s	u	6432	smdw	smdw
3	1	p	p	s	u	40000	gp3	sdw2	41000
5	1	m	m	s	u	50000	gp2	sdw1	51000
2	0	p	p	s	u	40000	gp2	sdw1	41000
4	0	m	m	s	u	50000	gp3	sdw2	51000

FTS的相關引數：

gp_fts_probe_threadcount：預設值16

gp_fts_probe_interval：預設60s

gp_fts_probe_timeout：預設20秒，檢查master與segment超時時間；

gp_fts_probe_retries：預設5次

gp_log_fts：FTS日誌級別："off"、"terse"、 "verbose"、"debug"，預設terse。

gp_segment_connect_timeout：預設180秒，指mirror反應超時時間；

 

（一）警告與通知

        接收系統事件通知,比如段失敗,啟用電子郵件或SNMP警報。參考第九章監控greenplum系統。

（二）檢測故障segment主機

gpstate -e：show 錯誤資訊

psql -c "SELECT * FROM gp_segment_configuration WHERE status='d';"

關於mirror segment例項資訊：gpstate -m 

（三）檢查故障segment主機的日誌檔案

gplogfilter檢查日誌資訊：WARNING, ERROR, FATAL，PANIC

使用gpssh檢查所有segment的日誌資訊：

$ gpssh -f seg_hosts_file -e 'source

/usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -t

/data1/primary/*/pg_log/gpdb*.log' > seglog.out

 

四、segment故障恢復

（一）恢復mirror segment

        1.ping failed_seg_host_address

        2.gprecoverseg，恢復完成後，mirror進入Resynchronizing，後臺操作；

        3.gpstate -m，檢查狀態

（二）恢復segment到preferred role

        當primary segment故障後，mirror segment會啟用充當primary。由於資料或負載的問題導致不均衡，當原來的primary修復後需要使其恢復到原來的role；

        1.先檢查狀態，gpstate -m，確保所有mirror都是Synchronized.狀態；

        2.如果有mirror是Resynchronizing，則等待同步完成

        3.gprecoverseg -r恢復其到preferred role

        4.gpstate -e,確認結果

（三）雙誤情況下的恢復

        當primary與mirror segment都出現故障後的恢復過程如下：

        1.重啟資料庫：gpstop -r

        2.重啟後，gprecoverseg

        3.恢復完成後檢查狀態：gpstate -m

        4.如果仍然有segment處於Change Tracking狀態，則：gprecoverseg -F 即full copy recovery

（四）無mirror情況下的恢復

        檢查master到segment的網路連通情況，手動恢復segment主機，然後重啟greenplum資料庫；

        $ ping failed_seg_host_address

        $ gpstop -r

        $ gpstate

（五）segment主機不可恢復情況下greenplum恢復

        如果意外導致segment主機硬體等毀滅性原因不可恢復，則可以透過其他mirror在備用主機上恢復；

 

$gprecoverseg -i recover_config_file

         recover_config_file格式如下:

filespaceOrder=[filespace1_name[:filespace2_name:...]failed_host_address:port:fselocation [recovery_host_address:port:replication_port:fselocation[:fselocation:...]]

        例子：

filespaceOrder=sdw5-2:50002:/gpdata/gpseg2 sdw9-2:50002:53002:/gpdata/gpseg2

 

=# SELECT dbid, content, hostname, address, port,

replication_port, fselocation as datadir

FROM gp_segment_configuration, pg_filespace_entry

WHERE dbid=fsedbid

ORDER BY dbid;

 

五、master故障恢復

        $ gpactivatestandby -d /data/master/gpseg-1

        $ gpstate -f

        $ psql dbname -c 'ANALYZE;'

        $ gpinitstandby -s new_standby_master_hostname

• 恢復master到preferred role

        1.確認primary master已經完全恢復正常

        2.primary master主機上，移除data_master_directory

$ mv /data/master/gpseg-1 /data/master/backup_gpseg-1

        3. primary master主機上初始化standby

$ gpinitstandby -s mdw

        4.檢查狀態：$ gpstate -f

        5.停止現在的primary master 資料庫：$ gpstop -m

        6. primary master主機上，啟用standby 到master：$ gpactivatestandby -d $MASTER_DATA_DIRECTORY

        7.檢查狀態：$ gpstate -f

        8.standby master 主機上，移除$MASTER_DATA_DIRECTORY

$ mv /data/master/gpseg-1 /data/master/backup_gpseg-1

        9.standby master 主機上初始化standby

$ gpinitstandby -s smdw

• 檢查master mirroring程式狀態

$ psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;'