If a restore is being performed as part of the recovery procedure, consider using the tungsten_provision_slave tool. This is 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 Section 7.6, “Provision or Reprovision a 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 :
shell> trepctl backup
Backup of dataSource 'host2' succeeded; uri=storage://file-system/store-0000000006.properties
Copy the backup information from
host2 to
host3. See
Section D.1.1.3, “Copying Backup Files” for more information
on copying backup information between hosts. If you are using
xtrabackup there will be additional files needed
before the next step. The example below uses scp to
copy a mysqldump backup:
shell>cd /opt/continuent/backupsshell>scp store-[0]*6[\.-]* host3:$PWD/store-0000000006-mysqldump-812096863445699665.sql 100% 234MB 18.0MB/s 00:13 store-0000000006.properties 100% 314 0.3KB/s 00:00
If you are using xtrabackup:
shell>cd /opt/continuent/backups/xtrabackupshell>rsync -aze ssh full_xtrabackup_2014-08-16_15-44_86 host3:$PWD/
Put the replication service offline using trepctl:
shell> trepctl offlineRestore the backup using trepctl restore :
shell> trepctl restoreCheck 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.
Put the replication service online using trepctl:
shell> trepctl online