Edw*_*ang 6 mysql replication mysql-5.1
众所周知，从 MySQL 5.1.12 到 MySQL 5.1.28 的默认混合模式复制。然而，这被恢复了，并且在当前时刻，基于语句的复制是默认的。
在声明默认基于语句的复制中，Oracle声称这只是因为混合模式复制构成了一种行为改变，可能会引起一些用户不知道。（另请参阅Bug 39812。）然而，MySQL 5.1 有许多行为变化，因为混合基复制的好处如此明显（我相信每个 DBA 都遇到过复制失败的情况，因为用户提交了一个查询没有正确复制并导致他们的数据库出现分歧），这似乎不是一个特别有力的理由。
有一些人抱怨混合复制“可以提供两全其美，但需要测试”，但我们已经在 MySQL 5.1.61 上，人们希望现在所有错误都已解决。所以这让我们很困惑。为什么混合模式复制不是默认的？
我最近也问自己这个问题。首先，我查看了为什么默认情况下未启用基于行的复制。显然，基于行的复制通过可能写入二进制日志的数据量在磁盘上创建了 IO 应变的可能性。
毫不奇怪，这是MySQL 文档提到的基于行的复制的第一大缺点。再往下一点，另一个缺点是 MyISAM 的潜在性能问题：
对于使用 MyISAM 存储引擎的表，当将它们作为基于行的事件应用到二进制日志时，INSERT 语句的从站上需要更强的锁，而不是将它们作为语句应用时。这意味着在使用基于行的复制时不支持对 MyISAM 表的并发插入。
MyISAM 是 5.1 系列的默认引擎。直到 5.5 才默认 InnoDB。对我来说，这种对 MyISAM 的复制影响是默认情况下不使用 RBR 的一个重要原因。
但是您的问题围绕MIXED 格式。在 MIXED 格式下，默认情况下使用基于语句的复制，直到调用需要基于行的复制的语句。上面的链接很好地概述了在某些情况下执行的日志类型（安全、不安全、行注入）。
我认为有太多潜在情况会导致复制切换到基于行的复制，从而在非最佳硬件上导致上面提到的一些性能问题。让我们面对现实，MySQL 有大量用户在非最佳硬件上运行它。
这种情况对我来说最为突出：
如果语句按行记录并且执行该语句的会话有任何临时表，则所有后续语句（访问临时表的语句除外）都使用按行记录，直到删除该会话正在使用的所有临时表。
请注意，在基于行的日志记录中涉及临时表的所有语句都被认为是不安全的，因此这可能会导致复制设置出现问题。
最终，我认为将 STATEMENT 设为默认值是个好主意，必须做出有意识的、受过教育的决定以切换到 MIXED。
根据当前文档，SBR是MySQL 5.5的默认设置
在问题中，它说It is well known that mixed-mode replication was default from MySQL 5.1.12 to MySQL 5.1.28.
然而，值得注意的是
鉴于此，从技术上来说，MySQL 5.1 的早期 GA 版本始终默认为 SBR。此外
所以，正确的问题是Why did MySQL AB not incorporate mixed-mode replication in MySQL 5.1?
恕我直言，我很容易看出情况就是如此。甲骨文自然会采取不干涉的方式来描述问题并声称承担任何责任。虽然 Oracle 一直在其旗舰数据库中使用 RBR，但我不认为 Oracle 会介入以使 RBR 在 MySQL 中受到任何关注。
从另一个角度来看，由于 MySQL 可以轻松地在商用硬件上运行，因此 SBR 就足够了。人们也不会被快速增长的二进制日志打死。具有高级复制设置的大型 MySQL 安装将更适合 RBR。
解决使用 SBR、RBR 和 Mixed 的问题应该像清除所有中继日志并在任何给定 Slave 上从头开始复制一样简单。
| 归档时间： |
|
| 查看次数： |
4184 次 |
| 最近记录： |