本机环境 centos6.5 ip:192.168.117.129
1.下载安装包 链接:www.percona.com/downloads/X…
三个包:
percona-xtrabackup-24-2.4.12-1.el6.i686.rpm
percona-xtrabackup-24-debuginfo-2.4.12-1.el6.i686.rpm
percona-xtrabackup-test-24-2.4.12-1.el6.i686.rpm
复制代码
2.下载完成之后 执行
yum -y install percona-xtrabackup-24-2.4.12-1.el6.i686.rpm percona-xtrabackup-24-debuginfo-2.4.12-1.el6.i686.rpm \
percona-xtrabackup-test-24-2.4.12-1.el6.i686.rpm
复制代码
3.如果出现报错信息:需要解决依赖关系 percona-xtrabackup依赖libev.so.4()(64bit)的包
下载包:ftp://rpmfind.net/linux/dag/redhat/el6/en/i386/dag/RPMS/libev-4.15-1.el6.rf.i686.rpm
ftp://rpmfind.net/linux/dag/redhat/el6/en/i386/dag/RPMS/libev-devel-4.15-1.el6.rf.i686.rpm
下载好安装即可
复制代码
-
1.进行全量备份一个数据:
innobackupex --defaults-file=/etc/my.cnf --host=192.168.117.129 --user=root --password=82111 /backup 出现报错 xtrabackup: recognized server arguments: --datadir=/var/lib/mysql xtrabackup: recognized client arguments: --datadir=/var/lib/mysql 180809 01:20:56 innobackupex: Starting the backup operation IMPORTANT: Please check that the backup run completes successfully. At the end of a successful backup run innobackupex prints "completed OK!". 180809 01:20:56 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;host=192.168.117.129' as 'root' (using password: YES). Failed to connect to MySQL server: DBI connect(';mysql_read_default_group=xtrabackup;host=192.168.117.129','root',...) failed: Host '192.168.117.129' is not allowed to connect to this MySQL server at - line 1314 180809 01:20:57 Connecting to MySQL server host: 192.168.117.129, user: root, password: set, port: not set, socket: not set Failed to connect to MySQL server: Host '192.168.117.129' is not allowed to connect to this MySQL server. innobackupex --defaults-file=/etc/my.cnf --host=127.0.0.1 --user=root --password=82111 --port=3306 /backup --host修改之后报错 180809 01:49:53 Connecting to MySQL server host: 127.0.0.1, user: root, password: set, port: 3306, socket: not set Error: Built-in InnoDB in MySQL 5.1 is not supported in this release. You can either use Percona XtraBackup 2.0, or upgrade to InnoDB plugin. 复制代码
2.修改版本:
percona-xtrabackup-2.0.0-417.rhel6.i686.rpm percona-xtrabackup-debuginfo-2.0.0-417.rhel6.i686.rpm 复制代码
--host为192.168.117.129时报错
innobackupex --defaults-file=/etc/my.cnf --host=192.168.117.129 --user=root --password=82111 --port=3306 /backup InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona Inc 2009-2012. All Rights Reserved. This software is published under the GNU GENERAL PUBLIC LICENSE Version 2, June 1991. 180809 02:38:31 innobackupex: Starting mysql with options: --defaults-file='/etc/my.cnf' --password=xxxxxxxx --user='root' --host='192.168.117.129' --port='3306' --unbuffered -- 180809 02:38:31 innobackupex: Connected to database with mysql child process (pid=2752) innobackupex: Error: mysql child process has died: ERROR 1130 (HY000): Host '192.168.117.129' is not allowed to connect to this MySQL server 复制代码
全量备份:
innobackupex --defaults-file=/etc/my.cnf --host=127.0.0.1 --user=root --password=82111 --port=3306 /backup 成功 --defaults-file指明配置文件 可省略 复制代码
ls /backup 文件为 2018-08-09_02-39-03/ 在/backup/2018-08-09_02-39-03/中还有一些文件 backup-my.cnf:该文件中包含my.cnf的一些设置,但并不是全部,而是只包含备份所需要的信息 xtrabackup_bin_info:该文件中记录了备份开始时二进制日志文件的位置 xtrabackup_checkpoints:此文件记录此次备份属于那种类型的备份,是全量还是增量,备份时起始的LSN号码,结束时的LSN号吗等信息 xtrabackup_info:本次备份的概要信息 xtrabackup_logfile:记录了备份过程的日志,在对数据prepare是需要通过日志将数据还原成一致可以用的数据 复制代码
xtrabackup_checkpoints:
备份恢复:
当我们开始备份innodb数据时,我们还需要同时备份对应的事务日志,因为在开始备份时,有些事务已经存在于事务日志中,这些事务可能已经提交了,但是还没有同步到datafile中,所以我们要重放这些已经提交的事务,有些事务可能还未提交,所以我们要回滚这些没有提交的事务。 xtrabackup就是这样做的,在备份开始时,同时运作两个线程,一个线程负责备份innodb中的page,另一个线程负责备份innodb的事务日志(redo log),事务日志都会被xtrabackup记录到自己的日志文件中,那么,备份结束后,我们会得到两份文件,一份是不可用的备份文件,一份是备份时的事务日志,备份文件之所以不可用,是因为有一部分不确定的数据可能在事务日志中,而且热备过程中数据也可能会发生改变,所以我们要通过这两份文件,制作出一份可用的备份文件,没错,就是通过应用事务日志的方式,让最终的备份成为一个可用的备份,事务日志会被应用,事务日志文件中已经提交的事务需要replayed,未提交的事务需要roolback, 整个过程类似于mysql崩溃后恢复的过程,但是这个过程在xtrabackup中被称为"prepare","prepare"操作保证了备份出的数据的一致性,没有经过prepare的备份数据是不可用的,我们可以理解为如果想要得到一个可用的备份,则需要进行这些所谓的"准备"工作或者所谓的"数据恢复"的工作。 说到这里,就必须考虑另外一个问题,我们刚才提到,想要备份数据可用,则必须进行prepare工作,那么,先不考虑存在增量备份的情况,当不存在增量备份时,我们在对数据进行prepare时,需要应用事务日志,对于已经写入redologfile中但是还没有写入datafile中的已提交事务进行同步,对于未提交的的事务所作出的修改进行回滚,这是没有增量的情况下,但是,如果存在增量备份时,xtrabackup会将所有增量都合并到之前的全量上,然后使用最后的完整数据进行还原,那么,在合并数据的过程中,上一次未提交的事务有可能在下次的增量备份中已经提交了,所以,如果存在多个增量备份的时候,我们在进行prepare工作时,只需要将已经提交的事务同步到数据文件中即可,未提交的事务不用进行回滚,因为在增量中,这些事务可能已经提交了,只需要在最后一份增量数据进行prepare时,将对应的未提交的事务回滚即可。 而我们知道,xtrabackup能对innodb做热备,能对myisam做温备,对myisam做温备时会对myisam表添加读锁,也就是说,备份出的myisam表中的数据应该是一致的 ,但是如果数据库中既有myisam表又有innodb表时,如果想要整体的所有数据都一致,则只能以myisam的一致性时间点作为最终备份的一致性时间点,所以,xtrabackup在备份时,会先备份inndb数据,备份完innodb数据后,再备份非innodb数据,当我们需要将备份的数据"prepare"时,只操作innodb数据即可,非innodb数据不用动,prepare完成后,innodb的一致性时间点与非innodb数据的一致性时间点是相同的。 复制代码
只还原全量备份,没有增量
innobackupex --apply-log --use-memory=100M /backup/2018-08-09_02-39-03/ --apply-log:该选项表示同xtrabackup的--prepare参数,一般情况下,在备份完成后,数据尚且不能用于恢复操作,因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此,此时数据 文件仍处理不一致状态。--apply-log的作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态。 --use-memory:可以指定使用的内存大小 因为我们的演示数据在备份时并没有什么多少事务日志,所以很快应用成功了,如果你要备份的数据量巨大,那么备份时长会变长,期间备份的事务日志容量有可能会很大。那么,我们可以使用--use-memory选项,加速准备工作的完成,在不指定内存大小的情况下,准备工作默认会占用100MB的内存,如果服务器有一定的空闲内存,那么我们可以让xtrabackup使用指定大小的内存完成准备工作,以提升准备工作完成的速度,示例语句如下。 好了,完成上述工作以后,我们已经得到了一份可用的,数据一致的备份,那么此刻,我们即可完成真正的恢复数据操作了,真正的恢复数据操作也非常简单,我们只要把可用的备份"拷贝回"数据库的数据目录即可。但是,拷贝工作并不是手工的使用cp命令或者mv命令进行,而是使用innobackupex命令进行,示例语句如下 innobackupex --datadir=/var/lib/mysql --copy-back /backup/2018-08-09_02-39-03/ --datadir选项指定的目录就是数据目录,上例中,我们指定的数据目录为rpm安装的mysql的默认数据目录,如果数据库的my.cnf配置文件中已经设置了datadir对应的目录,那么则可以省略--datadir选项,innobackupex在执行copyback时会读取数据库的my.cnf中的配置,但是如果my.cnf中没有配置datadir,那么--datadir选项必须存在,而且,datadir目录必须为空目录,其中不能存在数据,否则在执行上述命令时会报错,--copy-back选项对应的目录就是我们准备好的可用数据的目录。 好了,还原工作完成了,但是稍等,此时我们还不能启动mysql,因为我们是使用root用户拷贝的数据,所以数据目录中的数据文件的属主属组仍然为root,没错,我们需要将这些文件的属主属组设置为mysql。 chown -R mysql: /var/lib/mysql/ 如果你遇到无法启动的情况,此时,你可以确定一下数据目录中的事务日志文件的大小,是否与备份时数据库指定的事务日志大小相同,如果事务日志的大小自动变大了(比如从默认的5M变成了50M),可能会导致mysql启动不成功的现象发生,此时,可以尝试将如下事务日志文件删除或备份至其他目录后,再次启动mysql。 复制代码
增量备份:
添加一个表 mysql> create table user(id int primary key,name varchar(6),say char(20)); Query OK, 0 rows affected (0.02 sec) 加数据 mysql> insert into user (id,name,say) values(1,'vict','hello'),(2,'chen','word'); Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0 增量备份: innobackupex -user=root -password=82111 --incremental /backup --incremental-basedir=/backup/2018-08-09_02-39-03/ 复制代码
还原:
完全备份还原前准备 [root@chenkaidashuaige ~]# innobackupex --apply-log --redo-only --use-memory=100M /backup/2018-08-09_02-39-03/ 上述命令与前文中的命令有所不同,上述命令多出了一个--redo-only选项,这个选项表示在进行准备(应用日志)工作时,只进行redo操作,因为在备份开始时,有的事务日志已经提交了,但是还没有完全应用到数据文件中,有的事务日志还没有提交,这些没有提交的事务需要进行回滚操作,在进行"准备"工作时,如果添加了--redo-only选项,则只会重做已提交但是未应用的事务,而不会回滚未提交的事务,为什么前文中的准备工作中,没有添加--redo-only选项呢,那是因为,前文中只还原了一个全量备份,全量备份之后没有任何其他备份需要合并,而此刻则不同,除了全量备份,后面还有对应的增量备份,那么全量备份中未提交的事务有可能在后面的增量备份中已经提交了,所以,在准备"最后一份备份"之前的"备份"时,都不用进行回滚操作,只在最后一次备份中进行回滚操作即可。 增量备份和完全备份整合: [root@chenkaidashuaige 2018-08-09_02-39-03]# innobackupex --apply-log /backup/2018-08-09_02-39-03/ --use-memory=100M --incremental-dir=/backup/2018-08-09_03-38-23/ 此处不在加上redo-only因为是最后一次增量备份所以让其应该回滚的未提交的事务进行回滚 执行完上述命令后,则表示第一份增量备份已经整理完毕,并且已经将增量合并到了对应的全量备份中,如果此时,查看全量备份中的 xtrabackup_checkpoints 文件,会发现全量备份的备份类型已经变为了"full-prepared",如下所示,也就是说,这个备份已经经历过了日志应用的过程(已经做过了准备工作),而且,对应的最大的LSN号码为61918,此LSN正是第一次增量的结束LSN,也就是说,我们已经将第一次增量与全量整合在了一起。 如果我们进行整合的备份不是最后一次的增量备份 完全备份的备份类型是 log-applied 如果还有增量备份,就让其和整合好的备份进行整合,也就是和全量备份整合 命令同上 但是要注意的是最后一次增量备份的prepare不加 redo-only,让其该回滚的回滚 复制代码
还原:
到目前为止,所有准备工作已经完成,我们已经把所有增量备份都合并到了最初的第一份全量备份中,现在,我们只要通过这一份全量备份即可恢复数据库。 完成准备工作之后,关闭mysql服务,删除里面的数据文件,进行全量的恢复,(要确保数据文件为空,否则会提示报错 Original data directory is not empty! at /usr/bin/innobackupex line 568.) 给权限 chown -R mysql: /var/lib/mysql/ 开启服务 复制代码
数据恢复成功 复制代码