小量的数据库可以每天进行完整备份,因为这也用不了多少时间,但当数据库很大时,就不太可能每天进行一次完整备份了,这时候就可以使用增量备份。怎么做?
增量备份的原理就是使用了mysql的binlog日志。
本次操作的MySQL版本为5.5.40 for Linux (x86_64)。
增量备份要确保打开了二进制日志,参考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。
模拟插入数据和误操作
恢复过程不要记录日志:
我们也可以看到全备时的binlog位置:
查看当前所在二进制日志中的位置:
根据上面两个position能大概确定需要完整恢复哪几个binlog文件。
恢复mysql-bin.000002
在待恢复的position或时间点以前、全备以后的binlog需要全部恢复,多个文件以空格隔开
此时查询可以得到前两条数据。
恢复部分mysql-bin.000003
这个日志中包括了新增记录和误删表两个部分,我们需要恢复到新增记录之后、误删操作以前的位置。
如果知道误操作的命令如DROP TABLE,则可以通过下面的方法在binlog文件中找到误操作之前的那个position:
(如下面的信息显示,误操作DROP TABLE之前的pos是775,在datetime 141204 15:08:04或pos 882时完成DROP TABLE操作)
恢复命令:
如果position难以确定,但知道需要恢复到的确切(服务器)时间,也可以使用datetime:
如果不是误操作导致的,而是迁移数据库,那么不需要position或datetime,使用所有binlog文件增量恢复即可。
确定恢复成功后记得打开日志记录:
报错
原因是在我为了统一mysql客户端到服务端的的字符编码,在/etc/my.cnf文件的[client]、[mysqld]等节加入了default-character-set = utf8,mysqlbinlog会从my.cnf中的[client]读取配置,但奈何mysqlbinlog并不认识这个选项(据说是个bug)导致的。
应对这个bug的方法有两个:
第一,自然是注释到[client]中的这个字符集配置;
第二,改用loose-default-character-set = utf8。在选项前加了loose-,表示当程序不认识此选项时会略过此选项,并给出一个警告。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。