MySQL Cluster Manager 9.2.0 User Manual
This section explains how to back up configuration data for
mcmd agents and how to restore the backed-up
agent data. Used together with the backup
cluster
command, the backup
agents
command allows you to backup and restore a
complete cluster-plus-manager setup.
If no host names are given with the backup
agents
command, backups are created for all agents of
the site:
mcm> backup agents mysite; +-----------------------------------+ | Command result | +-----------------------------------+ | Agent backup created successfully | +-----------------------------------+ 1 row in set (0.07 sec)
To backup one or more specific agents, specify them with the
--hosts
option:
mcm> backup agents --hosts=tonfisk mysite; +-----------------------------------+ | Command result | +-----------------------------------+ | Agent backup created successfully | +-----------------------------------+ 1 row in set (0.07 sec)
If no site name is given, only the agent that the mcm client is connected to is backed up.
The backup for each agent includes the following contents from the
agent repository (mcm_data
folder):
The rep
subfolder
The metadata files high_water_mark
and
repchksum
The repository is locked while the backup are in progress, to
avoid creating an inconsistent backup. The backup for each agent
is created in a subfolder named
rep_backup/
under the agent's timestamp
mcm_data
folder, with
timestamp
reflecting the time the
backup began. If you want the backup to be at another place,
create a soft link from mcm_data/rep_backup
to your desired storage location.
You can list agent backups using the list
backups
command with the
--agent
option and
the site name:
mcm> list backups --agent mysite; +------------+-------+---------+----------------------+-------+--------------+ | BackupId | Agent | Host | Timestamp | Files | Comment | +------------+-------+---------+----------------------+-------+--------------+ | 1522914101 | 0 | tonfisk | 2020-04-05 07:41:41Z | 5 | Agent backup | | 1522914105 | 0 | tonfisk | 2020-04-05 07:41:45Z | 5 | Agent backup | | 1522914121 | 0 | tonfisk | 2020-04-05 07:42:01Z | 5 | Agent backup | +------------+-------+---------+----------------------+-------+--------------+ 3 rows in set (0.00 sec)
To restore the backup for an agent:
Wipe the contents of the agent's
mcm_data/rep
folder
Delete the metadata files
high_water_mark
and
repchksum
from the
mcm_data
folder
Copy the contents in the
mcm_data/rep_backup/
folder back into the timestamp
/repmcm_data/rep
folder
Copy the metadata files high_water_mark
and repchksum
from the
mcm_data/rep_backup/
folder back into the timestamp
mcm_data
folder
Restart the agent
The steps are illustrated below:
mysql@tonfisk$ cd mcm_data mysql@tonfisk$ cp mcm_data/rep_backup/timestamp
/rep/* ./rep/ mysql@tonfisk$ cp mcm_data/rep_backup/timestamp
/high_water_mark ./ mysql@tonfisk$ cp mcm_data/rep_backup/timestamp
/repchksum ./ mysql@tonfisk$ mcm9.2.0/bin/mcmd
The backup may be manually restored on just one, or more than one agents. If backup is restored for only one agent on, say, host A, host A will contact the other agents of the site to make them recover their repositories from host A using the usual mechanism for agent recovery. If all agents on all hosts are restored and restarted manually, the situation will be similar to the normal restarting all agents after stopping them at slightly different points in time.
If configuration changes has been made to the cluster since the
restored backup was created, the same changes must be made again
after the agent restores have been completed, to ensure that the
agents' configurations match those of the actual running cluster.
For example: sometime after a backup was done, a set
MaxNoOfTables:ndbmtd=500 mycluster
command was issued
and soon afterward, something happened and corrupted the agent
repository; after the agent backup was restored, the same
set
command has to be rerun in order to update
the mcmd agents' configurations. While the
command does not effectively change anything on the cluster
itself, after it has been run, a rolling restart of the cluster
processes using the restart
cluster
command is still required.