在 MySQL 中，为什么关闭 innodb_support_xa 进行单线程更新是安全的？

Question

在 MySQL 的文档中，有关 innodb_support_xa 选项的说明如下：

启用 InnoDB 对 XA 事务中两阶段提交的支持，从而导致事务准备时需要额外的磁盘刷新。此设置是默认设置。 XA 机制在内部使用，对于任何打开二进制日志并从多个线程接受数据更改的服务器来说都是必不可少的。 如果将其关闭，则事务可以按照与实时数据库提交事务的顺序不同的顺序写入二进制日志。当在灾难中重播二进制日志时，这可能会产生不同的数据恢复或在复制从属设备上。不要在复制主服务器上将其关闭，除非您有一个不寻常的设置，其中只有一个线程能够更改数据。

对于仅从一个线程接受数据更改的服务器，这是安全的，建议关闭此选项以提高 InnoDB 表的性能。例如，您可以在复制时将其关闭仅复制 SQL 线程正在更改数据的从属服务器。

然而，根据我对臭名昭著的组提交错误的理解，2PC 用于保证事务日志和binlog包含相同的事务集，而prepare_commit_mutex负责确保相同的顺序。

有了prepare_commit_mutex，事务日志和binlog的写入就已经序列化了，那么多线程更新和单线程更新有什么区别呢？

另一方面，即使只有一个线程可以更改数据，没有2PC，如果在事务写入binlog之后、写入事务日志之前发生崩溃，Innodb将如何处理恢复情况如何？理论上它可以简单地执行binlog中未完成的事务，就像slave所做的那样，但我怀疑Innodb实际上是这样做的，因为否则为什么我们需要2PC呢？

我对MySQL的内部结构一点也不熟悉，所以如果我错了，请原谅我。谢谢！

Answer 1

首先...

http://yoshinorimatsunobu.blogspot .com/2009/08/great-performance-effect-of-fixing.html

在InnoDB Plugin 1.0.4之前，它是这样的：

obtain mutex
  write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
  write binlog (fsync as appropriate if sync_binlog > 0)
  write innodb log and fsync, for commit-phase
release mutex

InnoDB上和之后插件 1.0.4（和 MySQL 5.5），现在是：

write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
obtain mutex
  write binlog (fsync as appropriate if sync_binlog > 0)
  write innodb log, for commit-phase
release mutex
fsync innodb log, for commit-phase

如您所见，在新版本中，临界区中没有任何内容（除了 sync_binlog > 0 的情况）。这样，组提交现在就可以工作并确保更好的并发吞吐量。

例如，在之前的“损坏”版本中，如果您有 100 个线程并发提交，则所有 fsync 都会被序列化，您将获得 100 个 fsync 用于准备，另外 100 个 fsync 用于提交。因此，小组提交完全被破坏了。

现在，在较新的实现中，fsync 根据事务的并发性进行分组，同时确保 innodb log 和 binlog 之间的操作顺序。这也意味着如果只有一个线程，则不会有任何性能提升。

至于你的问题，当在事务写入二进制日志之后但在写入事务日志之前发生崩溃时 - 我和你在同一页上。

如果服务器在最后一步之前崩溃，则 innodb 日志和 binlog 之间有可能存在差异（其中一个可能领先于另一个），但可以保证您拥有有关要处理的所有信息。检查 innodb 日志中的内容，因为它是在准备阶段记录的。

然而，如何处理未提交的内容仍然不确定。例如，除非 sync_binlog = 1，从属设备有可能收到数据，但尚未完全同步主设备上的 binlog。您不能只重做失败的事务，因为它可能已经在其中一个从属设备上运行。

这也意味着，binlog 可能比 innodb 日志短，返回“二进制日志 [file_name] 比其预期大小短”。正如官方文档中所述，您必须从头开始重建从站。不太人性化。

http://dev.mysql.com/doc/refman/5.1 /en/binary-log.html

由于操作顺序的一致性保证独立于 innodb_support_xa 设置（这与官方文档中所说的相矛盾） innodb_support_xa，可能是因为它是关于库存 innodb 5.0.3 远在并发修复之前编写的），并且即使使用 也不能严格保证主站上的 innodb 日志和从站上的中继日志之间的一致性>innodb_support_xa，我认为使用innodb_support_xa没有任何意义。不过，不遵循官方建议是很可怕的，但它在很多方面似乎陈旧且错误。

我想知道当前者设置为 2 或 0 时，innodb_flush_log_at_trx_commit 设置与 innodb_support_xa 行为之间是否存在任何相关性。

一种实用的思维方式是，故障转移到从属设备是安全的 - 毕竟，失败的事务是您想要完成的事情 - 但永远不会故障恢复到主设备，因为数据中可能存在一些差异。在将主站变成新的从站之前，您需要从从站完全复制数据。换句话说，当主服务器崩溃时，从此信任从服务器 - 这样，您就不需要为了崩溃恢复而搞乱 innodb 日志。

另请注意，MySQL 5.5 支持半同步复制，与“信任从属”相同 - 我想您可能会感兴趣。

http://dev.mysql.com/doc/refman/5.5 /en/replication-semisync.html