MySQL社区

 找回密码
 注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

搜索
查看: 14319|回复: 2

[mysqldump] mysqldump全量备份+mysqlbinlog二进制日志增量备份

[复制链接]
发表于 2015-10-19 17:49:53 | 显示全部楼层 |阅读模式

MySQL binlog就是mysql的二进制数据文件。在对mysql进行一些配置之后,mysql会把数据库的更新操作都记录在一个文件中。

mysql binlog可以在mysqld的--bin-log选项或者在配置文件(my.cnf或者my.ini)中打开。


[mysqld]

log-bin=mysql-bin   //[必须]启用二进制日志


在启用了二进制日志以后,在mysql的数据目录下,会出现一些以数字为结尾的文件,例如:


-rw-rw---- 1 guilhem  guilhem   1277324 Nov 10 23:59 mysql-bin.000001-rw-rw---- 1 guilhem  guilhem         4 Nov 10 23:59 mysql-bin.000002

这些文件就是二进制的日志文件。每次mysql启动都会增加一个文件。


那么如何采用全量mysqldump+增量mysqlbinlog的方式进行数据恢复?从mysqldump备份文件恢复数据会丢失掉从备份点开始的更新数据,所以还需要结合mysqlbinlog二进制日志增量备份。确保my.ini或者my.cnf中包含下面的配置以启用二进制日志。

方法其实很简单,在每次使用mysqldump进行全量数据备份时,用--flush-logs选项:


mysqldump --single-transaction --flush-logs --master-data=2 > mysqlpub_backup.sql

在使用这样的语句进行备份之后,mysql就会关闭原来的二进制日志文件,开启一个新的二进制日志文件。比如,新开启、新增量的二进制日志文件为 mysql-bin.000003,。 那么在进行数据恢复的时候,你可以利用backup.sql进行全量恢复+ mysql-bin.000003进行增量同步。


数据恢复的方法也很简单:


shell> mysql -uroot -pPwd < msyqlpub_backup.sql  (或 cat mysqlpub_backup.sql | mysql -uroot -ppassword )
shell> mysqlbinlog mysql-bin.000003 | mysql -uroot -ppassword

mysqlbinlog是一个读取 mysql二进制日志输出sql语句的命令行工具。

使用方法可以从 http://doc.mysql.cn/mysql5/refman-5.1-zh.html-chapter/client-side-scripts.html#mysqlbinlog 查到。


此外mysqlbinlog还可以指定--start-date、--stop-date、--start-position和--stop-position参数,用于精确恢复数据到某个时刻之前或者跳过中间某个出问题时间段恢复数据,直接摘录MySQL文档说明中相关内容如下:

5.9.3.1. 指定恢复时间
对于MySQL 4.1.4,可以在mysqlbinlog语句中通过--start-date和--stop-date选项指定DATETIME格式的起止时间。举例说明,假设在今天上午10:00(今天是2005年4月20日),执行SQL语句来删除一个大表。要想恢复表和数据,你可以恢复前晚上的备份,并输入:
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/bin.123456 | mysql -u root -pmypwd
该命令将恢复截止到在--stop-date选项中以DATETIME格式给出的日期和时间的所有数据。如果你没有检测到几个小时后输入的错误的SQL语句,可能你想要恢复后面发生的活动。根据这些,你可以用起使日期和时间再次运行mysqlbinlog:
mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/bin.123456 | mysql -u root -pmypwd
在该行中,从上午10:01登录的SQL语句将运行。组合执行前夜的转储文件和mysqlbinlog的两行可以将所有数据恢复到上午10:00前一秒钟。你应检查日志以确保时间确切。下一节介绍如何实现。

5.9.3.2. 指定恢复位置
也可以不指定日期和时间,而使用mysqlbinlog的选项--start-position和--stop-position来指定日志位置。它们的作用与起止日选项相同,不同的是给出了从日志起的位置号。使用日志位置是更准确的恢复方法,特别是当由于破坏性SQL语句同时发生许多事务的时候。要想确定位置号,可以运行mysqlbinlog寻找执行了不期望的事务的时间范围,但应将结果重新指向文本文件以便进行检查。操作方法为:
mysqlbinlog --start-date="2005-04-20 9:55:00" --stop-date="2005-04-20 10:05:00" /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql
该命令将在/tmp目录创建小的文本文件,将显示执行了错误的SQL语句时的SQL语句。你可以用文本编辑器打开该文件,寻找你不要想重复的语句。如果二进制日志中的位置号用于停止和继续恢复操作,应进行注释。用log_pos加一个数字来标记位置。使用位置号恢复了以前的备份文件后,你应从命令行输入下面内容:

mysqlbinlog --stop-position="368312" /var/log/mysql/bin.123456 | mysql -u root -pmypwd
mysqlbinlog --start-position="368315" /var/log/mysql/bin.123456 | mysql -u root -pmypwd

上面的第1行将恢复到停止位置为止的所有事务。下一行将恢复从给定的起始位置直到二进制日志结束的所有事务。因为mysqlbinlog的输出包括每个SQL语句记录之前的SET TIMESTAMP语句,恢复的数据和相关MySQL日志将反应事务执行的原时间。


参考资料:
http://dev.mysql.com/doc/refman/5.1/zh/client-side-scripts.html#mysqldump
http://dev.mysql.com/doc/refman/5.1/zh/database-administration.html#binary-log
http://my.oschina.net/costaxu/blog/82893
http://www.cnblogs.com/feichexia/p/MysqlDataBackup.html

发表于 2016-5-11 15:39:19 | 显示全部楼层
mysqlbinlog  记录的是整个实例下的操作内容,我要是具体操作一个数据库的话应该就是加上--database指定数据库把?
发表于 2016-7-12 11:43:57 | 显示全部楼层
圣地玛雅 发表于 2016-5-11 15:39
mysqlbinlog  记录的是整个实例下的操作内容,我要是具体操作一个数据库的话应该就是加上--database指定数据 ...

是的,具体备份某个数据库,加上--database参数,也可以不加--database参数,但是如果是导出多个库的时候,必须加上--databases 参数如下:
mysqlddump导出某个库:
mysqldump --user=xxyyzz --password=zzzz., --socket=/run/mysql3306.sock   niubi  --default-character-set=utf8 > /tmp/backupfiles.sql
或者:
mysqldump --user=xxyyzz --password=zzzz., --socket=/run/mysql3306.sock   --databases niubi --default-character-set=utf8 > /tmp/backupfiles.sql


但是如果是导出多个库的时候,必须加上--databases 参数,不然会报错
mysqldump导出数据库中的多个库:
备份2个库:niubi和diao
mysqldump  -uxxzzll -pdegeg   --databases niubi diao   --master-data=2 --default-character-set=utf8  > /tmp/backupfiles.sql


您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|申请友链|小黑屋|Archiver|手机版|MySQL社区 ( 京ICP备07012489号   
联系人:周生; 联系电话:13911732319

GMT+8, 2024-4-19 00:11 , Processed in 0.070622 second(s), 27 queries , Gzip On.

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表