mysql快照原理_[转]深入理解mysqldump原理

本文转至：http://blog.csdn.net/cug_jiang126com/article/details/49824471

在mysqldump过程中，之前其实一直不是很理解为什么加了--single-transaction就能保证innodb的数据是完全一致的，而myisam引擎无法保证，必须加--lock-all-tables，前段时间抽空详细地查看了整个mysqldump过程。

理解master-data和--dump-slave

--master-data=2表示在dump过程中记录当前库的binlog和pos点，并在dump文件中注释掉这一行；

--master-data=1表示在dump过程中记录当前库的binlog和pos点，并在dump文件中不注释掉这一行，即恢复时会执行；

--dump-slave=2表示在dump过程中，在从库dump，mysqldump进程也要在从库执行，记录当时主库的binlog和pos点，并在dump文件中注释掉这一行；

--dump-slave=1表示在dump过程中，在从库dump，mysqldump进程也要在从库执行，记录当时主库的binlog和pos点，并在dump文件中不注释掉这一行；

注意:在从库上执行备份时，即--dump-slave=2，这时整个dump过程都是stop io_thread的状态

深入理解--single-transaction：

打开general_log，准备一个数据量较小的db，开启备份，添加--single-transaction和--master-data=2参数，查看general_log，信息如下，每一步添加了我的理解

整个dump过程是同一个连接id 32，这样能保证在设置session级别的变量的时候不影响到其他连接

thread_id: 32

argument: ucloudbackup@localhost on

*************************** 14. row ***************************

thread_id: 32

argument: /*!40100 SET @@SQL_MODE='' */

*************************** 15. row ***************************

thread_id: 32

argument: /*!40103 SET TIME_ZONE='+00:00' */

*************************** 16. row ***************************

thread_id: 32

argument: FLUSH /*!40101 LOCAL */ TABLES

*************************** 17. row ***************************

thread_id: 32

argument: FLUSH TABLES WITH READ LOCK

批注：因为开启了--master-data=2，这时就需要flush tables with read lock锁住全库，记录当时的master_log_file和master_log_pos点

*************************** 18. row ***************************

thread_id: 32

argument: SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ

批注：--single-transaction参数的作用，设置事务的隔离级别为可重复读，即REPEATABLE READ，这样能保证在一个事务中所有相同的查询读取到同样的数据，也就大概保证了在dump期间，如果其他innodb引擎的线程修改了表的数据并提交，对该dump线程的数据并无影响，然而这个还不够，还需要看下一条

*************************** 19. row ***************************

thread_id: 32

argument: START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */

这时开启一个事务，并且设置WITH CONSISTENT SNAPSHOT为快照级别(如果mysql版本高于某一个版本值，我还不大清楚40100代表什么版本)。想象一下，如果只是可重复读，那么在事务开始时还没dump数据时，这时其他线程修改并提交了数据，那么这时第一次查询得到的结果是其他线程提交后的结果，而WITH CONSISTENT SNAPSHOT能够保证在事务开启的时候，第一次查询的结果就是事务开始时的数据A，即使这时其他线程将其数据修改为B，查的结果依然是A，具体的测试看我下面的测试结果

*************************** 20. row ***************************

thread_id: 32

argument: SHOW MASTER STATUS

这时候执行这个命令来记录当时的master_log_file和master_log_pos点，注意为什么这个时候记录，而不是再18 row和19 row之间就记录，个人认为应该都是可以的，这里是测试结果，start  transaction并不会产生binlog的移动，而18 row和19 row的动作也在同一个thread id中

mysql> show master status;

+------------------+----------+--------------+------------------+

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000003 |     1690 |              |                  |

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

mysql> START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */;

Query OK, 0 rows affected (0.00 sec)

mysql> show master status;

+------------------+----------+--------------+------------------+

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000003 |     1690 |              |                  |

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

*************************** 21. row ***************************

thread_id: 32

argument: UNLOCK TABLES

等记录完成后，就立即释放了，因为现在已经在一个事务中了，其他线程再修改数据已经无所谓，在本线程中已经是可重复读，这也是这一步必须在19 rows之后的原因，如果20 rows和21 rows都在19 rows之前的话就不行了，因为这时事务还没开启，一旦释放，其他线程立即就可以更改数据，从而无法保证得到事务开启时最准确的pos点。