Klustron RCR Remote Cluster Replication
Klustron RCR Remote Cluster Replication
Note:
Unless specifically stated, any version number mentioned can be substituted with any released version number. For all released versions, please visit: Release notes
Objective:
This guide assumes that users are already familiar with creating clusters in the Klustron database before proceeding. The subsequent sections detail the setup of primary and standby databases for RCR services, including operational status checks. Next, it will guide users through creating tables and inserting data in the RCR primary cluster database, and then verifying that the tables and inserted data have been synchronized to the RCR standby cluster database. The document will also cover updating and deleting operations in the primary cluster database and confirming that these changes are synced to the standby database. Each step and process will be elaborately described. The primary testing processes are conducted through the XPanel console.
All tests are conducted using the XPanel console and PostgreSQL client connections to the database cluster. The XPanel service is hosted on a server with the IP address 192.168.56.112.
01 Requirement Background
Klustron's distributed database supports high availability for clusters within the same city or across different cities by allowing users to establish additional Klustron cluster (standby cluster) in a backup data center. Together with the primary cluster, these form an RCR (Remote Cluster Replication) relationship, enabling real-time synchronization of data updates at the cluster level.
02 Feature Overview
When the primary data center becomes entirely unavailable, the user's business system can automatically switch to the Klustron backup cluster in the backup data center to continue operations. If the backup data center is located within the same city, DBAs can configure synchronous replication between the primary and standby clusters, ensuring no data loss after the switch. However, if the standby cluster is in a remote data center, asynchronous replication is typically configured due to significant network latency, which may result in the loss of some recent data updates upon failover.
03 Deployment Architecture
The cluster_mgr component of Klustron Enterprise Edition is responsible for creating and maintaining RCR inter-cluster replication relationships. Klustron provides an API interface through cluster_mgr and a GUI in XPanel, allowing users to manage and maintain RCR replication relationships. The user's DBA needs to create a standby cluster in the backup data center and configure the RCR cluster replication relationship using the RCR configuration management function. The user's business system must monitor the availability of the primary cluster or data center, and automatically switch to the standby cluster upon detecting a failure.
For more information, please visit: Klustron RCR feature introduction and usage example
04 Creating a Cluster
pen a browser on a device that can access 192.168.56.112 and enter the URL: http://192.168.56.112:18080/KunlunXPanel/#/login?redirect=%2Fdashboard.
After logging in, the homepage will appear as follows:
Create a cluster named "Cluster_A". This cluster’s compute node IP is 192.168.56.112 with the service port 47001. It has one storage shard, with the primary node IP at 192.168.56.113 and service ports 57003, 57005, 57007.
4.1 Click "Cluster Management" and then "Cluster List", and on the cluster list interface, click the "Add" button.
4.2 Add a new cluster and specify its business name.
4.3 Select the storage nodes and compute nodes.
4.4 Enable backup encryption for the new cluster.
4.5 Overview of the new cluster.
4.6 Click "Confirm" to review the completion of the cluster creation task.
4.7 Use the same method to create Cluster_B. After setup, view the operational status of Clusters A and B as shown below.
05 Creating an RCR Service
5.1 Click "RCR Service", then click "Add RCR".
5.2 In the new RCR interface, select the appropriate primary metadata cluster and backup metadata cluster, then click "Confirm".
5.3 Complete creating the RCR service.
5.4 View the operational status of the RCR service.
5.5 View the settings for Cluster_A, showing "This cluster has established an RCR relationship".
5.6 View the settings for Cluster_B, displaying "This cluster has established an RCR relationship".
06 Testing RCR Primary and Standby Cluster Data Synchronization
6.1 Open an SSH terminal window connected to 192.168.56.112, log in as the kunlun user, then use the PostgreSQL client to connect to the RCR primary cluster database to create a test table and insert test data. Execute the following commands:
[kunlun@kunlun1 ~]$ psql -h 192.168.56.112 -p 47001 -U abc postgres
CREATE TABLE "public"."product" (
"pro_id" int8 primary key,
"pro_name" varchar(100),
"pro_type" varchar(100),
"price" int8
);
insert into product (pro_id,pro_name,pro_type,price) values (10001,'ipad','padnote',4500);
insert into product (pro_id,pro_name,pro_type,price) values (10002,'ipad8','padnote',6000);
insert into product (pro_id,pro_name,pro_type,price) values (10003,'ipone','phone',8000);
insert into product (pro_id,pro_name,pro_type,price) values (10004,'ipone14','phone',8800);
insert into product (pro_id,pro_name,pro_type,price) values (10005,'notebook','computer',10000);
insert into product (pro_id,pro_name,pro_type,price) values (10006,'notebook2','computer',12000);
select * from product;
The output is displayed as follows:
6.2 Open an SSH terminal window connected to 192.168.56.212, log in as the kunlun user, then use the PostgreSQL client to connect to the RCR standby cluster database, and verify that the tables and data created in the primary cluster database have been synchronized:
[kunlun@kunlun1 ~]$ psql -h 192.168.56.212 -p 47001 postgres
select * from product;
The test results confirm that the tables and data created in the primary cluster database have been synchronized to the standby cluster database.
6.3 Open an SSH terminal window connected to 192.168.56.112, use the PostgreSQL client to connect to the RCR primary cluster database, and then execute update operations:
[kunlun@kunlun1 ~]$ psql -h 192.168.56.112 -p 47001 -U abc postgres
select * from product;
update product set price=9000 where pro_id=10002;
update product set price=8500 where pro_id=10003;
update product set price=9800 where pro_id=10004;
select * from product;
6.4 Open an SSH terminal window connected to 192.168.56.212, use the PostgreSQL client to connect to the RCR standby cluster database, and verify that the update operations on the primary cluster database have been synchronized:
[kunlun@kunlun1 ~]$ psql -h 192.168.56.212 -p 47001 postgres
select * from product;
The test results confirm that the update operations on the primary cluster database have been synchronized to the standby cluster database.
6.5 Open an SSH terminal window connected to 192.168.56.112, use the PostgreSQL client to connect to the RCR primary cluster database, and then execute delete operations:
[kunlun@kunlun1 ~]$ psql -h 192.168.56.112 -p 47001 -U abc postgres
select * from product;
delete from product where pro_id=10001;
delete from product where pro_id=10005;
select * from product;
6.6 Open an SSH terminal window connected to 192.168.56.212, use the PostgreSQL client to connect to the RCR standby cluster database, and verify that the delete operations on the primary cluster database have been synchronized:
[kunlun@kunlun1 ~]$ psql -h 192.168.56.212 -p 47001 postgres
select * from product;
The test results confirm that the delete operations on the primary cluster database have been synchronized to the standby cluster database.
This completes the configuration and data synchronization testing of the RCR service for the primary and standby clusters.