8.7.3. Restoring from Another Slave

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 master or a slave and is faster if you do not already have a backup ready to be restored. For more information, see Section 8.5, “Provision or Reprovision a Slave”.

Data can be restored to a slave by performing a backup on a different slave, transferring the backup information to the slave you want to restore, and then running restore process.

For example, to restore the host3 from a backup performed on host2 :

  1. Run the backup operation on host2 :

    shell> trepctl backup
    Backup of dataSource 'host2' succeeded; uri=storage://file-system/store-0000000006.properties
  2. Copy the backup information from host2 to host3. See Section E.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/backups
    shell> 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/xtrabackup
    shell> rsync -aze ssh full_xtrabackup_2014-08-16_15-44_86 host3:$PWD/
  3. Put the replication service offline using trepctl:

    shell> trepctl offline
  4. Restore the backup using trepctl restore :

    shell> trepctl restore

    Note

    Check 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.

  5. Put the replication service online using trepctl:

    shell> trepctl online