How to Deploy Fine-Grained Disaster Recovery for GaussDB DWS on Cloud

Applicable version: 8.2.1.210 and above. As data warehouses host more customer workloads, reliability requirements increase, especially in finance where disaster‑recovery (DR) is mandatory. This article describes the main steps for manually deploying fine‑grained DR in a cloud‑based dual‑cluster (same Region, same VPC) environment, enabling users to quickly set up DR.

Fine‑Grained Disaster Recovery Overview

Traditional MPPDB DR solutions either duplicate clusters with identical specs or use logical dual‑loading, both of which are complex and costly. GaussDB(DWS) implements fine‑grained DR using column‑store tables, providing active‑active primary‑standby clusters, lower resource consumption, and a lightweight, easy‑to‑operate DR architecture.

Advantages include:

Active‑active primary and standby clusters (standby tables are read‑only, others read‑write).

Standby cluster size only needs to be an integer multiple of DN, reducing resources.

Metadata‑logic sync plus data‑physical sync ensures table‑level consistency, leveraging UDF incremental extract/replay.

Granularity control at table, schema, or database level.

Support for table DDL and partial DCL metadata synchronization.

Disaster‑Recovery Preparation

Configure Trust

Prerequisites: SSH service enabled, SSH port open, network connectivity between all nodes.

Add the IP and hostname of every primary and standby node to /home/Ruby/.ssh/authorized_keys and /var/chroot/home/Ruby/.ssh/authorized_keys, and update /etc/hosts and /var/chroot/etc/hosts. Then run:

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

Verify trust by password‑less SSH between primary and standby nodes.

Configure DR Configuration Files

Create a disaster‑recovery directory, e.g., mkdir -p /DWS/data2/finedisaster, and under it create backupRestore.ini and sw_backupRestore.ini. The backup configuration supports parallel execution with physical backup and can isolate backup tasks by specifying different metadata and media directories and ports.

Example backupRestore.ini (values should be adjusted to the actual environment):

# Configuration file for SyncDataToStby tool
life-cycle=10m
backuprestoreinfo-file=backuprestoreinfo.csv
username=Ruby
primary-env=
standby-env=
full-backup-exec-time-interval=N/A
backup-exec-time-interval=2
primary-host-ip=XXX.XXX.XXX.XX
media-type=disk
parrallel-process=4
compression-level=1
compression-type=2
primary-media-destination=/DWS/data2/finedisaster/mediadata
primary-metadata-destination=/DWS/data2/finedisaster/metadata
backup-port=XXXX
primary-cluster-logging-level=INFO
restore-interval=2
restore-host-ip=XXX.XXX.XXX.XX
restore-media-destination=/DWS/data2/finedisaster/mediadata
restore-metadata-destination=/DWS/data2/finedisaster/metadata
restore-port=XXXX
log-file-count=50
check-balance-retry-times=0
primary-cluster-id=11111111-1111-1111-1111-111111111111
standby-cluster-id=22222222-2222-2222-2222-222222222222
desync-table-operation=drop-desync-table
cpu-cores=8
local-reserve-file-count=160

The standby configuration sw_backupRestore.ini swaps the primary and standby parameters (host IP, ports, media/metadata destinations, cluster IDs).

Key parameters:

username : OS user executing scripts, must match GaussDB(DWS) OS user.

primary-env : Absolute path of primary cluster environment variable file.

standby-env : Absolute path of standby cluster environment variable file.

backup-exec-time-interval : Incremental backup interval.

primary-host-ip : IP of primary backup host.

compression-type : Compression algorithm type for backup files.

compression-level : Compression level (0‑9).

primary-media-destination : Path on primary where backup media is stored.

primary-metadata-destination : Path on primary where metadata is stored.

backup-port : Port for backup process.

restore-interval : Restore interval.

restore-host-ip : IP of standby restore host.

restore-media-destination : Path on standby for received backup media.

restore-metadata-destination : Path on standby for received metadata.

restore-port : Port for restore process.

primary-cluster-id : UUID of primary cluster.

standby-cluster-id : UUID of standby cluster.

desync-table-operation : Action for tables excluded from fine‑grained DR (e.g., drop‑desync‑table).

cpu-cores : Number of CPU cores per DR process.

local-reserve-file-count : Max number of rch files retained on primary before sending.

Prepare Primary and Standby Clusters

Run the preparation script on the primary sandbox:

python3 $GPHOME/script/DisasterFineGrained.py -t prepare --local-dn-num 6 --remote-dn-num 3 --config-file /DWS/data2/finedisaster/backupRestore.ini

Create disaster‑recovery tables, e.g.:

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);

Convert existing tables by setting enable_disaster_cstore='on' and adjusting distribution keys as needed.

Fine‑Grained DR Operations

Define Publication

Define a publication on the primary to specify tables for DR:

CREATE PUBLICATION _pub_for_fine_dr FOR ALL TABLES;
-- or specific schemas/tables
CREATE PUBLICATION _pub_for_fine_dr FOR ALL TABLES IN SCHEMA schema1, schema2;
ALTER PUBLICATION _pub_for_fine_dr ADD TABLE schema1.table_1;

Save the publication name to a file, e.g.,

echo 'dbname._pub_for_fine_dr' > /DWS/data2/finedisaster/pub.list

. Use the script to cancel publications when needed.

Start DR

Because crontab cannot run inside the cloud sandbox, schedule backup and restore tasks from outside the sandbox. Example crontab entries (replace IPs):

* */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 &"

* */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 &"

Verify the processes and monitor progress with

python3 $GPHOME/script/SyncDataToStby.py -t show-progress --config-file /DWS/data2/finedisaster/backupRestore.ini

. The JSON output includes fields such as progress, currentStep, actionType, and timestamps.

Result Verification

Perform checksum validation on primary and standby tables to ensure data consistency, and review backup/restore duration via the progress tool.

Remove Disaster Recovery

Stop DR

# Comment out or remove crontab entries
crontab -e
# Stop backup on primary
python3 $GPHOME/script/SyncDataToStby.py -t stop-backup --config-file /DWS/data2/finedisaster/backupRestore.ini --disaster-fine-grained
# Stop restore on standby
python3 $GPHOME/script/SyncDataToStby.py -t stop-restore --config-file /DWS/data2/finedisaster/backupRestore.ini --disaster-fine-grained

Delete DR

After stopping DR, run:

python3 $GPHOME/script/SyncDataToStby.py -t set-independent --config-file /DWS/data2/finedisaster/backupRestore.ini --disaster-fine-grained

This removes DR state, deletes backup files, and restores read/write capability to the standby cluster.

Conclusion

The guide walks through preparing the environment, configuring fine‑grained DR, executing backup and restore, verifying results, and finally removing DR for a cloud‑based dual‑cluster GaussDB(DWS) deployment.