This document describes the mirror node (Mirror) addition tool mxaddmirrors.
mxaddmirrors tool enables adding Mirrors to a YMatrix system that was initially deployed without Mirrors, and starts the online replication process between primary segments (Primary) and their corresponding Mirrors.Note!
During the mirror addition process, the database must be idle. Workloads and other queries should not be running.
Below is a detailed description of the command-line arguments:
| Subcommand | Parameter | Description | Optional |
|---|---|---|---|
| config | Creates a custom configuration file | ||
| --db-cluster-id | Database cluster ID. Used to identify a unique database cluster | Optional | |
| --filename | Saves the generated configuration to this file. If the file does not exist, it will be created automatically. Redirection can also be used | Optional | |
| init | Converts collected information into a basic plan | ||
| --db-cluster-id | Database cluster ID. Stored in the /etc/matrixdb5/cluster.conf file. Use the last ClusterID if only one cluster is deployed; otherwise, select the appropriate --db-cluster-id for the target cluster |
Required | |
| --mirror-port-base | Starting port from which to search for an available port for Mirror to listen on. Defaults to searching from 7000 |
Optional | |
| plan | Generates a deployment plan | ||
| --init-file | Absolute path to the redirected output file from the init command |
Required | |
| --custom-config | Absolute path to the file generated by the config command |
Optional | |
| setup | Executes the deployment | ||
| --plan-file | Absolute path to the redirected output file from the plan command |
Required |
Note!
Only required parameters need to be specified if default behaviors are acceptable.
The mxaddmirrors command must be executed by a user with sudo privileges on the Master host (except for mxadmin, use absolute path /opt/ymatrix/matrixdb5/bin/mxaddmirrors). If the mxaddmirrors init command is mistakenly run under a non-sudo user, the mxaddmirrors.init file will be generated under that user's context, readable but not writable by others. You must delete this file and re-run the command under a sudo-enabled user to regenerate it.
Two usage workflows are provided: one using default behavior and another with custom configuration. Details are as follows:
Note!
Choose either 3.1 or 3.2. The default behavior uses YMatrix’s default Ring mirror placement policy. With custom configuration, you can adjust the mirror layout as needed. Regardless of the method chosen, a complete mirror addition workflow must be followed.
Collect host and partial database deployment information.
$ mxaddmirrors init > /tmp/mxaddmirrors.init
Generate a deployment plan based on the collected information—this outlines the exact deployment steps.
$ mxaddmirrors plan --init-file /tmp/mxaddmirrors.init > /tmp/mxaddmirrors.plan
Execute the deployment.
$ mxaddmirrors setup --plan-file /tmp/mxaddmirrors.plan --mode cli
Save the generated configuration to the config file. If the file does not exist, it will be created automatically.
$ mxaddmirrors config --filename /tmp/config
Edit the config file.
$ edit config
Collect host and partial database deployment information.
$ mxaddmirrors init > /tmp/mxaddmirrors.init
Generate a deployment plan using the collected data and the custom configuration.
$ mxaddmirrors plan --init-file /tmp/mxaddmirrors.init --custom-config /tmp/config > /tmp/mxaddmirrors.plan
Execute the deployment.
$ mxaddmirrors setup --plan-file /tmp/mxaddmirrors.plan --mode cli
The generated configuration file is in CSV format:
0||7000|
1||7000|
content_id, hostname, port, and rootdir of datadir (used to create directories and files for databases).content_id must not be empty and must be unique. All modified options take effect immediately—what you see is what you get.Note!
YMatrix 5 introduces a new database architecture. Use themxaddmirrorstool to add Mirrors. It is not compatible withgpaddmirrors. Earlier versions usedgpaddmirrors.