前言
適用版本:【8.2.1.210及以上】
當前數(shù)倉承載的客戶業(yè)務越來越多,從而導致客戶對于數(shù)倉的可靠性要求不斷增加。尤其在金融領域,容災備份機制是信息系統(tǒng)必須提供的能力之一。本文介紹了在云上環(huán)境的雙集群(不跨Region不跨VPC)后臺手動部署并使用細粒度容災的主要步驟,使得用戶能快速方便得搭建起細粒度容災。
2. 細粒度容災簡介
對于MPPDB集群的容災而言,目前業(yè)界的常見方案要么是部署兩套規(guī)格配置同等的集群,要么通過邏輯雙加載方式去實現(xiàn),這兩個方案缺點比較明顯,存在架構(gòu)復雜、建設成本高等問題,不僅使得災備部署難度增大,還導致資源浪費。在此背景下,GaussDB(DWS)基于列存表實現(xiàn)細粒度容災能力,既滿足核心分析型業(yè)務在極端場景的業(yè)務連續(xù)性要求,同時也能大幅降低容災方案的建設成本,而且容災架構(gòu)輕量化,容災系統(tǒng)易運維、易操作、易演練,從而幫助用戶迅捷、經(jīng)濟、按需構(gòu)建核心業(yè)務的容災系統(tǒng)。
相比于傳統(tǒng)的容災方案,細粒度容災有以下優(yōu)勢:
主集群和備集群雙活(Active-Active)(備集群除災備表只讀外,其余表可讀寫)
主備集群只需滿足DN整數(shù)倍關系,降低備集群建設資源,方便靈活部署
利用列存表的數(shù)據(jù)和元數(shù)據(jù)分離的特點,通過元數(shù)據(jù)邏輯同步 + 數(shù)據(jù)物理同步的方式,同步增量,結(jié)合UDF的增量抽取/回放接口,保障表級數(shù)據(jù)一致性
粒度可控,支持表級、schema級、庫級容災
支持表DDL,部分DCL元數(shù)據(jù)同步,達到切換可用
細粒度容災示意圖

3. 容災前準備
3.1 配置互信
前提條件
確保ssh服務打開。
確保ssh端口不會被防火墻關閉。
確保所有機器節(jié)點間網(wǎng)絡暢通。
配置互信
依次登錄主備集群各節(jié)點沙箱外,執(zhí)行步驟2-4。
將主集群和備集群所有節(jié)點ip和hostname添加到/home/Ruby/.ssh/authorized_keys和/var/chroot/home/Ruby/.ssh/authorized_keys的from列表中。
將主集群和備集群所有節(jié)點ip和hostname的映射添加到/etc/hosts和/var/chroot/etc/hosts文件中。
遍歷主集群和備集群所有節(jié)點ip和hostname,執(zhí)行以下命令。
ssh-keyscan -t rsa -T 120 ${ip/hostname} >> /home/Ruby/.ssh/known_hosts ssh-keyscan -t rsa -T 120 ${ip/hostname} >> /var/chroot/home/Ruby/.ssh/known_hosts
校驗互信
從主集群任一節(jié)點能免密ssh到備集群任一節(jié)點且從備集群任一節(jié)點能免密ssh到主集群任一節(jié)點,即代表互信已配置成功。
3.2 配置容災配置文件
Ruby用戶分別登錄主備集群主節(jié)點沙箱內(nèi)。
創(chuàng)建容災目錄,假設目錄為/DWS/data2/finedisaster。mkdir -p /DWS/data2/finedisaster
在/DWS/data2/finedisaster目錄下,創(chuàng)建容災配置文件backupRestore.ini和主備集群倒換配置文件sw_backupRestore.ini。
注意:
細粒度容災的容災備份過程支持與物理細粒度備份業(yè)務并行執(zhí)行。可通過以下措施隔離:
兩個備份任務指定不同的metadata目錄和media目錄,實現(xiàn)備份數(shù)據(jù)隔離。容災備份目錄通過容災配置文件(backupRestore.ini和sw_backupRestore.ini)中的參數(shù)primary-media-destination和primary-metadata-destination指定。
細粒度容災的容災備份端口與物理細粒度備份的master-port指定為不同的值,實現(xiàn)備份進程端口的隔離。容災的備份端口通過容災配置文件(backupRestore.ini和sw_backupRestore.ini)中的參數(shù)backup-port指定。
容災配置文件backupRestore.ini
以下是backupRestore.ini文件示例,可根據(jù)具體業(yè)務場景修改配置參數(shù)值。
# Configuration file for SyncDataToStby tool # The backup life cycle life-cycle=10m # The table that records backups info backuprestoreinfo-file=backuprestoreinfo.csv # The cluster user name for cluster username=Ruby # The primary cluster env set primary-env= # The standby cluster env set standby-env= # Time interval between each full backup, uint: min full-backup-exec-time-interval=N/A # Time interval between each backup backup-exec-time-interval=2 # One of the backup hosts primary-host-ip=XXX.XXX.XXX.XX # The media type that restore backup files, DISK media-type=disk # The number of process that should be used. Range is (1~32) parrallel-process=4 # The compression level that should be used for backup. Range(0~9) compression-level=1 compression-type=2 # Media destination where the backup must be stored primary-media-destination=/DWS/data2/finedisaster/mediadata # Metadata destination where the metadata must be stored primary-metadata-destination=/DWS/data2/finedisaster/metadata # The master-port in which the backup must be executed backup-port=XXXX # Logging level for the log contents of backup:FATAL,ERROR,INFO,DEBUG primary-cluster-logging-level=INFO # Time interval between each restore, uint: min restore-interval=2 # One of the restore hosts restore-host-ip=XXX.XXX.XXX.XX # Media destination where the backup contents must be stored in the standby cluster restore-media-destination=/DWS/data2/finedisaster/mediadata # Metadata destination where the backup contents must be stored in the standby cluster restore-metadata-destination=/DWS/data2/finedisaster/metadata # The master-port in which the restore must be executed restore-port=XXXX # Logging level for the log contents of restore standby-cluster-logging-level=INFO # The maximum number of log files that should be created. Range is (5~1024). log-file-count=50 # The retry times of checking cluster balance for resuem backup or double clusters check-balance-retry-times=0 # cluster id primary-cluster-id=11111111-1111-1111-1111-111111111111 standby-cluster-id=22222222-2222-2222-2222-222222222222 # Processes tables for which fine-grained disaster recovery is no longer performed # Value should be 'none', 'log-desync-table', 'drop-desync-table' desync-table-operation=drop-desync-table # Number of CPU cores that can be used by each DR process. Range is (1~1024). cpu-cores=8 # The max number of rch files that can be reserved on master cluster before sent to standby cluster. 0 means no limit. local-reserve-file-count=160
主備集群倒換配置文件sw_backupRestore.ini相比于backupRestore.ini只需顛倒下列參數(shù)
primary-host-ip / restore-host-ip
backup-port / restore-port
primary-media-destination / restore-media-destination
primary-metadata-destination / restore-metadata-destination
primary-cluster-id / standby-cluster-id
配置文件主要參數(shù)說明
| 參數(shù)名 | 參數(shù)含義 |
|---|---|
| username | 執(zhí)行雙集群腳本的OS用戶,設置成GaussDB(DWS)集群相同的OS用戶 |
| primary-env | 主集群的環(huán)境變量存儲文件的絕對路徑 |
| standby-env | 備集群的環(huán)境變量存儲文件的絕對路徑 |
| backup-exec-time-interval | 增量備份周期 |
| primary-host-ip | 主集群執(zhí)行備份的節(jié)點ip |
| compression-type | 備份文件的壓縮算法類型 |
| compression-level | 備份文件的壓縮級別 |
| primary-media-destination | 主集群上存放備份文件的絕對路徑 |
| primary-metadata-destination | 主集群上備份元數(shù)據(jù)的絕對路徑 |
| backup-port | Roach主代理備份進程的執(zhí)行端口 |
| restore-interval | 恢復周期 |
| restore-host-ip | 備集群執(zhí)行恢復的節(jié)點ip |
| restore-media-destination | 備集群存放主集群同步的備份文件的路徑 |
| restore-metadata-destination | 備集群存放主集群同步的元數(shù)據(jù)信息的路徑 |
| restore-port | 恢復進程執(zhí)行端口 |
| primary-cluster-id | 指定主集群的UUID |
| standby-cluster-id | 指定備集群的UUID |
| new-disaster-recovery-suppressed-time-windows | 指定主集群不發(fā)起新一輪備份的時間窗口 |
| desync-table-operation | 指定不再進行細粒度容災的表,在備集群上的處理方式 |
| cpu-cores | 指定容災每個進程能使用的cpu核數(shù) |
| local-reserve-file-count | 在發(fā)送到備用群集之前,可以在主群集上保留的最大rch文件數(shù)。0表示無限制。 |
3.3 主備集群準備
Ruby用戶登錄主集群主節(jié)點沙箱內(nèi)。
設置集群GUC參數(shù)。
local-dn-num為本集群DN數(shù),remote-dn-num為對方集群DN數(shù),可替換為實際值。
python3 $GPHOME/script/DisasterFineGrained.py -t prepare --local-dn-num 6 --remote-dn-num 3 --config-file /DWS/data2/finedisaster/backupRestore.ini
3.4 容災表數(shù)據(jù)準備
主集群連接數(shù)據(jù)庫,準備容災表數(shù)據(jù)。
新建容災表
create table schema1.table_1(id int, name text) with (orientation = column, colversion="2.0", enable_disaster_cstore="on", enable_delta=false) DISTRIBUTE BY hash(id);
存量表(非容災表)轉(zhuǎn)為容災表
alter table schema1.table_1 set (enable_disaster_cstore='on');
--查詢表的分布方式
select pclocatortype from pg_catalog.pgxc_class where pcrelid = 'schema1.table_1'::oid limit 1;
--若表的分布方式為H(HASH分布),獲取一個hash表的分布列,后續(xù)以'id'列分布為例
select pg_catalog.getdistributekey('schema1.table_1');
--對表做重分布
alter table schema1.table_1 DISTRIBUTE BY HASH(id);
--若表的分布方式為N(ROUNDROBIN分布),對表做重分布
alter table schema1.table_1 DISTRIBUTE BY ROUNDROBIN;
--若表的分布方式為R(REPLICATION分布),對表做重分布
alter table schema1.table_1 DISTRIBUTE BY REPLICATION;
4. 細粒度容災操作
4.1 定義發(fā)布
Ruby用戶登錄主集群主節(jié)點沙箱,以下操作均在沙箱內(nèi)進行。
連接數(shù)據(jù)庫,通過發(fā)布語法指定需要容災的主表,語法如下:
--發(fā)布所有表 CREATE PUBLICATION _pub_for_fine_dr FOR ALL TABLES; --發(fā)布schema CREATE PUBLICATION _pub_for_fine_dr FOR ALL TABLES IN SCHEMA schema1, schema2; --發(fā)布表和schema CREATE PUBLICATION _pub_for_fine_dr FOR ALL TABLES IN SCHEMA schema1, TABLE schema2.table_1; --增加一個發(fā)布表 ALTER PUBLICATION _pub_for_fine_dr ADD TABLE schema1.table_1; --增加發(fā)布SCHEMA ALTER PUBLICATION _pub_for_fine_dr ADD ALL TABLES IN SCHEMA schema2;
定義發(fā)布后,將容災publication放到參數(shù)文件中,以dbname.pubname形式,例如:
echo 'dbname._pub_for_fine_dr' > /DWS/data2/finedisaster/pub.list
若需要解除發(fā)布,通過DisasterFineGrained.py腳本下發(fā)cancel-publication命令
# 1、創(chuàng)建需要取消的容災對象列表文件 # 解除發(fā)布表 echo 'db_name.schema_name.table_name' > /DWS/data2/finedisaster/config/disaster_object_list.txt # 解除發(fā)布SCHEMA echo 'db_name.schema_name' > /DWS/data2/finedisaster/config/disaster_object_list.txt # 2、下發(fā)cancel-publication命令 python3 $GPHOME/script/DisasterFineGrained.py -t cancel-publication --disaster-object-list-file /DWS/data2/finedisaster/config/disaster_object_list.txt --config-file /DWS/data2/finedisaster/backupRestore.ini # 3、取消全部發(fā)布 python3 $GPHOME/script/DisasterFineGrained.py -t cancel-publication --config-file /DWS/data2/finedisaster/backupRestore.ini --all-cancel
4.2 啟動容災
注意:
云上集群沙箱內(nèi)無法啟動crontab任務,需要在主備集群沙箱外手動添加定時備份恢復任務
HCS 8.3.0及以上環(huán)境,沙箱外crontab設置ssh到沙箱內(nèi)的定時任務,為了防止沙箱逃逸,ssh前需要加上"sudo python3 /rds/datastore/dws/XXXXXX/sudo_lib/checkBashrcFile.py && source /etc/profile && source ~/.bashrc && ",否則定時任務不生效。checkBashrcFile.py文件路徑與版本號有關。
主集群主節(jié)點沙箱外設置定時任務,crontab -e。注意替換主節(jié)點IP。
*/1 * * * * nohup ssh XXX.XXX.XXX.XXX "source /etc/profile;if [ -f ~/.profile ];then source ~/.profile;fi;source ~/.bashrc;nohup python3 /opt/dws/tools/script/SyncDataToStby.py -t backup --config-file /DWS/data2/finedisaster/backupRestore.ini --disaster-fine-grained --publication-list /DWS/data2/finedisaster/pub.list >>/dev/null 2>&1 &" >>/dev/null 2>&1 &
備集群主節(jié)點沙箱外設置定時任務,crontab -e。注意替換主節(jié)點IP。
*/1 * * * * nohup ssh XXX.XXX.XXX.XXX "source /etc/profile;if [ -f ~/.profile ];then source ~/.profile;fi;source ~/.bashrc;nohup python3 /opt/dws/tools/script/SyncDataToStby.py -t restore --config-file /DWS/data2/finedisaster/backupRestore.ini --disaster-fine-grained >>/dev/null 2>&1 &" >>/dev/null 2>&1 &
成功啟動備份確認。
Ruby用戶分別登錄主備集群主節(jié)點沙箱,查詢SyncDataToStby.py進程是否存在。
ps ux | grep SyncDataToStby | grep -v grep
Ruby用戶登錄主/備集群主節(jié)點沙箱,使用roach的show-progress監(jiān)控工具,查看備份/恢復進度。show-progress命令提供主備集群備份恢復進度等信息, 顯示結(jié)果為json格式,各字段含義請參考產(chǎn)品文檔。
python3 $GPHOME/script/SyncDataToStby.py -t show-progress --config-file /DWS/data2/finedisaster/backupRestore.ini
系統(tǒng)回顯:
{
"primary cluster": {
"key": "20231109_212030",
"priorKey": "20231109_211754",
"actionType": "Backup",
"progress": "100.00%",
"backupRate": {
"producerRate": "0MB/s",
"compressRate": "0MB/s",
"consumerRate": "0MB/s"
},
"currentStep": "FINISH",
"unrestoreKeys": "N/A",
"failedStep": "INIT",
"errorMsg": "",
"errorCode": "",
"actionStartTime": "2023-11-09 2128",
"actionEndTime": "2023-11-09 2149",
"updateTime": "2023-11-09 2150"
},
"standby cluster": {
"key": "20231109_175002",
"priorKey": "N/A",
"actionType": "Restore",
"progress": "100.00%",
"backupRate": {
"producerRate": "0MB/s",
"compressRate": "0MB/s",
"consumerRate": "0MB/s"
},
"currentStep": "FINISH",
"unrestoreKeys": "20231109_211754,20231109_212030",
"failedStep": "INIT",
"errorMsg": "",
"errorCode": "",
"actionStartTime": "2023-11-09 1707",
"actionEndTime": "2023-11-09 1715",
"updateTime": "2023-11-09 1715"
},
"apply": {
"backupState": "waiting",
"restoreState": "waiting",
"backupSuccessTime": "2023-11-09 2124",
"restoreSuccessTime": "2023-11-09 1755"
},
"latestBarrierTime": "",
"recovery point objective": "317",
"failover recovery point time": ""
}
show-progress命令顯示的主要字段釋義如下
priorKey:該備份集是基于這個backup key生成的。
actionType:備份集當前的操作類型。
取值包括如下:
Backup,表示備份階段。
Restore,表示恢復階段。
progress:備份或恢復操作的進度。
currentStep:備份或恢復正在執(zhí)行的步驟。
unrestoreKeys:待恢復的key列表。
failedStep:備份或恢復失敗的步驟,初始值默認為INIT。
errorMsg:備份或恢復失敗的錯誤信息,如果成功,該字段則顯示成功的信息。
errorCode:備份或恢復的錯誤碼,該字段為預留字段,暫未使用。
actionStartTime:當前操作的開始時間。
actionEndTime:當前操作的結(jié)束時間。
updateTime:當前操作進度的刷新時間。
backupState:當前備份狀態(tài)(backuping/stopped/waiting/abnormal)。
restoreState:當前恢復狀態(tài)(restoring/stopped/waiting/abnormal)。
backupSuccessTime:上次成功備份結(jié)束的時間。
restoreSuccessTime:上次成功恢復結(jié)束的時間。
latestBarrierTime:上次主備集群一致點時間。
recovery point objective:rpo時間(當前主集群時間到最后一個恢復成功的備份集備份開始時間)。
failover recovery point time:failover未同步時間點。
4.3 結(jié)果驗證
4.3.1 功能驗證
同步前后進行數(shù)據(jù)一致性校驗,主表、備表數(shù)據(jù)進行checksum校驗,檢查是否同步正確(需排除由于接入業(yè)務導致的差異)。
4.3.2 性能驗證
通過show-progress監(jiān)控工具可以看到最近一次備份、恢復耗時。
5. 解除容災
5.1 停止容災
# 主備集群取消沙箱外的定時容災任務,在備份/恢復任務前添加注釋符“#”,取消定時任務 crontab -e # 主集群Ruby用戶登錄主節(jié)點沙箱,停止備份 python3 $GPHOME/script/SyncDataToStby.py -t stop-backup --config-file /DWS/data2/finedisaster/backupRestore.ini --disaster-fine-grained # 備集群Ruby用戶登錄主節(jié)點沙箱,停止恢復 python3 $GPHOME/script/SyncDataToStby.py -t stop-restore --config-file /DWS/data2/finedisaster/backupRestore.ini --disaster-fine-grained
5.2 刪除容災
警告
當不再需要容災任務的時候,可以解除主備關系,恢復備集群的讀寫能力。刪除容災前需要先停止容災。
Ruby用戶登錄主集群主節(jié)點的沙箱內(nèi)。
python3 $GPHOME/script/SyncDataToStby.py -t set-independent --config-file /DWS/data2/finedisaster/backupRestore.ini --disaster-fine-grained
系統(tǒng)回顯:
Delete csv file. Delete roachbackup file from XXX.XXX.XXX.XX Delete roachbackup file from XXX.XXX.XXX.XX Clear cluster disaster state.
6. 總結(jié)
本文介紹了在云上環(huán)境的雙集群(不跨Region不跨VPC)后臺手動部署并使用細粒度容災的主要步驟,分為容災前準備、細粒度容災操作和解除容災,使得用戶能快速方便得搭建起細粒度容災。
審核編輯:黃飛
-
容災系統(tǒng)
+關注
關注
0文章
4瀏覽量
5436
原文標題:詳解如何在數(shù)倉中搭建細粒度容災應用
文章出處:【微信號:magedu-Linux,微信公眾號:馬哥Linux運維】歡迎添加關注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
細粒度圖像分析技術詳解
一種細粒度的面向產(chǎn)品屬性的用戶情感模型
基于Modbus功能碼細粒度過濾算法的研究
基于ABS細粒度隱私隔絕的身份追溯研究
使用深度模型遷移進行細粒度圖像分類的方法說明
細粒度圖像分析任務在發(fā)展過程中面臨著獨特的挑戰(zhàn)
紹華為云在細粒度情感分析方面的實踐
結(jié)合非局部和多區(qū)域注意力機制的細粒度識別方法
基于文本的細粒度美妝圖譜視覺推理問題
基于BiLSTM-CRF的細粒度知識圖譜問答模型
機器翻譯中細粒度領域自適應的數(shù)據(jù)集和基準實驗
通過對比學習的角度來解決細粒度分類的特征質(zhì)量問題

數(shù)倉中搭建細粒度容災應用的主要步驟
評論