MySQL源码学习：ib_logfile、bin-log与主从同步

    今天研究MySQL主从同步的同事问了一个问题，如果InnoDB写完ib_logfile后，服务异常关闭。会不会由于主库能够根据ib_logfile恢复数据，而由于bin-log没写导致从库同步时少了这个事务？或者反之，bin-log写成功，而ib_logfile没有写完，导致从库执行事务，而主库不执行？ 这会导致主从不一致。

本文简要说明下这个问题。

 

1、              写入流程

源码sql/handler.cc:

ha_commit_trans {   …   if ((err= ht->prepare(ht, thd, all)))   …   tc_log->log_xid(thd, xid)   …   error=ha_commit_one_phase(thd, all) … }

说明：

实际上ib_logfile的两步写策略避免了上述的两个问题。流程大致如下：

a)        [ib_logfile] 写入当前事务的更新数据，并标志为事务准备(trx_prepare).

b)        写入bin-log。

c)        [ib_logfile] 当前事务提交结束(trx_commit)

 

2、              恢复流程

实际上，若ib_logfile已经写入trx_prepare，则在恢复过程中，会根据bin-log中该事务是否存在来恢复数据（见函数xarecover_handlerton）。

流程如下（sql/handler.cc）

xarecover_handlerton {   sql_print_information("Found %d prepared transaction(s) in %s",                             got, ha_resolve_storage_engine_name(hton));   foreach (trx)   { If (found in bin-log) {   sql_print_information("commit xid %s", xid_to_str(buf, info->list+i));   hton->commit_by_xid(hton, info->list+i); } Else { sql_print_information("rollback xid %s",xid_to_str(buf, info->list+i)); hton->rollback_by_xid(hton, info->list+i); } } }

说明：从启动日志中能够看到上述代码输出的日志。

☆    假设在阶段a)结束之后程序异常， 此时没有写入bin-log。 则从库不会同步这个事务。 主库上，在重启之后，从恢复日志中这个事务没有trx_commit，因此会被回滚。 逻辑上主从库都不会执行这个事务。

☆    假设在阶段b)结束后程序异常，此时bin-log已经写入，则从库会同步这个事务。 主库上，根据恢复日志和bin-log，也能够正常恢复此事务。

也就是说，若bin-log写入完成，则主从库都会正常完成事务；bin-log没有写入，则主从库都回滚事务。不会出现主从不一致的问题。

 

3、              操作系统崩溃造成的不一致

上述的流程并不是天衣无缝的。ib_logfile的写盘是能够被设置成非实时flush的。假设在bin-log写入完成后，系统崩溃，则可能出现这样的情况：bin-log写入所以从库能够执行事务。但主库中trx_prepare的日志没有被写入到ib_logifle中，导致主库不执行事务。这样就会出现主从不一致的情况。

解决方案：增加启动检测，将ib_logfile中不存在的事务，从bin-log删除掉。这样主从库都不执行此事务。