Chr*_*ltz 5 mysql mysqldump backup master-slave-replication
我最近意识到，--master-data当我真正想要的是时，我正在使用从复制从属转储备份--dump-slave。切换到 后--dump-slave，我发现这mysqldump将在备份期间停止从属 SQL 线程（这从文档中可以清楚地看出 - 这并不奇怪）。
我想知道是否有人可以解释为什么整个备份需要停止从属服务器的 SQL 线程？我正在使用--single-transaction，并且希望在备份开始时获得一致的快照。即使事务由 SQL 线程处理，这也应该是可能的。即使从属 SQL 线程由于已mysqldump获取某些锁而完全被阻塞，也应允许从属在备份期间继续（尝试）执行 SQL DML 语句。
我也可以理解希望至少暂停从属 SQL 线程，以便 get-slave-status 然后启动事务操作可以一致地发生，但是一旦转储操作开始，从属 SQL 线程就可以重新启动，对吧？
当--master-data与复制主机一起使用时，全局锁被获取一次然后释放，从而允许常规应用程序负载在转储操作期间继续。为什么不能以同样的方式在从属设备上完成此操作？任何人可以提供的任何信息都会非常有帮助。
--single-transaction显然只为事务表保留一个事务。
需要STOP SLAVE保持 MyISAM 表转储的一致性。如果 mysqldump 中有逻辑首先转储 MyISAM 表，那么它可以START SLAVE在此时（在不同的连接中，可能是START SLAVE隐式提交），然后继续转储 InnodDB 表。
STOP SLAVE由于 DLL 不是事务性的，因此也是必需的。可能发生的情况是，在转储表时，复制流中可能会出现CREATE TABLE/ DROP TABLE，并且由于这些不是事务性的，因此转储将不一致。
为什么--master-data假设它不是奴隶并且不需要相同级别的保护，每个人都在猜测。为什么--master-data发出FLUSH TABLES WITH READ LOCK周围转储位置信息而转储从属设备却没有？为什么会UNLOCK TABLES在数据转储开始之前发生？也是一个谜。