我目前有一个MySQL双主复制（A＆lt; - ＆gt; B）设置，一切似乎都在游泳。我借鉴了here和here的基本想法。
服务器A是我的网络服务器（VPS）。用户与应用程序的交互导致对表X中的多个字段的更新（这些字段被复制到服务器B）。服务器B是重型升降机，完成所有重大计算。服务器B上的cron作业定期向表X添加行（将其复制到服务器A）。
因此服务器A可以更新（但从不添加）行，服务器B可以添加行。服务器B还可以更新X中的字段，但只有 之后用户才能更新该行。
如果我用这种方式进行生产，我可以期待哪种潜在的灾难？或者看起来好吗？我问的主要是因为我不知道任何同时操作表（来自A副本或B副本）是否会导致问题，或者它是否只是对的操作相同行变得毛茸茸。
答案 0 :(得分：11)
如果您尝试在两个主服务器上写入同一数据库，则双主复制会很混乱。
争论（和高血压）最大的一点是use of autoincrement keys。
只要您记得设置auto_increment_increment和auto_increment_offset，就可以查找所需的任何数据并检索auto_incremented ids。
您只需记住此规则：如果从serverX读取id，则必须使用相同的ID从serverX查找所需的数据。
这是使用双主复制的一种保存优雅。
假设你有
如果您施加以下限制
那么你不需要设置auto_increment_increment和auto_increment_offset。
我希望我的回答澄清使用双主复制的好，坏和丑陋。
答案 1 :(得分：3)
我认为你可以依靠
Percona XtraDB Cluster Feature 2: Multi-Master replication比常规MySQL复制
他们向这些人保证：
通过Multi-Master我的意思是能够写入群集中的任何节点，并且不用担心最终会导致不同步的情况，因为如果您不正确地写入错误的服务器，它会经常发生在常规MySQL复制中
使用Cluster，您可以写入任何节点，并且群集可以保证写入的一致性。也就是说，写入要么在所有节点上提交，要么根本没有提交。
多主体架构的两个重要后果。
首先：我们可以有几个并行工作的应用程序。这给了我们真正的并行复制。 Slave可以有很多并行线程，你可以通过变量wsrep_slave_threads来调整它
第二：从机与主机不同步时可能会有一段时间。发生这种情况是因为主设备可以比从设备更快地应用事件。如果您从从站读取，您可能会读取尚未更改的数据。你可以从图中看到。但是，您可以使用变量wsrep_causal_reads = ON来更改此行为。在这种情况下，从器件上的读操作将等待直到应用事件（但这会增加读取的响应时间。从器件和主器件之间的这个间隙是这个复制命名为“virtually synchronous replication”的原因，而不是真正的“ synchronous replication”
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.
答案 2 :(得分：2)
Master-master复制可能非常棘手，您确定这是最适合您的解决方案吗？通常它用于负载平衡目的（例如，循环连接到数据库服务器），有时用于避免复制滞后效应。一个众所周知的问题是auto_increment问题，据说可以使用不同的偏移量和增量值来解决。
我认为你应该把你的配置修改为简单的主从，通过使A成为主设备而B成为从设备，除非我误解了你的系统要求。
答案 3 :(得分：2)
根据我在这个主题上的相当广泛的经验，我可以说你有一天会遗憾地写给不止一位大师。它可能很快，可能不会持续很长时间，但它会发生。你将有两个服务器，每个服务器都有一些正确的数据和一些错误的数据，你要么选择一个作为权威来源并抛弃另一个（可能不知道你扔掉了什么），或者你将调和两个。无论你如何设计它，你都无法消除这种情况发生的可能性，因此有一天它会发生在数学上的确定性。
Percona（我的雇主）在做了你正在尝试的事情之后，已经处理了数百个恢复案例。其中一些需要几个小时，一些需要几个星期，一个我帮助了几个月 - 而且这是一个很好的工具来帮助。
使用其他复制技术或找到其他方法来执行您想要执行的操作。 MMM无济于事 - 它将更快带来灾难。无论是否使用外部工具，您都无法使用标准MySQL复制执行此操作。您需要替换复制技术，例如Continuent Tungsten或Percona XtraDB Cluster。
如果你想使用vanilla MySQL复制，通常更容易以其他方式解决实际需求并放弃多主机写入。
答案 4 :(得分：2)
感谢分享我的Master-Master Mysql集群文章。正如Rolando所阐明的那样，由于自动增量支持的限制，这种配置不适合大多数生产环境。
获得MySQL集群的最佳方法是使用NDB，它需要至少4台服务器（2个管理和2个数据节点）。
我写了一篇详细的文章，只在两台服务器上运行，这与我之前的文章非常相似，但使用的是NDB。
请注意，我始终建议您分析您的需求并找出最合适的解决方案，不要只寻找可用的解决方案，并尝试确定它们是否符合您的需求。
-Hatem
答案 5 :(得分：-1)
我强烈建议您寻找能够为您管理此工具的工具。如果出现问题，多主复制可能会非常麻烦。
我会建议像Percona XtraDB Cluster这样的东西。我一直在关注这个项目，它看起来很酷。我绝对认为它将成为MySQL世界中的游戏规则改变者。它仍处于测试阶段。