[转帖]mysqldump --master-data=2 --single-transaction

https://www.cnblogs.com/cheyunhua/p/9896167.html

 

转载于https://blog.csdn.net/linuxheik/article/details/71480882
1 mysqldump导出数据主要有两种控制：一种是导出的全过程都加锁 lock-all-tables, 另一种则是不加。前者会在导出开始时执行 FLUSH TABLES WITH READ LOCK; 也就是加全局读锁，会阻塞其它写操作，以保证导出是一致性的；因此只有在导出测试数据时或导出时没有业务连接操作时可不加 lock-all-tables .
至于说一致性导出的另一种方式 single-transaction, 则是有适用范围的，见下边。

2 single-transaction 选项和 lock-all-tables 选项是二选一的，前者是在导出开始时设置事务隔离状态并使用一致性快照开始事务,而后马上unlock tables，然后执行导出,导出过程不影响其它事务或业务连接，但只支持类似innodb多版本特性的引擎，因为必须保证即使导出期间其它操作(事务点t2)改变了数据，而导出时仍能取出导出开始的事务点t1时的数据。而lock-all-tables则一开始就 FLUSH TABLES WITH READ LOCK; 加全局读锁，直到dump完毕。
-- 关于一致性快照，简单地说，就是通过回滚段能记录不同的事务点的各版本数据
-- single-transaction 的流程如下：
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
SHOW MASTER STATUS		-- 这一步就是取出 binlog index and position
UNLOCK TABLES
...dump...

3 master_data 选项开启时默认会打开lock-all-tables，因此同时实现了两个功能，一个是加锁，一个是取得log信息。
  master_data取1和取2的区别，只是后者把 change master ... 命令注释起来了，没多大实际区别；

4 当master_data和 single_transaction 同时使用时，先加全局读锁，然后设置事务一致性和使用一致性快照开始事务，然后马上就取消锁，然后执行导出。过程如下
FLUSH TABLES WITH READ LOCK
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
SHOW MASTER STATUS		-- 这一步就是取出 binlog index and position
UNLOCK TABLES
...dump...

5 总结，了解了这些选项作用后，使用起来就明确了.
如果需要binlog信息则使用 master_data; 
如果不想阻塞同时表是innodb引擎可使用 single_transaction 取得一致性快照(取出的数据是导出开始时刻事务点的状态)
如果表不支持多版本特性，则只能使用 lock-all-tables 阻塞方式来保证一致性的导出数据。
当然，如果能保证导出期间没有任何写操作，可不加或关闭 lock-all-tables

4、mysqldump全量备份+mysqlbinlog二进制日志增量备份

从mysqldump备份文件恢复数据会丢失掉从备份点开始的更新数据，所以还需要结合mysqlbinlog二进制日志增量备份。确保my.ini或者my.cnf中包含下面的配置以启用二进制日志，或者mysqld ---log-bin：

1 2	[mysqld] log-bin=mysql-bin

 mysqldump命令必须带上--flush-logs选项以生成新的二进制日志文件：

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

这样生成的增量二进制日志文件比如为mysql-bin.000003，那么恢复数据时如下：

1 2	shell> mysql -uroot -pPwd < backup_sunday_1_PM.sql shell> mysqlbinlog mysql-bin.000003 | mysql -uroot -pPwd

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

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行将恢复到停止位置为止的所有事务。下一行将恢复从给定的起始位置直到二进制日志结束的所