mxmoveseg

This document introduces the Mirror Mirror migration tool mxmoveseg.

Notes!
mxmoveseg is only used to migrate node instances in the gp_segment_configuration table with a role (current role) of m (mirror) and has nothing to do with the preferred_role (original role) column.

1 Description

Function
- The mxmoveseg tool supports migration of any currently Mirror database instance to another server.
Scene
- The current server cluster can run normally, but load imbalance affects performance and stability, and needs to be adjusted by migrating Mirror between different machines.
- The server is currently offline and Mirror needs to be migrated to a healthy new server to ensure the operation of the cluster.
limit
- The mxmoveseg tool does not support migration of Standby.

Notes!
Before using this tool, you need to judge whether all servers are healthy by yourself. If there is an absolute server, you also need to understand which servers are the absolute to ensure that all healthy servers can be collected by mxmoveseg.

2 Command line parameter information

The following is a detailed command line parameter information:

Parameter name	Description
--config	Create a configuration file for the Mirror to be migrated
--plan	Create a migration plan for the Mirror to be migrated
--setup	Perform plan steps to implementation migration
-h / --help	Print Help Information

3 Examples

3.1 Migrate an existing Segment to a new server

Notes!
The new server needs to install the RPM/DEB package of the same version of YMatrix according to the YMatrix related deployment documents, but the steps to initialize the new cluster in the graphic interface cannot be implemented.

Notes!
A new server can have a YMatrix cluster that is different from the old server (for example, a cluster with YMatrix 4.8 on the old machine and a cluster with YMatrix 5.1 on the new machine).

Collect information about the current database cluster. clusterid can be viewed using more /etc/matrixdb5/cluster.conf.

[<username>@<Master hostname> ~]$ sudo /opt/ymatrix/matrixdb5/bin/mxctl expand init --cluster-id <clusterid> --unrestrict > /tmp/init

Add a new server.

[<username>@<Master hostname> ~]$ cat /tmp/init | sudo /opt/ymatrix/matrixdb5/bin/mxctl expand add --unrestrict --host <newhost> > /tmp/initadd

Check whether the network is connected between the servers that collect information.

[<username>@<Master hostname> ~]$ cat /tmp/initadd | sudo /opt/ymatrix/matrixdb5/bin/mxctl expand netcheck > /tmp/netcheck

Switch to mxadmin user.

[<username>@<Master hostname> ~]$ sudo su - mxadmin

Create a migration configuration file and configure the instances to be migrated based on the information prompted by the generated file.

$ mxmoveseg config --db-cluster-id <clusterid> --filename /tmp/migrate.cfg

# After the configuration file is created, please manually edit the dbid of the node instance that needs to be migrated according to the prompt information in the file content (after connecting to the database, execute SELECT * FROM gp_segment_configuration; view dbid), host name, etc. SPEC: If the new server has a port conflict with the old server, you need to assign a new port in the file.
$ vim /tmp/migrate.cfg

Generate a migration plan.

$ mxmoveseg plan --init-file /tmp/netcheck --config-file /tmp/migrate.cfg > /tmp/plan

Perform a migration.

$ mxmoveseg setup --plan-file /tmp/plan --mode cli

After the migration is successful, you can use the graphic interface: Cluster Management - Cluster Overview - Instance View or use the SELECT * FROM gp_segment_configuration SQL statement to view the status of the migrated Mirror.

Warning! If the source migration server is offline, the offline old server cannot be restarted even after the migration is completed. If enabled, the old management process will be automatically pulled up, and there will be a conflict with the new management process that will cause cluster exceptions.

3.2 Migrate an existing segment to the old server