视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
MySQL增量备份与恢复实例_MySQL
2020-11-09 19:48:33 责编:小采
文档

小量的数据库可以每天进行完整备份,因为这也用不了多少时间,但当数据库很大时,就不太可能每天进行一次完整备份了,这时候就可以使用增量备份。增量备份的原理就是使用了mysql的binlog日志。

本次操作的MySQL版本为 5.5.40 for Linux (x86_)

增量备份要确保打开了二进制日志,参考 mysql的日志系统 :

mysql> show variables like'%log_bin%';

首先对pak数据库做一个完整备份:

$ mysqldump -h localhost -upak -ppwd -P3306 --master-data=2 --single-transaction --opt pak > pak_bak_full.sql 

这时候就会得到一个全备文件pak_bak_full.sql。mysqldump操作会导致滚动一次log,假设新的binlog文件是mysql-bin.000002。

模拟插入数据和误操作

a. 在pak库的某个表插入一些数据,然后执行 flush logs 命令。这时将会产生一个新的二进制日志文件mysql-bin.000003,mysql-bin.000002则保存了全备过后的所有更改,既增加记录的操作也保存在了mysql-bin.00002中。

b. 再在pak库中的t_user表中增加两条记录,然后误删除t_user表。t_user中增加记录的操作和删除表的操作都记录在mysql-bin.000003中。

开始恢复

恢复过程不要记录日志:

mysql > setglobal sql_log_bin=0;

首先导入全备数据

 $ mysql -h localhost -upak -ppwd < pak_bak_full.sql
或
mysql> source /path/backup/pak_bak_full.sql

我们也可以看到全备时的binlog位置:

head -50 backup-file.sql |grep 'CHANGE MASTER' -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=4321;

查看当前所在二进制日志中的位置:

mysql> show master status;

根据上面两个position能大概确定需要完整恢复哪几个binlog文件。

恢复mysql-bin.000002

在待恢复的position或时间点以前、全备以后的binlog需要全部恢复,多个文件以空格隔开

$ mysqlbinlog /var/lib/mysql/mysql-bin.000002 | mysql -uroot -p 

此时查询可以得到前两条数据。

恢复部分mysql-bin.000003

这个日志中包括了新增记录和误删表两个部分,我们需要恢复到新增记录之后、误删操作以前的位置。

如果知道误操作的命令如 DROP TABLE ,则可以通过下面的方法在binlog文件中找到误操作之前的那个position:

(如下面的信息显示,误操作 DROP TABLE 之前的pos是775,在datetime 141204 15:08:04或pos 882时完成 DROP TABLE 操作)

 $ mysqlbinlog /var/lib/mysql/mysql-bin.000003 |grep -C 5 'DROP TABLE'
#141204 15:07:05 server id 1 end_log_pos 775 Xid = 376
COMMIT/*!*/;
# at 775
#141204 15:08:04 server id 1 end_log_pos 882 Query thread_id=10 exec_time=0 error_code=0
SET TIMESTAMP=1417676884/*!*/;
DROP TABLE `t_user` /* generated by server */
/*!*/;
# at 882

恢复命令:

$ mysqlbinlog /var/lib/mysql/mysql-bin.000003 --stop-position=775 | mysql -h localhost -uroot -p 

如果position难以确定,但知道需要恢复到的确切(服务器)时间,也可以使用datetime:

$ mysqlbinlog /var/lib/mysql/mysql-bin.000003 --stop-datetime="2014-12-04 15:08:00" | mysql -uroot -p 

如果不是误操作导致的,而是迁移数据库,那么不需要position或datetime,使用所有binlog文件增量恢复即可。

确定恢复成功后记得打开日志记录:

mysql > setglobal sql_log_bin=1;

报错

1. unknown variable 'default-character-set=utf8'

在使用 mysqlbinlog 查看二进制日志的时候,提示下面的错误:

/usr/local/mysql/bin/mysqlbinlog: unknown variable 'default-character-set=utf8'

原因是在我为了统一mysql客户端到服务端的的字符编码,在 /etc/my.cnf 文件的 [client][mysqld] 等节加入了 default-character-set = utf8mysqlbinlog 会从 my.cnf 中的 [client] 读取配置,但奈何mysqlbinlog并不认识这个选项(据说是个bug)导致的。

应对这个bug的方法有两个:

第一,自然是注释到 [client] 中的这个字符集配置;

第二,改用 loose-default-character-set = utf8 。在选项前加了 loose-,表示当程序不认识此选项时会略过此选项,并给出一个警告。

下载本文
显示全文
专题