mysql物理备份工具Xtrabackup安装配置

mysql物理备份工具Xtrabackup安装配置

Xtrabackup是一个对InnoDB做物理数据备份的工具，支持在线热备份（备份时不影响数据读写），是商业备份工具InnoDB Hotbackup的一个很好的替代品。Xtrabackup有两个主要的工具：xtrabackup、innobackupex（1）xtrabackup只能备份InnoDB和XtraDB两种数据表，而不能备份MyISAM数据表。（2）innobackupex是用来备份非InnoDB表的，同时会调用xtrabackup命令来备份InnoDB表，还会和mysql server发送命令进行交会，如加读锁、获取位点等。简单来说，innobackupex在xtrabackup之上做了一层封装。一般情况下，我们是希望能备份MyISAM表的，虽然我们可能自己不用MyISAM表，但是mysql库下的系统表示MyISAM的，因此备份基本都通过innobackupex命令进行；另外一个原因是我们可能需要保存位点信息。XtraBackup基于InnoDB的crash-recovery功能，它会复制InnoDB的data file，由于不锁表，复制出来的数据是不一致的，在恢复的时候使用crash-recovery，使得数据恢复一致。InnoDB维护了一个redo log，又称为transaction log（事务日志），它包含了InnoDB数据的所有改动情况。当InnoDB启动的时候，它会先去检查data file和transaction log，并且会做两步操作：XtraBackup在备份的时候，一页一页的复制InnoDB的数据，而且不锁定表，与此同时，XtraBackup还有另外一个线程监视着transaction log，一旦log发生变化，就把变化过的log pages复制走。为什么要着急复制走呢？因为transaction log文件大小有限，写满之后，就会从头再开始写，所以新数据可能会覆盖到旧的数据。在prepare过程中，XtraBackup使用复制到的transaction log对备份出来的InnoDB data file进行crash recovery。(1)备份过程快速、可靠(2)备份过程不会打断正在执行的事务(3)能够基于压缩等功能节约磁盘空间和流量(4)自动实现备份检验(5)还原速度快本来想用源码安装的，但总是不断报错，所以只好采用yum方法安装了打开官网yum源安装方法说明https://www.percona.com/doc/percona-xtrabackup/LATEST/installation/yum_repo.html按照步骤安装官网的yum源# yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm# ls /etc/yum.repos.d/CentOS-Base.repo CentOS-fasttrack.repo CentOS-Vault.repo percona-release.repoCentOS-Debuginfo.repo CentOS-Media.repo epel.repo安装xtrabackup# yum list|grep percona #测试是否安装成功官网的yum源# yum install percona-xtrabackup-24# xtrabackup -version #查看版本信息也可以选用其他版本用rpm包方式安装https://www.percona.com/downloads/XtraBackup/LATEST/binary/redhat/6/x86_64/–user=USER 指定备份用户，不指定的话为当前系统用户–password=PASSWD 指定备份用户密码–port=PORT 指定数据库端口–defaults-group=GROUP-NAME 在多实例的时候使用–host=HOST 指定备份的主机，可以为远程数据库服务器–apply-log 应用 BACKUP-DIR 中的 xtrabackup_logfile 事务日志文件。一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处于不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件使得数据文件处于一致性状态。–apply-log-only 这个选项使在准备备份(prepare)时，只执行重做(redo)阶段，这对于增量备份非常重要。–database 指定需要备份的数据库，多个数据库之间以空格分开–defaults-file 指定mysql的配置文件–copy-back 将备份数据复制回原始位置–incremental 增量备份，后面跟要增量备份的路径–incremental-basedir=DIRECTORY 增量备份时使用指向上一次的增量备份所在的目录–incremental-dir=DIRECTORY 增量备份还原的时候用来合并增量备份到全量，用来指定全备路径–redo-only 对增量备份进行合并–rsync 加快本地文件传输，适用于non-InnoDB数据库引擎。不与–stream共用–safe-slave-backup–no-timestamp 生成的备份文件不以时间戳为目录.查看备份之前都有哪些库mysql> show databases;+——————–+| Database |+——————–+| information_schema || binlog || database1 || mysql || performance_schema || wangning || wordpress |+——————–+7 rows in set (0.16 sec)全备份数据存放在/data/backup/full下面，innobackupex会自动创建一个文件夹+以当前系统时间命名的文件夹# innobackupex –defaults-file=/etc/my.cnf –user=root –password=abc123 –socket=/tmp/mysql.sock /data/backup/full# ls /data/backup/full/2017-12-11_09-10-45备份好的目录里各文件说明，部分为备份之前建的库# ls /data/backup/full/2017-12-11_09-10-45/backup-my.cnf ibdata1 wangning xtrabackup_checkpointsbinlog mysql wordpress xtrabackup_infodatabase1 performance_schema xtrabackup_binlog_info xtrabackup_logfile(1) backup-my.cnf —— 备份命令用到的配置选项信息；(2) ibdata1 —— 备份的表空间文件；(3) xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件；(4) xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置；(5) xtrabackup_logfile —— 备份的重做日志文件。(6) xtrabackup_checkpoints —— 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息；# cat /data/backup/full/2017-12-11_09-10-45/xtrabackup_checkpointsbackup_type = full-backuped #可以看出是全备份from_lsn = 0 #记录了LSN，日志偏移量to_lsn = 8096126last_lsn = 8096126compact = 0recover_binlog_info = 0关闭数据库并移除数据文件# service mysqld stop# mv /application/mysql/data /opt/# mkdir /application/mysql/data #创建数据目录# chown -R mysql.mysql /application/mysql/data一般情况下，这个/data/backup/full/2017-12-11_09-10-45备份不能用于恢复，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务，此时数据文件处于不一致的状态。因此，我们现在就是要通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。# innobackupex –defaults-file=/etc/my.cnf –user=root –password=abc123 –socket=/tmp/mysql.sock –apply-log /data/backup/full/2017-12-11_09-10-45/# innobackupex –defaults-file=/etc/my.cnf –user=root –password=abc123 –socket=/tmp/mysql.sock –copy-back /data/backup/full/2017-12-11_09-10-45171211 10:03:07 innobackupex: Starting the copy-back operationIMPORTANT: Please check that the copy-back run completes successfully. At the end of a successful copy-back run innobackup开发云主机域名ex prints “completed OK!”.innobackupex version 2.4.9 based on MySQL server 5.7.13 Linux (x86_64) (revision id: a467167cdd4)Error: datadir must be specified.当执行上述命令出现报错时，是因为my.cnf文件里没有指定datadir目录解决方法：[mysqld]datadir = /application/mysql/data启动mysql出现报错# service mysqld start Starting MySQL. ERROR! The server quit without updating PID file (/application/mysql/data/db01.pid).将data目录属主改为mysql即可# chown -R mysql.mysql /application/mysql/data/此时mysql的数据已成功恢复了增量备份是在全量备份的基础之上进行的增量备份目录1：/data/backup/increment1增量备份目录2：/data/backup/increment2先全备再增备，全备见6.1# innobackupex –defaults-file=/etc/my.cnf –user=root –password=abc123 –socket=/tmp/mysql.sock –incremental /data/backup/increment1 –incremental-basedir=/data/backup/full/2017-12-11_09-10-45生成一个以系统时间命名的文件夹# ls /data/backup/increment1/2017-12-11_10-51-27–incremental-basedir指的是完全备份所在的目录，此命令执行结束后，innobackupex命令会在/data/backup/increment1目录中创建一个新的以时间命名的目录以存放所有的增量备份数据。另外，在执行过增量备份之后再一次进行增量备份时，其–incremental-basedir应该指向上一次的增量备份所在的目录。需要注意的是，增量备份仅能应用于InnoDB或XtraDB表，对于MyISAM表而言，执行增量备份时其实进行的是完全备份。准备完整的数据恢复文件全备 –apply-log# innobackupex –defaults-file=/etc/my.cnf –user=root –password=abc123 –socket=/tmp/mysql.sock –apply-log –redo-only /data/backup/full/2017-12-11_09-10-45/增备1 –apply-log# innobackupex –defaults-file=/etc/my.cnf –user=root –password=abc123 –socket=/tmp/mysql.sock –apply-log –redo-only /data/backup/full/2017-12-11_09-10-45/ –incremental-dir=/data/backup/increment1/2017-12-11_10-51-27模拟数据库损坏，详见6.2.1开始恢复数据，详见6.2.3第二次增量备份是在第一次增量备份的基础上进行的# innobackupex –defaults-file=/etc/my.cnf –user=root –password=abc123 –socket=/tmp/mysql.sock –incremental /data/backup/increment2 –incremental-basedir=/data/backup/increment1/2017-12-11_10-51-27生成一个以系统时间命名的文件夹# ls /data/backup/increment2/2017-12-11_10-58-55准备完整的数据恢复文件增备2 –apply-log# innobackupex –defaults-file=/etc/my.cnf –user=root –password=abc123 –socket=/tmp/mysql.sock –apply-log –redo-only /data/backup/full/2017-12-11_09-10-45/ –incremental-dir=/data/backup/increment2/2017-12-11_10-58-55模拟数据库损坏，详见6.2.1开始恢复数据，详见6.2.3按照6.3.2.2以此类推即可

相关推荐: 参数binlog_row_image设置MINIMAL，你今天被坑了吗？

今天网友”芬达”跟我讨论一个参数binlog_row_image，在什么场景下设置为MINIMAL，我觉得这个案例很有意义，尤其是在生产环境中，要慎重设置这个参数。首先这个MINIMAL，只会在binlog里记录被影响的行，而不能像默认的FULL一样，记录完整…