sync_binlog参数
我正在查看sync_binlog参数的文档，发现sync_binlog参数文档中有一个不一致之处。
这里的文档binlog说：
值1是最安全的选择，因为在发生崩溃时，您最多会从二进制日志中丢失一个提交组。
这在本质上意味着数据将被更新，但可能不在绑定日志中。
但是，在这里的二进制日志文档中，http://dev.mysql.com/doc/refman/5.6/en/binary-log.html说：
例如，如果您使用InnoDB表，而MySQL服务器处理一个COMMIT语句，则它将许多准备好的事务依次写入二进制日志，同步二进制日志，然后将该事务提交到InnoDB中。如果服务器在这两个操作之间崩溃，事务将在重启时由InnoDB回滚，但仍然存在于二进制日志中。
这在本质上意味着事务首先是用二进制日志编写的，然后提交给InnoDB，所以在崩溃的情况下，行可能在二进制日志中，但在数据库中不存在。
我在MySQL论坛上问过这个问题，等待回复，但是如果有人使用了这个参数，能给出以下两种行为中哪一种是正确的，我会很感激吗？
回答 1
Stack Overflow用户
发布于 2016-09-07 16:06:46
服务器本身中的同步与复制设置中的从服务器同步不同。
绑定日志(因此，不是sync_binlog和“组提交”)不用于主表上的InnoDB表的完整性。然而，正如你所指出的，这是涉及到的。
您提到的崩溃将发生在日志被写入本地机器之后，因此本地机器(如果它恢复)可以恢复。但是，“集体承诺”可能不会被奴隶所接受。即使它到达了二进制日志，这也不能保证任何奴隶(更不用说，所有奴隶)都已经得到了这个值。
也请参阅“半同步”复制，其中至少有一个奴隶必须在提交被破坏之前确认。
您引用了一些暗示事务可以到达奴隶，但在主服务器上被回滚的内容。我想那个案子有个漏洞。
GTID也混淆了这个问题。这可能是你在GTID之前所做的一些引号需要更新。
请考虑在http://bugs.mysql.com上报告这一情况。
https://stackoverflow.com/questions/39372545
复制相似问题
腾讯云开发者
