Recently I happen to work for a MySQL database restore, a pretty exciting task for DBA \ud83d\ude1b<\/p>\n
Well, backup server was already configured with Holland (backup framework) & Xtrabackup (Percona’s backup tool) which made our lives easier with steps to restore.<\/p>\n
Extracted backup command from backup server’s holland.log:<\/p>\n
\n\/usr\/bin\/innobackupex-1.5.1 --defaults-file=\/mysql_backups\/xtrabackup\/20141219_013002\/my.cnf --stream=tar --tmpdir=\/mysql_backups\/xtrabackup\/20141219_013002 --slave-info --no-timestamp \/mysql_backups\/xtrabackup\/20141219_013002 > \/mysql_backups\/xtrabackup\/20141219_013002\/backup.tar.gz 2 > \/mysql_backups\/xtrabackup\/20141219_013002\/xtrabackup.log<\/pre>\n<\/blockquote>\n
\nThe task here is as simple as:
\n– Ship & extract the backup to destination,
\n– Apply-logs (innobackupex –defaults-file=\/path\/my.cnf –apply-log \/path\/datadir\/)
\n– Start database (\/etc\/init.d\/mysqld start),
\n– Setup replication (CHANGE MASTER TO) .<\/p>\nMySQL cameup clean after following all the steps and now it’s time to setup replication.<\/p>\n
The option –slave-info to innobackupex script stores master’s binlog coordinates in a file, xtrabackup_slave_info, which can be used to setup the new server as slave.<\/p>\n
The co-ordinates can also be found in the xtrabackup log shown as follows:<\/p>\n
\ninnobackupex-1.5.1: Backup created in directory '\/mysql_backups\/xtrabackup\/20141219_013002'\r\ninnobackupex-1.5.1: MySQL binlog position: filename 'mysql-bin.002573', position 53014559, GTID of the last change '0-10110111-42499073'\r\ninnobackupex-1.5.1: MySQL slave binlog position: master host '10.1.101.11', gtid_slave_pos 0-10110111-42499073\r\n141219 04:55:16\u00a0 innobackupex-1.5.1: Connection to database server closed\r\ninnobackupex-1.5.1: You must use -i (--ignore-zeros) option for extraction of the tar stream.\r\n141219 04:55:16\u00a0 innobackupex-1.5.1: completed OK!<\/em><\/pre>\n<\/blockquote>\n