MySQL事务提交和崩溃恢复

MySQL事务提交和崩溃恢复

本文导读：MySQL事务提交和崩溃恢复的相关介绍，接下来IT袋网小编为大家介绍。

MySQL中的XA协议

有一个名叫X/Open的组织提出了一个名为XA的规范。这个XA规范提出了2个角色：

• 一个全局事务由多个小的事务组成，所以我们得在某个地方找一个总揽全局的角色用于和各个小事务进行沟通，指导它们是提交还是回滚。这个角色被称作事务协调器（Transaction Coordinator）。
• 管理一个小事务的角色被称作事务管理器（Transaction Manager）。

要提交一个全局事务，那么属于该全局事务的若干个小事务就应该全部提交，只要有任何一个小事务无法提交，那么整个全局事务就应该全部回滚。XA规范中指出，要提交一个全局事务，必须分为2步：

• Prepare阶段：当协调器准备提交一个全局事务时，会依次通知各个管理器把在事务执行过程中所产生的数据都刷盘。
• Commit阶段：如果在Prepare阶段各个管理器都完成了数据的刷盘，那么协调器就要真正通知各个管理器去提交事务了，否则就需要让这些管理器回滚事务了。

XA规范把上述全局事务提交时所经历的两个阶段称作两阶段提交。在单个MySQL实例中，将server层作为事务协调器，存储引擎作为事务管理器，故本文将binlog作为事务协调器。

sql执行流程

sql提交到MySQL时需要进行词法语法分析、优化（如果没有命中索引，就会扫全表），才会执行：

事务执行流程

假设我们要更新一条数据，语句如下：

update T set c=c+1 where ID=2;

1. Server层的执行器先调用引擎取出ID=2这一行。ID是主键，引擎直接用树搜索找到这一行。如果 ID=2这一行所在的数据页本来就在内存中，就直接返回给执行器；否则需要先从磁盘读入内存，然后再返回。
2. 执行器拿到数据把这个值+1（分配trx_id，开始记录事务），得到新的数据，再调用存储引擎接口写入这行新数据。此处会先记录undolog，并将undolog对应的变化信息redolog保存到log buffer中，然后再去修改buffer pool，并且把buffer pool对应的变化信息redolog记录到log buffer中，详情见上文。
3. InnoDB做完上述操作后，就准备提交事务了。此时处在Prepare阶段，执行器调用binlog_prepare接口，就会将上文提到的undo segment的状态置为TRX_UNDO_PREPARED，并将本次提交事务的XID也写入其中，同时生成对应的redolog。此时根据redolog的刷盘策略，本次事务对应的log buffer可能会被刷盘，而只要log buffer刷盘成功，那么即使之后系统崩溃，在重启恢复的时候也可以将处于Prepare状态的事务完全恢复（恢复buffer pool和undolog），然后回滚或者再次提交事务。
   12下一页