我目前有一个 MySQL 双主复制 (AB) 设置，一切似乎都在顺利运行。我借鉴了here 和here 的基本思想。
服务器 A 是我的网络服务器（VPS）。用户与应用程序的交互导致表 X 中的几个字段的更新（这些字段被复制到服务器 B）。服务器 B 是重担，所有的大计算都在这里完成。服务器 B 上的 cron 作业定期将行添加到表 X（复制到服务器 A）。
所以服务器 A 可以更新（但从不添加）行，而服务器 B 可以添加行。服务器 B 也可以更新 X 中的字段，但只有在用户不再具有更新该行的能力之后。
如果我使用这种场景进行生产，我可以预料到什么样的潜在灾难？或者这看起来没问题？我之所以问，主要是因为我不知道表上的 any 同步操作（来自 A 副本或 B 副本）是否会导致问题，或者它是否只是对 相同的操作有毛的行。
【问题讨论】：
标签： mysql replication
如果您尝试在两个 master 上写入同一个数据库，则双 master 复制会很麻烦。
最大的争论点之一（和高血压）是use of autoincrement keys。
只要你记得设置auto_increment_increment和auto_increment_offset，你就可以查找任何你想要的数据并检索auto_incremented ids。
您只需要记住这条规则：如果您从 serverX 读取 id，则必须使用相同的 id 从 serverX 查找所需的数据。
这是使用双主复制的一大优势。
假设你有
如果您施加以下限制
那么你不需要设置auto_increment_increment和auto_increment_offset。
我希望我的回答能阐明使用双主复制的好处、坏处和丑陋。
【讨论】：
根据我在这个主题上相当丰富的经验，我可以说有一天你会后悔给不止一位大师写信。可能很快，可能不会很长时间，但它会发生。您将拥有两台服务器，每台服务器都有一些正确的数据和一些错误的数据，您将选择一个作为权威来源并将另一个丢弃（可能并不真正知道您要丢弃什么），或者您将调和两者.无论您如何设计它，都无法消除这种情况发生的可能性，因此可以肯定它总有一天会发生。
Percona（我的雇主）在完成您尝试的操作后已经处理了大约数百个康复案例。其中一些需要数小时，一些需要数周，而我帮助完成的一项需要几个月的时间——而这需要出色的工具来提供帮助。
使用不同的复制技术或找到不同的方法来做你想做的事。 MMM 无济于事——它会更快地带来灾难。使用标准 MySQL 复制，无论是否使用外部工具，都无法做到这一点。您需要替代复制技术，例如 Continuent Tungsten 或 Percona XtraDB Cluster。
如果您想使用普通 MySQL 复制，通常更容易以其他方式解决实际需求并放弃多主写入。
【讨论】：
感谢分享我的 Master-Master Mysql 集群文章。正如 Rolando 澄清的那样，由于自动增量支持的限制，此配置不适用于大多数生产环境。
获得 MySQL 集群的最合适方法是使用 NDB，它至少需要 4 个服务器（2 个管理节点和 2 个数据节点）。
我写了一篇详细的文章来让它只在两台服务器上运行，这与我之前的文章非常相似，但使用的是 NDB。
请注意，我始终建议您分析您的需求并找出最合适的解决方案，不要只寻找可用的解决方案并试图弄清楚它们是否符合您的需求。
-仇恨
【讨论】：
我认为你可以依赖
Percona XtraDB Cluster Feature 2: Multi-Master replication 比常规 MySQL 复制
他们承诺如下：
我所说的 Multi-Master 是指能够写入集群中的任何节点，并且不用担心最终会出现不同步的情况，因为如果您不谨慎地写入错误的服务器，常规 MySQL 复制经常会发生这种情况.
使用集群，您可以写入任何节点，集群保证写入的一致性。也就是说，写入要么在所有节点上提交，要么根本不提交。
多主架构的两个重要后果。
首先：我们可以让多个应用程序并行工作。这为我们提供了真正的并行复制。 Slave可以有很多并行线程，可以通过变量wsrep_slave_threads进行调优
第二：可能有一小段时间，slave 与 master 不同步。发生这种情况是因为主设备可能比从设备更快地应用事件。如果您确实从从站读取，您可能会读取尚未更改的数据。你可以从图中看到。但是，您可以通过使用变量 wsrep_causal_reads=ON 来更改此行为。在这种情况下，slave 上的读取将等到应用事件（但这会增加读取的响应时间。slave 和 master 之间的这种差距是这个复制命名为“virtually synchronous replication”而不是真正的“@987654324”的原因@”
所描述的 COMMIT 行为也有第二个严重的含义。 如果您将写入事务运行到两个不同的节点，集群将使用乐观锁定模型。 这意味着事务不会在单个查询期间检查可能的锁定冲突，而是在 COMMIT 阶段检查。你可能会在 COMMIT 上得到 ERROR 响应。我要强调这一点，因为这是您可能会遇到的与常规 InnoDB 的不兼容之一。在 InnoDB 中，通常 DEADLOCK 和 LOCK TIMEOUT 错误发生在特定查询的响应中，但不会发生在 COMMIT 上。好吧，如果您遵循良好的做法，您仍然会在“COMMIT”查询后检查错误代码，但我看到许多应用程序不这样做。
So, if you plan to use Multi-Master capabilities of XtraDB Cluster, and run write transactions on several nodes, you may need to make sure you handle response on “COMMIT” query.
【讨论】：
主-主复制可能非常棘手，您确定这是最适合您的解决方案吗？通常它用于负载平衡目的（例如循环连接到您的数据库服务器），有时当您想要避免复制滞后效应时。一个已知的大问题是 auto_increment 问题，据说可以使用不同的偏移量和增量值来解决。
我认为您应该将配置修改为简单的主从，让 A 为主，B 为从，除非我对您的系统要求有误。
【讨论】：
我强烈建议您研究一种可以为您管理此问题的工具。如果出现问题，多主复制可能会非常麻烦。
我会建议像Percona XtraDB Cluster 这样的东西。我一直在关注这个项目，它看起来很酷。我绝对认为这将改变 MySQL 世界的游戏规则。不过它仍处于测试阶段。
【讨论】：