KlustronDB RCR 使用手册

01 Background Requirements

The purpose of this document is to help customers better use the KlustronDB database. The KlustronDB database supports data synchronization between clusters (remote cluster replication), hereinafter referred to as RCR.

The KlustronDB distributed database, in order to support high availability across cities, establishes an RCR relationship between the backup city cluster and the main city cluster to achieve real-time data synchronization. When the main city experiences an exception, it switches to the backup city to continue providing external services.

02 Principle of Implementation

2.1 Principle

KlustronDB data cross-city data synchronization, including two parts of data synchronization:

Data synchronization between shards is implemented based on MySQL binlog master-slave replication.
The metadata synchronization of the KlustronDB cluster involves synchronizing data needed by Kluscomp instances, specifically the distribution information of database tables. This synchronization is carried out using the binlog_sync tool. Binlog_sync connects to the metashard of the master cluster via the binlog_dump method, and after capturing the binlog changes, it maps the shard ID information in the binlog records before writing them into the metadata tables of the backup cluster.

2.2 Precautions

1. The number of primary and standby shards must be kept consistent

2. The primary and standby cluster_mgr networks must be able to communicate with each other

3. xpanel must be able to communicate with the metashard network

03 KlustronDB Version & Cluster Machine Configuration

KlustronDB Version	1.2.1

| Cluster Name | Cluster_A | | ------------- | ------------------------------- | --------------------------------------------- | | Machine IP | Machine Configuration | Components | | 172.16.0.15 | CentOS7.9 32C 128G 1T2nvme ssd | Meta Node Data Node Kluscomp instance Xpanel | | 172.16.0.16 | CentOS7.9 32C 128G 1T2nvme ssd | Meta Node Data Node Kluscomp instance | | 172.16.0.17 | CentOS7.9 32C 128G 1T*2nvme ssd | Meta Node Data Node Kluscomp instance |

| Cluster Name | Cluster_B | | ------------- | ------------------------------- | --------------------------------------------- | | Machine IP | Machine Configuration | Components | | 172.16.1.18 | CentOS7.9 32C 128G 1T2nvme ssd | Meta Node Data Node Kluscomp instance Xpanel | | 172.16.1.19 | CentOS7.9 32C 128G 1T2nvme ssd | Meta Node Data Node Kluscomp instance | | 172.16.1.20 | CentOS7.9 32C 128G 1T*2nvme ssd | Meta Node Data Node Kluscomp instance |

04 Data Synchronization Between Clusters

4.1 Data synchronization between clusters managed under the local xpanel

4.1.1 Add RCR

First, create two cluster clusters, named cluster_A and cluster_B, as shown in the figure below:

After successfully creating the cluster, the information of the two clusters is displayed in the cluster list as shown in the figure below:

In the cluster management list, click 'RCR Service', and then click the 'Add RCR' button as shown in the figure:

Add metadata node information corresponding to Cluster_A and Cluster_B respectively

Metadata information added successfully

After the metadata is successfully added, check the values of each attribute in the RCR service list. A status value of 'Running' indicates that a new set of data synchronization between clusters has been successful.

4.1.2 Verify Data Synchronization

Test data synchronization, Cluster_A Kluscomp instance writing data

PGPASSWORD=abc psql -h 127.16.0.16 -U abc -p 47001 -d postgres

Querying the Kluscomp instances in Cluster_B shows that the data has been successfully synchronized (Note: At this time, Cluster_B acts as the backup cluster and writing is not allowed; related data can be queried)

PGPASSWORD=abc psql -h 127.16.1.20 -U abc -p 47001 -d postgres

4.1.3 Verify Data Consistency

To further verify the accuracy and consistency of the data, use the MySQL protocol to access the Kluscomp instance and check the md5 values in the table data

mysql -uabc -pabc -h172.16.0.16 -P47002

Use the MySQL protocol to log in to the Kluscomp instance and verify the md5 values in the table data

mysql -uabc -pabc -h172.16.1.20 -P47002

Its result is exactly the same as the md5 value of the data corresponding to the main Cluster_A cluster.

4.1.4 Delayed Replication Settings

Delayed replication settings, this function is similar to MySQL delayed replication, where Cluster_A waits for a certain number of seconds before data is synchronized to Cluster_B

4.1.5 Delete RCR

Establish RCR relationships between clusters. Clusters cannot be deleted; they can only be deleted after unbinding the relationship. Note: Be cautious when deleting clusters in a production environment.

4.1.6 Switch RCR

When the primary cluster experiences an exception for some reason (Cluster_A) or due to certain changes the business needs to be switched to the backup cluster (Cluster_B), manual cluster switching is required. The specific operations are as follows:

Click 'Details' before switching to check the replication information corresponding to the primary and standby.

Verify data accuracy after switching

Modify information on the main cluster for Cluster_B (previously standby before the switch, now primary), and log in to the main cluster Kluscomp instance

PGPASSWORD=abc psql -h 127.16.1.20 -U abc -p 47001 -d postgres

Modify information on the standby cluster Cluster_A (previously the primary before the switch, now the standby), log in to the standby cluster Kluscomp instance

PGPASSWORD=abc psql -h 127.16.0.15 -U abc -p 47001 -d postgres

Data query is consistent

To further verify data consistency, use the MySQL protocol to log in to the master-slave cluster Kluscomp instances for queries respectively

mysql -uabc -pabc -h172.16.1.20 -P47002

mysql -uabc -pabc -h172.16.0.15 -P47002

The results show that the MD5 values of the queried data are exactly the same.

4.1.7 Start/Stop RCR

Stop RCR

Start RCR

The status of the property list will change accordingly when stopping and starting.

4.1.8 RCR Add/Delete Shard

When creating an RCR relationship, the number of shards between the primary and standby clusters must be consistent. If any cluster in the RCR relationship adds or deletes a shard, the system will automatically add or delete shards in the corresponding cluster according to the RCR relationship.

Add a shard to the main cluster, as shown in the figure below:

After the primary successfully added the shard, the backup cluster also added the corresponding shard node.

The delete operation is the same, and will not be demonstrated here again.

4.2 Data synchronization between clusters managed under non-local xPanel

Previously, we introduced data synchronization between clusters managed by the local xpanel (i.e., all clusters share the same metashard). Below, we introduce data synchronization between clusters managed by different xpanels (i.e., all clusters are not in the same metashard). Before data synchronization, they are logically unrelated.

4.2.1 Data Preparation

http://192.168.0.125:18080/KunlunXPanel/open in new window manage one cluster, for Cluster_A

http://192.168.0.128:18080/KunlunXPanel/ Manage 1 cluster, for Cluster_B

4.2.2 Add RCR

In the cluster management list, click 'RCR Service', and then click the 'Metadata Management' button as shown in the figure:

Add metadata information of the backup cluster to the newly added metadata list

After the addition is successful, the corresponding information just added will be displayed in the metadata list as shown in the figure below:

In the cluster management list, click 'RCR Service', and then click the 'Add RCR' button as shown in the figure:

Add metadata node information corresponding to Cluster_A and Cluster_B respectively

After successfully adding a new RCR, the list information is displayed as follows:

Click 'Details' to view the relevant synchronization information:

Other functions are the same as the local xpanel cluster synchronization function, and will not be repeated!