Restoring from Another Replica
If a restore is being performed as part of the recovery procedure, consider using the tprovision tool. This will work for restoring from the Primary or
a Replica and is faster if you do not already have a backup ready to be restored.
For more information, see "Recover a failed Replica"
Data can be restored to a Replica by performing a backup on a different Replica, transferring the backup information to the Replica you want to restore, and then running restore process.
For example, to restore the host3 from a backup performed on host2:
Run the backup operation on
host2:[LOGICAL:EXPERT] /alpha > datasource host2 backupUsing the 'xtrabackup' backup agent.Replicator 'host2' starting backupBackup of dataSource 'host2' succeeded; uri=storage://file-system/store-0000000006.propertiesCopy the backup information from
host2tohost3. See "Copying Backup Files" for more information on copying backup information between hosts. If you are usingxtrabackupthere will be additional files needed before the next step. The example below usesscpto copy amysqldumpbackup:shell> cd /opt/continuent/backupsshell> scp store-[0]*6[.-]* host3:$PWD/store-0000000006-mysqldump-812096863445699665.sql 100% 234MB 18.0MB/s 00:13store-0000000006.properties 100% 314 0.3KB/s 00:00If you are using
xtrabackup:shell> cd /opt/continuent/backups/xtrabackupshell> rsync -aze ssh full_xtrabackup_2014-08-16_15-44_86 host3:$PWD/Shun the datasource to be restored, and put the replicator service offline using
cctrl:[LOGICAL] /alpha > datasource host2 shun[LOGICAL] /alpha > replicator host2 offlineRestore the backup using
cctrl:[LOGICAL] /alpha > datasource host2 restoreOnce the restore operation has completed, the datasource will be placed into the online state.
NoteCheck the ownership of files if you have trouble transferring files or restoring the backup. They should be owned by the Tungsten system user to ensure proper operation.