mysql - sync_binlog 参数

Question

我正在浏览sync_binlog 参数的文档，发现sync_binlog 参数文档中存在差异。

这里的文档http://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_sync_binlog说：

值 1 是最安全的选择，因为在发生崩溃时，您最多会从二进制日志中丢失一个提交组。

这本质上意味着数据将被更新，但可能不在二进制日志中。

但是，在这里的二进制日志文档http://dev.mysql.com/doc/refman/5.6/en/binary-log.html说：

例如，如果您使用 InnoDB 表，并且 MySQL 服务器处理一个COMMIT语句，它会按顺序将许多准备好的事务写入二进制日志，同步二进制日志，然后将该事务提交到 InnoDB。如果服务器在这两个操作之间崩溃，事务会在重启时被 InnoDB 回滚，但仍然存在于二进制日志中。

这实质上意味着事务首先写入 binlog，然后提交到 InnoDB，因此在发生崩溃的情况下，该行有可能在 binlog 中但在数据库中不存在。

我已经在 MySQL 论坛中提出了这个问题并等待回复，但如果使用过此参数的人能详细说明以下两种行为中哪一种是正确的，我将不胜感激？

Answer 1

在服务器本身中同步与在复制设置中与从站同步不同。

binlog（因此，不是sync_binlog和“组提交”）不用于Master 上InnoDB 表的完整性。但是，正如您所指出的，它涉及到.

您提到的崩溃将在日志写入本地机器后发生，因此本地机器（如果它恢复正常）可以恢复。但是“组提交”可能无法到达奴隶。即使它到达 binlog，也不能保证任何 Slave（更不用说，所有 Slave）都已经获得了该值。

另请参阅“半同步”复制，其中至少一个从站必须在确认提交之前确认。

您引用的内容暗示事务可以到达从站，但在主站上回滚。我认为这种情况有一个开放的错误。

GTID 也混淆了这个问题。可能是您提出的某些报价早于 GTID 并且需要更新。

考虑在http://bugs.mysql.com上报告这个。