Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Optimize replication-between-clusters #1389

Merged
merged 1 commit into from
May 24, 2022
Merged

Optimize replication-between-clusters #1389

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions docs-2.0/synchronization-and-migration/replication-between-clusters.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Synchronize between two clusters

Nebula Graph supports data synchronization from a primary to a secondary cluster in almost real-time. It applies to scenarios such as disaster recovery and load balancing, and helps reduce the risk of data loss and enhance data security.
Nebula Graph supports data synchronization from a primary cluster to a secondary cluster in almost real-time. It applies to scenarios such as disaster recovery and load balancing, and helps reduce the risk of data loss and enhance data security.

!!! enterpriseonly

Expand Down Expand Up @@ -76,7 +76,7 @@ The test environment for the operation example in this topic is as follows:

1. Install Nebula Graph on all the machines.

For installing Nebula Graph, see the instructions in the [Compile and install Nebula directory](../4.deployment-and-installation/2.compile-and-install-nebula-graph/2.install-nebula-graph-by-rpm-or-deb.md).
For installation instructions, see [Install Nebula Graph](../4.deployment-and-installation/2.compile-and-install-nebula-graph/2.install-nebula-graph-by-rpm-or-deb.md).

2. Modify the configuration files on all the machines.

Expand Down Expand Up @@ -386,9 +386,11 @@ The schema data is synchronized through the Meta listener, while the vertex/edge

### How to deal with synchronization failures?

- If problems happen on the primary cluster, the synchronization will be paused. Fixing the problems and then restarting the primary cluster can continue the synchronization.
Fix the problems in the cluster, and the synchronization will be automatically restored.

- If problems happen on the secondary cluster, listeners or drainers, when the problem is fixed, the services that had the problems will receive the WALs accumulated from its upstream and the synchronization will continue. If the faulty machine is replaced with a new one, all the data of the synchronization services on the faulty machine must be copied to the new machine. Otherwise, the synchronization of the complete data set starts.
- If problems happened on the primary cluster, the synchronization would continue when the problems were fixed and the primary cluster restarted.

- If problems happened on the secondary cluster, listeners, or drainers, when the problems were fixed, the services that had the problems would receive the WALs accumulated from its upstream and the synchronization would continue. If the faulty machine were replaced with a new one, all the data of the synchronization services on the faulty machine must be copied to the new machine. Otherwise, the synchronization of the complete data set would start automatically.

### How to check the data synchronization status and progress?

Expand All @@ -400,4 +402,4 @@ Find the WALs that has just been synchronized, and that has most recently been g
- Compare the log ID to view the synchronization gap.
-->

There is no tool specially designed to do this for now.
There is no tool specially designed to show the real-time status and overall progress of the synchronization for now.