mysql主主数据复制一致性答案

【问题标题】：mysql master-master data replication consistencymysql主主数据复制一致性
【发布时间】：2014-02-07 09:06:48
【问题描述】：

众所周知，mysql 是异步进行复制的。我听说我需要一些额外的插件来做
同步复制。

那么让我们考虑一下异步复制的情况： master 将事件写入其二进制日志，但不知道 master2 是否或何时检索并处理了它们。使用异步复制，如果 master1 崩溃，它已提交的事务可能不会传输到任何 master2。

我的问题是这些事务是否会在 master1 再次启动时最终被复制到 master2？如果不是，那就是一个很大的不一致问题。

对于主从复制，我的问题是相同的，并且 master 出现了同样的情况。

我需要一些特殊的配置参数来让它自动发生吗？

或者我是否必须手动从 master1 转储数据并导入到 master2 等？

======

更新：我可能误用了上面的“崩溃”这个词，我只是想参考一下master1在一段时间内无法将数据同步给其他人的情况。下面的回复（感谢）包括两种情况：例如由于磁盘故障而导致的真正不可恢复的崩溃，或由于网络问题而导致的暂时离线问题等。

【问题讨论】：

谁说 master1 会回来？可能是硬件出了问题。如果一致性对您很重要，那么您需要能够验证一致性的东西。 Percona 的 XtraDB Cluster 是一个常见的选择。
我只是假设 master1 稍后会回来。假设故障不是由于硬件故障，而是网络问题等。
Ceejayoz：感谢您为 Percona XtraDB 集群提供的意见。我也注意到类似的东西：Galera Cluster。市场上，谁是mysql数据复制解决方案的领导者？
Percona 在后台使用 Galera。我想大多数人会认为 Percona 的解决方案是同步 MySQL 复制的领导者之一。

标签： mysql database database-replication transactional-replication

【解决方案1】：

如果master1在中断后重新上线，并且binlogs没有丢失，那么replica可以下载它错过的任何binlogs。对于本次讨论，master2 是一个副本。

当然，如果 master1 的崩溃严重到足以损坏或丢失其二进制日志，那么你就不走运了。

也有 master1 将更改写入其数据库但 binlog 条目在崩溃中丢失的情况。要解决此风险，您可以设置sync_binlog=1，以便 master1 上的事务要求相应的 binlog 条目在磁盘上是安全的，否则事务无法完成。

但是在每次 COMMIT 时将 binlog 同步到磁盘会产生一些开销，而且许多网站认为他们宁愿拥有性能而不是数据安全。确实，某些工作负载的每秒事务处理率太高，无法实现这一点。 IE。每秒磁盘同步数有一个物理上限。然后，解决方案需要获得更快的磁盘（或 SSD），或者将工作负载分散到多台服务器上。

我还看到了相反的情况：binlog 条目被写入 master1 上的文件系统缓存，副本下载该 binlog 条目并应用它，但该条目永远不会将其写入 master1 上的磁盘，因为的磁盘出现间歇性故障。具有讽刺意味的是，副本处理的更改从未提交到主服务器上的磁盘！

您提到了同步复制的可能性。 MySQL 并没有这个选项。它们最接近的是Semisynchronous Replication，这意味着在至少一个半同步副本确认它已收到事务的二进制日志条目之前，不允许提交 master1 上的事务。这意味着您将永远不会有像上面描述的那样的差异。但这会为每个 COMMIT 增加一些延迟。

为什么它是“半”同步的？因为 master1 上的 COMMIT 不需要等待事务在副本上执行，它只需要等待副本确认接收到 binlog 事件。副本仍然可能落后。

@ceejayoz 的评论提到了Percona XtraDB Cluster。这与半同步复制非常相似，因为在 COMMIT 期间，写入节点必须将该事务的日志传输到集群中的所有其他节点。所以延迟是最慢节点确认接收事件的速度。

【讨论】：

非常感谢。我在看半同步，需要额外的插件。还要感谢您对 Percona XtraDB 集群的投入。我也注意到类似的东西：Galera Cluster。市场上，谁是mysql数据复制解决方案的领导者？
Percona XtraDB 集群使用 Galera。

【解决方案2】：

如果 master1 崩溃，提交的事务将在日志文件中可用，一旦再次启动，它们将被传递给从属，在这种情况下，master2。如果根据您的配置，当 master1 关闭时 master2 提交了相同的主键值，您将遇到不一致的问题。

您可以通过服务器分配不同的主键来防止这种情况发生——例如，一个只写奇数，而另一个写偶数。甚至是使用服务器 ID 的组合主键。

【讨论】：

我配置了auto-increment-increment，并为不同的节点设置了不同的auto-increment-offset值，所以我认为它可以防止主键问题。
你的意思是只要事务日志在logfile里面，当master1再次up时，它就会写到slave。所以基本上你对我的问题的回答是数据将被传输到master2？
从站应该有不同的自动增量偏移和相同的自动增量。那么你应该在逻辑上是安全的，但当然不能避免损坏日志文件的磁盘崩溃......
是的，主服务器将其所有事务记录到日志文件中。从站获取更新并存储日志文件位置（它确实停止的位置），当从站可以再次到达主站时，它从它获得的最后一个位置查询，并请求更新。
这不仅适用于服务器崩溃，也适用于连接中断（如果服务器位于不同的网络上）。