RESTORE to Resolve Replication Issues with MariaDB Xpand
Fast Backup and Restore can also be used to resolve the following issues in replicated environments.
MariaDB Xpand 5.3
MariaDB Xpand 6.0
MariaDB Xpand 6.1
Scenario I : Xpand slave does not exist or needs to be reset with master.
Take a fresh backup using
BACKUPsql command on master. This will minimize the time it will take for the slave to catch up if older backups were to be used.
Stop the slave if one already exists. If none exists as yet, see "Configure MariaDB Xpand as a Replication Slave" for steps to create a new Xpand slave and leave it in stop mode after successful creation.
Restore backup taken in step 1 on slave using
Master's binlog position when backup initiates is stored under
your_backup_location/metadata/binlogsfile. This file contains relevant information in the format
logfile.seq#:position, for example,
Reset the position recorded in the binlogs file by issuing the command:
sql> CHANGE MASTER TO MASTER_LOG_FILE = 'foo1.002843',
MASTER_LOG_POS = 99744547, MASTER_HOST = 'foo1',
MASTER_USER = 'root', MASTER_PORT = 3306;
Start the slave.
Scenario II: Xpand Master needs to be restored, Xpand Slave looks good.
Promote Xpand slave to act as master. Please refer to "Configure Replication Failover with MariaDB Xpand" for the necessary steps to promote a passive Xpand slave to an active Master mode.
Follow steps outlined in Scenario I to restore and reset the old master which is now in passive slave mode.
If necessary, repeat the steps to switch over the current passive slave to active master once both master and slave are fully caught up.
Scenario III: Xpand Master and Slave both need to be restored and reset.
Stop the slave.
Restore the master and slave using
Reset the slave to the current position of the master (i.e., from
SHOW MASTER STATUSon the master), after the restore, before it begins taking writes from clients. Note that using this technique, you are losing incremental changes since the backup. An advanced method to capture the incremental changes since backup would be to replay the binlogs if they are still available, and change the
serveridof the master, in order to have it reapply the events in the binlog. Please contact MariaDB Support for assistance with this advanced procedure.
Start the slave.
If you receive the following timeout error during the backup process, "Socket timeout while waiting for server response: read_
3000, to prevent this error. This global applies to backups and restores of both FTP and SFTP servers.