在MySQL中事务的提交Server层最后会调用函数ha_commit_trans()，该函数负责处理binlog层和存储引擎层的提交，它先调用 tc_log->prepare()在引擎层生成一个XA事务，然后再调用tc_log->commit()来提交事务，这里的tc_log是在mysqld启动时就生 成的一个MYSQL_BIN_LOG类的对象。简化后代码片断类似：

MYSQL_BIN_LOG::prepare()函数调用ha_prepare_low()，该函数再调用存储引擎层（这里指innodb）的prepare在存储层生成XA 事务。MYSQL_BIN_LOG::commit()先在binlog层加入一个Xid_log_event类型的日志作为XA事务在binlog层提交的标志，注意这 里并没有调用操作系统的fsync。该函数最后调用会调用MYSQL_BIN_LOG::ordered_commit()，做binlog文件的磁盘fsync和提交 到存储引擎。

  1. 将binlog数据刷写到文件中
  2. 将当前的binlog文件名和位点注册到semisync模块中，以便后面等待备机的回复
  3. 调用函数MYSQL_BIN_LOG::sync_binlog_file()将binlog文件sync到磁盘，到这里事务将不能回滚，即使mysqld崩溃了事务 也会最终提交。
  4. 调用MYSQL_BIN_LOG::update_binlog_end_pos()更新binlog最后sync的位点信息，这时为备库复制服务的binlog dump线程 才可以读到这个事务，可参考Log_event::read_log_event()
  5. 如果semisync模块配置了rpl_semi_sync_master_wait_point为 after_sync，那么当前Session将在这里等待备机回复再继 续。
  6. ordered_commit()接下来会最终调用到 ha_commit_low()在存储引擎层提交
  7. 如果rpl_semi_sync_master_wait_point参数为after_commit，当前Session就会在ordered_commit()接下来调用的 MYSQL_BIN_LOG::finish_commit()函数里等待备机的回复，

以上可以看出after_sync和after_commit的主要区别是，当备机确认收到日志时，主机上的该事务是否对其他session可见， after_sync是不可见（因为在存储引擎层还没有提交），after_commit是可见。after_commit可能导致在主机上被其他事务看 见了的事务在切换到备机后又消失了，所以MySQL 5.7默认使用after_sync。

mysqld崩溃之后的事务恢复最终是通过MYSQL_BIN_LOG::recover()进行的，调用栈： mysqld_main() -> init_server_components() -> MYSQL_BIN_LOG::open() -> MYSQL_BIN_LOG::open_binlog() -> MYSQL_BIN_LOG::recover()。open_binlog()函数通过binlog文件头上的标志可以知道该文件在mysqld退出时没有正常关闭，然 后就调用recover()函数进行恢复。

从以上MySQL事务提交和恢复流程可以看出，在最终备机提交事务，必然在主机上是提交的，也就是主机的事务必然比备机更全。

前文已经提到在MYSQL_BIN_LOG::ordered_commit()函数中，用户session会将要等待备机回复的事务对应的binlog文件名和位 点注册到semisync模块中，然后在向备机发送binlog的主函数里mysql_binlog_send()中，将这些事务对应的binlog event数据 包加上要求备机回复的标志，见函数ReplSemiSyncMaster::updateSyncHeader()。主机在mysqld启动时就启动了一个 ack_receiver线程，每次有新的备机连接上来，就把对应的服务线程注册到ack_receiver中，见函数 ReplSemiSyncMaster::dump_start()，ack_receiver负责接收所有备机的回复。备机在handle_slave_io()函数中读到一个 event的数据包就会检查是否有要求回复的标志，如果有则在将binlog刷到本地磁盘后向主机发送回复报文，回复的报文的内容 包含收到的binlog文件名和位点。流程大致如下：

  2.   // ...
  3.   event_len= read_event(mysql, mi, &suppress_warnings);
  4.   mi->repl_semisync_slave.slaveReadSyncHeader((const char*)mysql->net.read_pos + 1,
  5.                           event_len, &(mi->semi_ack), &event_buf,
  6.                           &event_len);
  7.   // ...
  9.     {
  10.       mi->report(ERROR_LEVEL, ER_SLAVE_RELAY_LOG_WRITE_FAILURE,
  11.          ER(ER_SLAVE_RELAY_LOG_WRITE_FAILURE),
  12.          "could not queue event from master");
  13.     }
  14.   // ...
  16.      mi->repl_semisync_slave.slaveReply(mi))
  17.     {
  18.       mi->report(ERROR_LEVEL, ER_SLAVE_FATAL_ERROR,
  19.          ER(ER_SLAVE_FATAL_ERROR),
  20.          "Failed to call 'slaveReply'");
  21.       goto err;
  22.     }

通过以上分析可以看出在同步复制的模式上，MySQL通过非常严格的流程保证了用户Session执行完事务返回给客户端后，该事 务也必然已同步到了备机的磁盘上。同时保证了出现在备机的事务必然在主机上已经是安全提交了的，也就是在任何时刻主机 上的事务一定是大于等于备机的。