在不停复制的MySQL从库执行mysqldump --single-transaction是否可行？

嘿，这两个问题其实是很多做MySQL备份的同学都会碰到的，我来给你掰扯清楚：

答案是分情况，核心要看你那部分MyISAM表的情况：

• 对于占绝大多数的InnoDB表来说，--single-transaction是完全安全的。这个参数会开启一个一致性读的事务，利用InnoDB的MVCC特性，让整个dump过程都基于事务启动时的数据快照，不会锁表，也不会影响从库的复制进程（复制线程依然可以正常应用主库的binlog）。
• 但少数的MyISAM表就不一样了——MyISAM不支持事务，mysqldump碰到MyISAM表时，会自动使用LOCK TABLES来锁表，直到这个表dump完成。如果你的MyISAM表很小，锁表时间极短，那基本没影响；但如果MyISAM表很大，锁表期间从库的复制线程可能会因为无法更新这些表而产生延迟。

另外要注意：--single-transaction和--lock-all-tables是互斥的，千万别同时用；而且最好确保从库的复制延迟不大，不然你dump出来的可能是比较旧的数据（但逻辑上对InnoDB来说是一致的）。

完全不是指“最新数据”！这里的一致数据指的是某个固定时间点的、逻辑上无冲突的完整数据集。举个例子：

• 如果不停止复制，从库一直在同步主库的更新，你可能刚dump完订单表，从库就同步了一条订单状态的更新，接着再dump订单详情表——这时候订单表和订单详情表的数据就不是同一个时间点的，可能出现“订单已经完成，但详情还显示未发货”这种逻辑矛盾。
• 而停止复制后，从库的数据会停在某个精确的时刻，所有表的状态都定格在这个时间点，dump出来的数据集就是逻辑完全一致的，不会有跨表的数据冲突。

补充一句：用--single-transaction对InnoDB表能实现这种时间点一致性，但MyISAM表因为锁表的原因，它的数据状态是锁表那一刻的，和InnoDB的快照时间点可能不一致，所以如果你的库混合了引擎，想要100%的全局一致性，还是建议先stop slave，dump完成后再start slave。

内容的提问来源于stack exchange，提问作者user