从一个线上问题分析binlog与内部XA事务提交过程

标签：moni   date   日志记录   tar   fsync   自身   需要   还需要   引擎   

4. int MYSQL_BIN_LOG::ordered_commit(THD *thd, bool all, bool skip_commit) {
5. .....
6. //进入flush stage，
7. change_stage(thd, Stage_manager::FLUSH_STAGE, thd, NULL, &LOCK_log);
8. ....
9. //通知底层存储引擎日志刷盘
10. process_flush_stage_queue(&total_bytes, &do_rotate, &wait_queue);
11. .....
12. //将各个线程的binlog从cache写到文件中
13. flush_cache_to_file(&flush_end_pos);
14. ....
15. //进入到Sync stage
16. change_stage(thd, Stage_manager::SYNC_STAGE, wait_queue, &LOCK_log,
17. &LOCK_sync));
18. //binlog fsync落盘
19. sync_binlog_file(false)
20. //通知binlog发送线程，有新的binlog落盘可以发送到订阅者了
21. update_binlog_end_pos(tmp_thd->get_trans_pos());
22. //进入commit state
23. change_stage(thd, Stage_manager::COMMIT_STAGE, final_queue,
24. leave_mutex_before_commit_stage, &LOCK_commit);
25. ....
26. //事务状态提交
27. process_commit_stage_queue(thd, commit_queue);
28. ....
    }

其中，在update_binlog_end_pos之后，binlog发送线程就已经可以读取最新的binlog发送给订阅者了。当订阅者收到这些binlog之后如果process_commit_stage_queue因为系统调度等原因还未执行完成，那么订阅者碰巧在此时发起问题中所描述的查询，就会发生查询不到的情况。
下面我们看一下process_commit_stage_queue都做了什么。
在process_commit_stage_queue会分别调用到binlog的commit方法binlog_commit和innodb的commit函数trx_commit_in_memory。

1. static int binlog_commit(handlerton , THD , bool) {
2. DBUG_ENTER("binlog_commit");
3. /*
4. Nothing to do (any more) on commit.
5. */
6. DBUG_RETURN(0);
7. }
   在binlog_commit中什么也不做，因为跟binlog有关的操作前面都已经做完了。
   最后看一下存储引擎innodb的trx_commit_in_memory都干了什么。
8. static void trx_commit_in_memory(
9. trx_t trx, /!< in/out: transaction */
10. const mtr_t mtr, /!< in: mini-transaction of
11. trx_write_serialisation_history(), or NULL if
12. the transaction did not modify anything */
13. bool serialised)
14. /*!< in: true if serialisation log was
15. written */
16. {
17. ....
18. //释放锁
19. lock_trx_release_locks(trx);
21. ut_ad(trx_state_eq(trx, TRX_STATE_COMMITTED_IN_MEMORY));
23. .....
24. //释放mvcc相关的read view
25. if (trx->read_only || trx->rsegs.m_redo.rseg == NULL) {
26. MONITOR_INC(MONITOR_TRX_RO_COMMIT);
27. if (trx->read_view != NULL) {
28. trx_sys->mvcc->view_close(trx->read_view, false);
29. }
31. } else {
32. ut_ad(trx->id > 0);
33. MONITOR_INC(MONITOR_TRX_RW_COMMIT);
34. }
35. }
36. ....
37. //清理insert操作相关的undo log(注意，此时只有insert的undo需要清理)
38. if (mtr != NULL) {
39. if (trx->rsegs.m_redo.insert_undo != NULL) {
40. trx_undo_insert_cleanup(&trx->rsegs.m_redo, false);
41. }
43. if (trx->rsegs.m_noredo.insert_undo != NULL) {
44. trx_undo_insert_cleanup(&trx->rsegs.m_noredo, true);
45. }
46. }

这一步完成之后，在运行时刻事务的变更才能被查询到。但需要记住，MySQL在binlog落盘成功后就认为事务的持久化已经完成。
30. 总结
在binlog落盘之后，MySQL就会认为事务的持久化已经完成(在这个时刻之后，就算数据库发生了崩溃都可以在重启后正确的恢复该事务)。但是该事务产生的数据变更被别的客户端查询出来还需要在commit全部完成之后。MySQL会在binlog落盘之后会立即将新增的binlog发送给订阅者以尽可能的降低主从延迟。但由于多线程时序等原因，当订阅者在收到该binlog之后立即发起一个查询操作，可能不会查询到任何该事务产生的数据变更(因为此时该事务所处线程可能尚未完成最后的commit步骤)。
如果应用需要根据binlog作为一些业务逻辑的触发点，还是需要考虑引入一些延时重试机制或者重新考虑合适的实现架构。

本文由京东商城数据库技术部王治提供。

从一个线上问题分析binlog与内部XA事务提交过程

标签：moni   date   日志记录   tar   fsync   自身   需要   还需要   引擎   

原文地址：http://blog.51cto.com/wangwei007/2323844