我正在使用mysql-binlog-connector来监听任何binlog事件，然后在slave DB上执行复制。 我的问题是，binlog在执行之后和提交之前注册事件，所以如果有任何回滚事件仍然从binlog条目中拾取并复制到从属设备上。 有没有办法解决这个问题？
从binlog手册中，我得到了这个机制工作方式稍有不同的印象：
在未提交的事务中，更改事务表（例如InnoDB表）的所有更新（UPDATE，DELETE或INSERT）都将被caching，直到服务器接收到COMMIT语句。 此时，mysqld在执行COMMIT之前将整个事务写入二进制日志。
换句话说，在实际发出COMMIT之前，根本没有任何事务被写入到二进制日志中，或者事务将事务处理到二进制日志意味着没有发出ROLLBACK！
一旦COMMIT已经发出：那么首先完整的事务被写入二进制日志，然后COMMIT得到执行，最后，只有在COMMIT成功完成后，COMMIT才会被login到二进制日志中。
然后，手册继续处理几个边缘案例及其缓解措施（ sync_binlog=1 ＆ – --innodb_support_xa ），这可能会减轻您的担忧：
从MySQL 5.7.7开始，二进制日志默认同步到磁盘（
sync_binlog=1）。 在MySQL 5.7.7之前，它不是（sync_binlog=0）。 因此，在MySQL 5.7.7之前，如果操作系统或机器（不仅是MySQL服务器）崩溃，那么二进制日志的最后一条语句就有可能丢失。 为防止出现这种情况，请在每N个提交组之后，使用sync_binlog系统variables将二进制日志同步到磁盘。 请参见第5.1.4节“服务器系统variables”。 sync_binlog的最安全值是1，但这也是最慢的。 即使将sync_binlog设置为1，在发生崩溃的情况下，表内容和二进制日志内容之间仍有可能出现不一致。例如，如果您使用的是InnoDB表，并且MySQL服务器处理了一个COMMIT语句，它会将许多准备好的事务顺序写入二进制日志，同步二进制日志，然后将此事务提交到InnoDB。 如果服务器在这两个操作之间崩溃，则事务在重新启动时由InnoDB回退，但仍然存在于二进制日志中。 假设
--innodb_support_xa设置为1则解决此问题