备份,对于任何数据库,任何系统都是重中之重。针对Mysql,我选择percona xtrabackup软件。我更喜欢物理层面的热备份。而不是逻辑层面的备份(mysqldump),当然很多情况,也要定期做mysqldump备份。增加一个安全的备份选择。
关于如何下载安装percona xtrabackup,请参考:
http://blog.51cto.com/hsbxxl/2107388
先看看innobackupex常用参数
--compact 创建一个不包含第二索引(除了主键之外的索引)的备份 --decompress 解压之前所有以–compress参数备份出来的带有.qp格式的备份文件,--parallel参数会允许同时解锁或解压多个文件。需要安装qpress软件。 --defaults-file=[MY.CNF] 配置文件的路径 --incremental-basedir 以上一次全量或增量备份的路径,作为增量备份的基础。指定这个参数的同时,应该同样指定--incremental参数 --incremental 创建增量备份,当指定这个参数的时候,应该指定--incremental-lsn或--incremental-basedir参数,否则将会备份到--incremental-basedir路径 --apply-log 在备份目录下,通过应用名称为xtrabackup_logfile的交易日志文件来准备备份。同时,创建新的交易日志。 --redo-only 当准备数据库的全备或合并增量备份时,需要指定这个参数。这个参数实际上执行的是xtrabackup --apply-log-only,会让xtrabackup跳过回滚节点,只做“redo”步骤。当数据库需要应用增量备份时,需要指定这个参数。 --incremental-dir=DIRECTORY 指定增量备份的目录,需要搭配--incremental参数。 --no-timestamp 这个参数会让xtrabackup在备份的时候不创建带有时间格式的子文件夹。当指定了这个参数,备份会直接创建在指定的备份目录下 --stream=STREAMNAME 指定流备份的格式。备份将会以指定格式输出到STDOUT。目前支持的格式有tar 和 xbstream。如果指定了这个参数,后面需要接tmpdir目录作为处理流的一个中间目录。 --slave-info 当备份一个作为复制环境的服务器时,这个参数会自动将CHANGE MASTER语句写到备份中,在恢复备份后,不必执行CHANGE MASTER语句。 --tables-file=FILE 这个参数会接受一个字符串,这个字符串指定了一个文件,这个文件包含了要备份的表名,格式如database.table,一行一个。 --use-memory=# 这个参数用于在准备备份时,xtrabackup执行crash recovery所使用的内存大小。这个参数仅和--apply-log搭配时才生效。
更多innobackupex参数解释,请参考官网
整个测试流程如下图
下面开始我的备份&恢复测试
1. 先看一下我的/etc/my.cnf设置。我选择了binlog是row模式的,也就是“行”模式,而不是sql模式。binlog和datafile分开存放,方便后续的数据库管理。
binlog_format = row expire_logs_days = 7 max_binlog_size = 100m binlog_cache_size = 4m max_binlog_cache_size = 512m character_set_server = utf8 lower_case_table_names=1 datadir=/data/mysql log_bin=/data/mysql-binlog/mysql-bin server_id=101
备份前,创建表
test1 --innodb引擎 test2 --innodb引擎 testmyisam --myisam引擎
2. 数据库全备份(innobackupex参数请参考)
创建备份目录
mkdir /backup
全库备份
innobackupex --defaults-file=/etc/my.cnf --user=root --password='Abcd234!' /backup/20180424/
3. 全备份之后的操作
a. 创建myisam存储引擎的表testmyisam2
mysql> show tables; +----------------+ | Tables_in_test | +----------------+ | test1 | | test2 | | testmyisam | | testmyisam2 | +----------------+ 4 rows in set (0.00 sec)
b. 删除表test2
mysql> drop table test2; Query OK, 0 rows affected (0.03 sec) mysql> show tables; +----------------+ | Tables_in_test | +----------------+ | test1 | | testmyisam | | testmyisam2 | +----------------+ 3 rows in set (0.00 sec)
4. innobackupex备份mysql的过程,就是文件的拷贝,在拷贝数据的过程中,数据会发生变化,所以备份出来的数据文件是不一致的。为了保证数据的一致性,需要应用这段时间产生的binlog,才能做到备份数据文件的一致性。后续回复才能有效。
使用--apply-log参数并指定带时间的备份子目录,进行备份一致性合并。想要加快apply-log的进程,推荐使用--use-memory参数。
这个操作可以在任意机器上执行准备备份动作,并不限定在备份的服务器上。
innobackupex --defaults-file=/etc/my.cnf --apply-log --user=root --password='Abcd1234!' /backup/20180424/2018-04-22_21-22-30/
5. 恢复数据文件到mysql路径下,恢复路径取决于my.cnf中的datadir=/data/mysql 参数。
需要先清空datadir=/data/mysql 路径才能恢复,不然会报错。默认情况下,--copy-back是不会over write已经存在的文件的,可以通过参数--force-non-empty-directories强制覆盖
停止mysql
service mysqld stop
清空mysql路径(一定要慎重,建议是mv备份,而不是rm)
rm -rf /data/mysql/*
全库恢复
innobackupex --defaults-file=/etc/my.cnf --copy-back /backup/20180424/2018-04-22_21-22-30/
修改路径权限
chown mysql:mysql -R /data/mysql/
启动mysql
service mysqld start
6. 当前数据库只是restore一个全备份,并没有基于时间点,恢复到当前
全背后恢复完成之后,查询数据库,可以看到test2表还没有删除,testmyisam2也没有出现
mysql> show tables; +----------------+ | Tables_in_test | +----------------+ | test1 | | test2 | | testmyisam | +----------------+
7. 首先要通过备份文件,查找上次备份完成,的binglog position位置,在备份文件路径下的xtrabackup_binlog_info中记录,这个position很重要,是后面恢复的关键。
# cd /backup/20180424/2018-04-22_21-22-30/ # cat xtrabackup_binlog_info mysql-bin.000002 29388004
8. 通过mysqlbinglog进行recover
mysqlbinlog --start-position=29388004 /data/mysql-binlog/mysql-bin.000002 | mysql -uroot -p'Abcd234!'
9. 归档也恢复完成之后,再次查询test2表已经删除,testmyisam2也出现了
mysql> show tables; +----------------+ | Tables_in_test | +----------------+ | test1 | | testmyisam | | testmyisam2 | +----------------+ 3 rows in set (0.00 sec)
10.也可以根据position恢复到指定的时间点范围(下面是full restore自后再次测试的步骤,不是接上一步恢复的。)
查找position信息
# mysqlbinlog --start-position=29388004 /data/mysql-binlog/mysql-bin.000002|grep "^# at" # at 4 # at 29388004 # at 29388069 # at 29388304 # at 29388369 # at 29388487
11. 指定范围恢复
mysqlbinlog --start-position=29388004 --stop-position=29388304 /data/mysql-binlog/mysql-bin.000002 | mysql -uroot -p'Abcd1234!' 恢复完这段binlog,可以看到testmyisam2已经出现了 mysql> show tables; +----------------+ | Tables_in_test | +----------------+ | test1 | | test2 | | testmyisam | | testmyisam2 | +----------------+ 4 rows in set (0.00 sec)
12. 分段recover,有助于在人为错误的数据找回
mysqlbinlog --start-position=29388304 --stop-position=29388487 /data/mysql-binlog/mysql-bin.000002 | mysql -uroot -p'Abcd1234!' 恢复这段binlog,可以看到test2已经被删除了 mysql> show tables; +----------------+ | Tables_in_test | +----------------+ | test1 | | testmyisam | | testmyisam2 | +----------------+
总结
a、对于完全恢复,我们需要使用备份加binlog两者结合的方式来实现
b、在恢复期间,首先使用带read-only的apply-log方式来prepare全备(在有增量备份需要合并的情况,没有增量的情况,就不需要read-only)
c、接下来使用带read-only的apply-log方式来prepare增备,仅最后一个增备可以不用read-only
d、停止原有实例,并copy-back后启动恢复后的实例
e、从Innobakcupex备份信息中获取最后的binlog日志及位置信息
f、使用mysqlbinlog方式将日志追加到最新时刻
参考链接
http://blog.itpub.net/26506993/viewspace-2088737/
https://blog.csdn.net/zhang123456456/article/details/72954519
原文地址:http://blog.51cto.com/hsbxxl/2107383