使用XtraBackup恢复|备份Mysql数据库--数据恢复篇-创新互联
数据恢复篇
XtraBackup工具介绍：
现在我们给MySQL做备份的时候经常会考虑到数据量的增长,数据量较小的时候用mysqldump,随着数据量越来越大mysqldump也就不太合适了.第一不支持增量备份,第二恢复的时候也较慢.这里推荐使用Percona公司的XtraBackup.
简单介绍一下热备份工具XtraBackup,它是Percona公司推出的一款热备份工具,备份的时候不影响数据读写操作,是商业工具HotBackup的一个替代(现在应该叫MySQL Enterprise Backup这个工具不止可以备份InnoDB还可以备份MyISAM等等)
XtraBackup有两个工具:xtrabackup和innobackupex.
xtrabackup本身只能备份InnoDB和XtraDB,不能备份MyISAM.
innobackupex本身是Hot Backup脚本修改而来,同时可以备份MyISAM和InnoDB,但是备份MyISAM需要加读锁.
#安装percona-xtrabackup rpm软件包。
[root@localhost data]# rpm -ivh percona-xtrabackup-2.3.2-1.el6.x86_64.rpm warning: percona-xtrabackup-2.3.2-1.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY error: Failed dependencies: libev.so.4()(64bit) is needed by percona-xtrabackup-2.3.2-1.el6.x86_64 perl(DBD::mysql) is needed by percona-xtrabackup-2.3.2-1.el6.x86_64#安装依赖：
yum install perl-DBD-MySQL#安装libev包
到http://rpmfind.net/linux/rpm2html/search.php?query=libev.so.4%28%29%2864bit%29&submit=Search+...&system=&arch= 下载操作系统对应的libev包，注意系统号与版本位数
[root@master ~]# wget ftp://rpmfind.net/linux/dag/redhat/el6/en/x86_64/dag/RPMS/libev-4.15-1.el6.rf.x86_64.rpm --2016-05-17 12:54:43-- ftp://rpmfind.net/linux/dag/redhat/el6/en/x86_64/dag/RPMS/libev-4.15-1.el6.rf.x86_64.rpm => “libev-4.15-1.el6.rf.x86_64.rpm” Resolving rpmfind.net... 195.220.108.108 Connecting to rpmfind.net|195.220.108.108|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /linux/dag/redhat/el6/en/x86_64/dag/RPMS ... done. ==> SIZE libev-4.15-1.el6.rf.x86_64.rpm ... 74692 ==> PASV ... done. ==> RETR libev-4.15-1.el6.rf.x86_64.rpm ... done. Length: 74692 (73K) (unauthoritative) 100%[===============================================================================================================>] 74,692 187K/s in 0.4s 2016-05-17 12:54:46 (187 KB/s) - “libev-4.15-1.el6.rf.x86_64.rpm” saved [74692]安装RHEL6对应的libev-4.15-1.el6.rf.x86_64.rpm包
[root@master ~]# rpm -ivh libev-4.15-1.el6.rf.x86_64.rpm warning: libev-4.15-1.el6.rf.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 6b8d79e6: NOKEY Preparing... ########################################### [100%] 1:libev ########################################### [100%]#安装percona-xtrabackup软件包：
[root@localhost data]# rpm -ivh percona-xtrabackup-2.3.2-1.el6.x86_64.rpm warning: percona-xtrabackup-2.3.2-1.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY Preparing... ########################################### [100%] percona-xtrabackup ########################################### [100%]操作过程如图：
#备份恢复时数据库必须停止的。
[root@localhost ~]# /etc/init.d/mysqld stop Shutting down MySQL.. [ OK ]#上篇fpm封装好的二进制mysql，纯净。
注意：备份时候MySQL必须是运行状态，而在做数据恢复时候服务必须是处于停滞状态。
重要参数：
--defaults-file=/etc/my.cnf：备份时，指定配置文件
--socket=/tmp/mysql.sock：备份时，连接到备份的mysql服务器所使用的 套接字文件
--user=root：连接备份mysqld所使用的用户
--password=hello：连接备份mysqld所使用的用户密码
--no-timestamp：默认情况下，备份目录会使用以当前时间为名称创建一个备份目录，加上此参数则不会做这个动作
--apply-log：创建ib_logfile文件，并恢复备份期间产生的redo日志到ib_logfile和表空间中。注意：若备份期间产生了提交的事务日志，则apply-log操作会将未提交的事务回滚
--copy-back：执行恢复数据到目标mysqld，但是目标mysqld的数据目录不 能用—datadir指定，这一点不同与meb，而是需要使用—defaults-file指 定一个配置文件，在配置文件中指定恢复的datadir。与meb不同，恢复前必 须清空目录数据目录
--use-memory=1G：备份时xtrabackup可用的内存大小，取决于操作系统可用的内存量，默认为100M，使用大的内存可加速备份的速度
--incremental：表示为增量备份，增量备份只对innodb表有效，对于non-innodb表，例如myisam则无效，因为每次增量备份都会拷贝myisam相关的所有文件，不管上次备份到这次备份有没有发生更改；而对于innodb表，增量备份则只会备份上次备份到这次备份所更改的表
--incremental-basedir=/lxw/full-back/：基于上一次的备份目录做增量 备份
--incremental-dir=/lxw/incr-backup/：用于将增量备份恢复到全备时指定增量备份的目录
--redo-only：增量备份恢复到之前的备份时，除了最后一个增量备份外，其他的增量备份最好指定该参数
--databases=’dba.t1 mysql performance_schema lxw.t1’：用于部分备份，可以用空格分开，指定备份哪些库的所有表，或者哪些库的某些表
--export：在执行apply-log操作时，将应用信息保存到文件中，在恢复部分备份时有用
--compact：采用压缩备份
--rebuild-indexes：解压缩
----记录备份信息(如备份命令、备份开始和完成时间、binlog position、备份开始和完成的lsn等
注意：备份使用的innobackupex是2.3.1 恢复可以使用innobackupex2.3.x等小版本，但是不能夸大版本，否则会有问题。
新建一个数据目录，和原数据目录同样的名字：
mkdir /data/mysqldata#为了练习使用percona-xtrabackup全量备份了线上的mysql，scp到新机器上恢复练习。
备份完备份的时间目录下都有xtrabackup_info 文件，记录了你备份时的动作。
[root@localhost 2017-03-27_04-00-01]# cat xtrabackup_info uuid = c4c25074-1260-11e7-9a6a-069e3400093a name = tool_name = innobackupex tool_command = --defaults-file=/etc/my.cnf --socket=/usr/local/mysql56/data/mysqld.sock --host=localhost --user=backuser --password=... /usr/local/mysql56/mysql_data_backup/o2o/full_backup/ tool_version = 2.3.3#工具的版本 ibbackup_version = 2.3.3 server_version = 5.6.25-log start_time = 2017-03-27 04:00:02 end_time = 2017-03-27 04:14:08 lock_time = 0 binlog_pos = filename 'mysql-bin.000285', position '764217961' innodb_from_lsn = 0 innodb_to_lsn = 393358640191 partial = N incremental = N format = file compact = N compressed = N encrypted = N#首先恢复事务，也可以加--user=：
[root@localhost data]# innobackupex --apply-log --use-memory=10M 2017-03-27_04-00-01/ 170331 01:28:54 innobackupex: Starting the apply-log operation IMPORTANT: Please check that the apply-log run completes successfully. At the end of a successful apply-log run innobackupex prints "completed OK!". innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 306a2e0) xtrabackup: cd to /data/2017-03-27_04-00-01/ xtrabackup: This target seems to be not prepared yet. xtrabackup: xtrabackup_logfile detected: size=26689536, start_lsn=(393334934174) xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 1 xtrabackup: innodb_log_file_size = 26689536 xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 1 xtrabackup: innodb_log_file_size = 26689536 xtrabackup: Starting InnoDB instance for recovery. xtrabackup: Using 10485760 bytes for buffer pool (set by --use-memory parameter) InnoDB: Using atomics to ref count buffer pool pages InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw_locks use GCC atomic builtins InnoDB: Memory barrier is not used InnoDB: Compressed tables use zlib 1.2.3 InnoDB: Using CPU crc32 instructions InnoDB: Initializing buffer pool, size = 10.0M InnoDB: Completed initialization of buffer pool InnoDB: Highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 393334934174 InnoDB: Database was not shutdown normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages InnoDB: from the doublewrite buffer... InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Doing recovery: scanned up to log sequence number 393340176896 (22%) InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Doing recovery: scanned up to log sequence number 393345419776 (44%) InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Doing recovery: scanned up to log sequence number 393350662656 (66%) InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Doing recovery: scanned up to log sequence number 393355905536 (88%) InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Doing recovery: scanned up to log sequence number 393358640191 (99%) InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: 128 rollback segment(s) are active. InnoDB: Waiting for purge to start InnoDB: 5.6.24 started; log sequence number 393358640191 xtrabackup: Last MySQL binlog file position 764217961, file name mysql-bin.000285 xtrabackup: starting shutdown with innodb_fast_shutdown = 1 InnoDB: FTS optimize thread exiting. InnoDB: Starting shutdown... InnoDB: Shutdown completed; log sequence number 393358641472 xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 2 xtrabackup: innodb_log_file_size = 50331648 InnoDB: Using atomics to ref count buffer pool pages InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw_locks use GCC atomic builtins InnoDB: Memory barrier is not used InnoDB: Compressed tables use zlib 1.2.3 InnoDB: Using CPU crc32 instructions InnoDB: Initializing buffer pool, size = 10.0M InnoDB: Completed initialization of buffer pool InnoDB: Setting log file ./ib_logfile101 size to 48 MB InnoDB: Setting log file ./ib_logfile1 size to 48 MB InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0 InnoDB: New log files created, LSN=393358641472 InnoDB: Highest supported file format is Barracuda. InnoDB: 128 rollback segment(s) are active. InnoDB: Waiting for purge to start InnoDB: 5.6.24 started; log sequence number 393358641676 xtrabackup: starting shutdown with innodb_fast_shutdown = 1 InnoDB: FTS optimize thread exiting. InnoDB: Starting shutdown... InnoDB: Shutdown completed; log sequence number 393358644153 170331 01:29:33 completed OK!#恢复数据，也可以加--defaults-file=/etc/my.cnf --rsync 也可以去掉
innobackupex --copy-back --rsync 2017-03-27_04-00-01/ ........ ......... 170331 03:03:04 [01] ...done 170331 03:03:04 [01] Copying ./ecos_notice/tbl_notice_file.ibd to /data/mysqldata/ecos_notice/tbl_notice_file.ibd 170331 03:03:04 [01] ...done 170331 03:03:04 [01] Copying ./stest/tbl_test_user_info.ibd to /data/mysqldata/stest/tbl_test_user_info.ibd 170331 03:03:04 [01] ...done 170331 03:03:04 [01] Copying ./stest/tbl_test_user_info.frm to /data/mysqldata/stest/tbl_test_user_info.frm 170331 03:03:04 [01] ...done 170331 03:03:04 [01] Copying ./stest/db.opt to /data/mysqldata/stest/db.opt 170331 03:03:04 [01] ...done 170331 03:03:04 completed OK!授权恢复数据的目录为mysql用户和mysql组：
[root@localhost data]# ll total 5624 drwx------ 14 root root 4096 Mar 31 02:33 2017-03-27_04-00-01 -rw-r--r-- 1 root root 74692 Mar 31 01:10 libev-4.15-1.el6.rf.x86_64.rpm drwxr-xr-x 13 mysql mysql 4096 Mar 31 02:42 mysql drwxr-xr-x 14 root root 4096 Mar 31 03:03 mysqldata drwxr-xr-x 2 mysql mysql 4096 Mar 31 02:47 mysqldata20170330 -rw-r--r-- 1 root root 5664452 Mar 31 01:09 percona-xtrabackup-2.3.2-1.el6.x86_64.rpm#授权mysql用户和mysql组
[root@localhost data]# chown mysql:mysql mysqldata -R #授权mysql用户和mysql组#mysql启动跳过授权用户表
[root@localhost data]# cat /etc/my.cnf [mysqld] basedir=/data/mysql datadir=/data/mysqldata port=3306 socket=/tmp/mysql.sock user=mysql innodb_file_per_table=on skip_name_resolve=on symbolic-links=0 init-connect='SET NAMES utf8' character-set-server = utf8 max_connections = 5000 max_connect_errors = 100000 skip-grant-tables #添加启动mysql跳过用户授权表 [mysqld_safe] log-error=/data/mysql/mysqld.log pid-file=/data/mysql/mysqld.pid、#启动mysql服务：
[root@localhost data]# /etc/init.d/mysqld start Starting MySQL... [ OK ] [root@localhost data]# cd mysqldata [root@localhost mysqldata]# ls 2017-03-31_02-33-37 ecos ecoslog ibdata1 localhost.localdomain.pid stest xtrabackup_info appversion ecosantispam ecos_notice ib_logfile0 mysql test auto.cnf ecos_delivery ecoswallet ib_logfile1 performance_schema xtrabackup_binlog_pos_innodb#如果忘记了登录mysql的用户密码可以跳过用户认证表，当然也可以加在my.cnf文件中：
/etc/rc.d/init.d/mysqld start --skip-grant-tables; #跳过权限表启动mysql不用密码；另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
本文名称：使用XtraBackup恢复|备份Mysql数据库--数据恢复篇-创新互联
浏览路径：http://hbruida.cn/article/dgdosc.html
