Main-subsidy switching method

Note! Disaster recovery capability is only available as an experimental feature in YMatrix 6.0.0.

When a disaster occurs, if all machines on the main cluster side are physically unavailable, the user can only operate on the backup cluster side.

After the main and backup switch is completed, the data content of the backup cluster is not consistent with the main cluster, and it cannot be switched back to the backup cluster role again.

Operation backup cluster

On the Master machine in the backup cluster, as the user of mxadmin, execute the mxdr switch or mxdr switch -a command to switch the master and backup.

a. If you use mxdr switch to switch, the following conversation will occur. You need to confirm again whether the main and backup switch is performed.
```
 Continue promoting cluster for disaster recovery to normal cluster? Yy|Nn (default=N):
```
b. If you use mxdr switch -a to switch, you can skip the above dialogue confirmation process.

Operation Publisher

On the Publisher machine, execute the following command as the mxadmin user to get the name of the Publisher managed by the supervisor.
```
supervisorctl status
```
The output result is shown in the figure below. In this example, the name is publisher_5V967HARnCHfRMTeyiLQgS.

dr_switch_1

After obtaining name, execute the following command to stop Publisher.
```
supervisorctl stop publisher_5V967HARnCHfRMTeyiLQgS
```
Finally, execute the following command to check whether the Publisher status becomes exited.
```
supervisorctl status
```
Example:

dr_switch_2

Use of the database cluster after switching

After the disaster recovery switch, the YMatrix database cluster of the backup cluster switches to provide normal services to the main cluster role. At this time, the use of the cluster is the same as the normal use of the YMatrix database cluster.
The application of the database service can switch to the main cluster connected to the main and standby switch to continue normal service.
If there is a high availability requirement for the cluster, you can add standby and mirror segments to implement the high availability functionality of the YMatrix database cluster.

Remark

Command Line Tools

This section provides command-line operation tools for disaster recovery capabilities.

mxdr

The mxdr command is used to run Subscriber and Publisher, as well as to control the switchover of the backup database cluster.

  Usage:
    mxdr [flags]
    mxdr [command]

  Available Commands:
    completion Generate the autocomplete script for the specified shell
    help Help about any command
    switch Promote disaster recovery cluster

  Flags:
    -c, --config-file string path of the configuration file to start up
    -h, --help help for mxdr
    -s, --shard-cnt int number of shards of the source database cluster
    -v, --version version for mxdr

mxbox deployer dr

mxbox deployer dr is used to deploy disaster recovery components and backup clusters.

  Usage:
    mxbox deployer dr [command]

  Available Commands:
    pub Publisher deployer for dr

  Flags:
    -h, --help help for dr

    Usage:
      mxbox deployer dr pub [command]

    Available Commands:
      config Generate a config template file
      plan Generate plan for migrating host.
      setup Execute steps to deploy physical publisher.

    Flags:
      -h, --help help for pub

Known Issues

Cluster expansion without adding shards The current disaster recovery function does not support the situation where the database cluster topology changes, so it does not support the cluster expansion with additional shards.
The read-only query results of the backup cluster are not guaranteed to be consistent Data consistency in the backup cluster is only valid at global consistency points.
After the backup cluster is switched to a global consistency point after the disaster occurs, it will switch to a global consistency point to ensure the final consistency of the backup data. However, during the data backup process, although the backup cluster supports read-only query, the log playback synchronization granularity of each data slice is only controlled at the location of the global consistency point, and the correctness of the query results at any time cannot be guaranteed.