MySQL事务提交过程(二) - 三石雨 - 博客园

标签: | 发表时间:2019-08-02 14:41 | 作者:
出处:https://www.cnblogs.com

上一篇文章我们介绍了在关闭binlog的情况下,事务提交的大概流程。之所以关闭binlog,是因为开启binlog后事务提交流程会变成两阶段提交,这里的两阶段提交并不涉及分布式事务,当然mysql把它称之为内部xa事务(Distributed Transactions),与之对应的还有一个外部xa事务。

这里所谓的两阶段提交分别是prepare阶段和commit阶段。

内部xa事务主要是mysql内部为了保证binlog与redo log之间数据的一致性而存在的,这也是由其架构决定的(binlog在mysql层,而redo log 在存储引擎层);

外部xa事务则是指支持多实例分布式事务,这个才算是真正的分布式事务。

既然是xa事务,必然涉及到两阶段提交,对于内部xa而言,同样存在着提交的两个阶段。

下文会结合源码详细解读内部xa的两阶段提交过程,以及各种情况下,mysqld crash后,mysql如何恢复来保证事务的一致性。

   

测试环境

OS:WIN7

ENGINE:

DB:

   

配置文件参数:

log-bin=D:\mysql\log\5-6-21\mysql-bin

binlog_format=ROW

set autocommit=0;

innodb_support_xa=1sync_binlog=1;

innodb_flush_log_at_trx_commit=1;

【innodb_flush_log_at_trx_commit=1,sync_binlog=1

不同的模式区别在于,写文件调用write和落盘fsync调用的频率不同,所导致的后果是mysqld 或 os crash后,不严格的设置可能会丢失事务的更新。

双一模式是最严格的模式,这种设置情况下,单机在任何情况下不会丢失事务更新。】

   

测试条件

set autocommit=0;
-- ----------------------------

-- Table structurefor`user`-- ----------------------------DROP TABLE IF EXISTS `user`;

CREATE TABLE `user` (

`id`int(20) NOT NULL,

`account` varchar(20) NOT NULL,

`name` varchar(20) NOT NULL,

PRIMARY KEY (`id`),

KEY `id` (`id`) USING BTREE,

KEY `name` (`name`) USING BTREE

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

   

测试语句

insert into user values(1, 'sanzhang', '张三');
commit;

   

prepare阶段:

   1.设置undo state=TRX_UNDO_PREPARED;//trx_undo_set_state_at_prepare调用

   2.刷事务更新产生的redo日志;【步骤1产生的redo日志也会刷入】

MYSQL_BIN_LOG::prepare

ha_prepare_low

    {

engine:

binlog_prepare

innobase_xa_prepare

mysql:

trx_prepare_for_mysql

{1.trx_undo_set_state_at_prepare//设置undo段的标记为TRX_UNDO_PREPARED2.设置事务状态为TRX_STATE_PREPARED3.trx_flush_log_if_needed//将产生的redolog刷入磁盘}

     }

     

commit阶段:

   1.将事务产生的binlog写入文件,刷入磁盘;

   2.设置undo页的状态,置为TRX_UNDO_TO_FREE或TRX_UNDO_TO_PURGE; // trx_undo_set_state_at_finish调用

   3.记录事务对应的binlog偏移,写入系统表空间; //trx_sys_update_mysql_binlog_offset调用

MYSQL_BIN_LOG::commit

    ordered_commit

   {1.FLUSH_STAGE

        flush_cache_to_file//刷binlog2.SYNC_STAGE

        sync_binlog_file//Call fsync() to sync the file to disk.3.COMMIT_STAGE

        ha_commit_low

        {

            binlog_commit

            innobase_commit   

                trx_commit(trx) 

                {

                    trx_write_serialisation_history(trx, mtr);//更新binlog位点,设置undo状态trx_commit_in_memory(trx, lsn);//释放锁资源,清理保存点列表,清理回滚段}        

        } 

    }

   

在任何情况下(机器掉电)mysqld crash或者os crash,MySQL仍然能保证数据库的一致性。数据的一致性是如何做到的哪?正是二阶段提交。

我们结合几种场景来分析下二阶段提交是如何做到的:

1.prepare阶段,redo log落盘前,mysqld crash

2.prepare阶段,redo log落盘后,binlog落盘前,mysqld crash

3.commit阶段,binlog落盘后,mysqld crash

对于第一种情况,由于redo没有落盘,毫无疑问,事务的更新肯定没有写入磁盘,数据库的一致性受影响;

对于第二种情况,这时候redo log写入完成,但binlog还未写入,事务处于TRX_STATE_PREPARED状态,这是提交还是回滚呢?

对于第三种情况,此时,redo log和binlog都已经落盘,只是undo状态没有更新,虽然redo log和binlog已经一致了,事务是否应该提交?

   

我们结合mysqld异常重启后的执行逻辑以及关键的源代码。

对于第三种情况,我们可以搜集到未提交事务的binlog event,所以需要提交;

对于第二种情况,由于binlog未写入,需要通过执行回滚操作来保证数据库的一致性。

   

异常重启后,如何判断事务该提交还是回滚

1.读binlog日志,获取崩溃时没有提交的event;  //info->commit_list中含有该元素

2.若存在,则对应的事务要提交;否则需要回滚。

   

判断事务提交或回滚源码如下:

   

上面讨论了两阶段提交的基本流程,以及服务器异常crash后,mysql如何重启恢复保证binlog和数据的一致性。

简而言之,对于异常的xa事务,若binlog已落盘,则事务应该提交;binlog未落盘,则事务就应该回滚。

   

//异常重启后,回滚流程

innobase_rollback_by_xid

rollback_by_xid

trx_rollback_resurrected

    trx_rollback_active

        row_undo

        {//从回滚页获取undo记录//分析undo记录类型if(insert)

                row_undo_inselserow_undo_mod

        }

 

   

//异常重启后,提交流程

commit_by_xid

trx_commit_for_mysql

   

//写binlog接口

handler.cc:binlog_log_row

sql/binlog.cc:commit

mysys/my_sync:my_sync

sql/binlog.cc:sync_binlog_file

handler/ha_innodb.cc:innobase_xa_prepare

   

binlog日志文件是为了解决MySQL主从复制功能而引入的一份新日志文件,它包含了引发数据变更的事件日志集合。

从库请求主库发送 binlog 并通过日志事件还原数据写入从库,所以从库的数据来源为 binlog。

这样 MySQL 主库只需做到 binlog 与本地数据一致就可以保证主从库数据一致(暂且忽略网络传输引发的主从不一致)。

   

参考

   1、《高性能MySQL》

   2、 mysql 事务提交过程

相关 [mysql 博客] 推荐:

Python3连接MySQL数据库之mysql-client - Ethan_zhang - 博客园

- -
要想使 python 可以操作 mysql 就需要 MySQLdb 驱动,它是 python 操作 mysql 必不可少的模块. 在此站点下载mysqlclient安装包:https://www.lfd.uci.edu/~gohlke/pythonlibs/# 进行本地安装. 以下是从这个网站上面检索到的mysqlclient的所有版本.

在Debian下搭建基于Apache-Php-MySQL的wordpress博客

- - CSDN博客互联网推荐文章
wordpress是一个流行的博客搭建框架,为不会html,css和js的人提供了搭建博客的便捷方式.我这里是在我的笔记本上搭建了一个wordpress博客,这里把详细的搭建过程写出来.. 具体的操作过程如下描述.. 1.安装apache2服务器. 其中apache2-doc是apache服务器的说明和配置文件,libapache2-mod-php5是apache的php模块库文件..

MySQL双主(主主)架构方案 - ygqygq2 - 博客园

- -
在企业中,数据库高可用一直是企业的重中之重,中小企业很多都是使用mysql主从方案,一主多从,读写分离等,但是单主存在单点故障,从库切换成主库需要作改动. 因此,如果是双主或者多主,就会增加mysql入口,增加高可用. 不过多主需要考虑自增长ID问题,这个需要特别设置配置文件,比如双主,可以使用奇偶,总之,主之间设置自增长ID相互不冲突就能完美解决自增长ID冲突问题.

MySQL事务提交过程(一) - 三石雨 - 博客园

- -
MySQL作为一种关系型数据库,已被广泛应用到互联网中的诸多项目中. 今天我们来讨论下事务的提交过程.                                                        MySQL体系结构. 由于mysql插件式存储架构,导致开启binlog后,事务提交实质是二阶段提交,通过两阶段提交,来保证存储引擎和二进制日志的一致.

MySQL事务提交过程(二) - 三石雨 - 博客园

- -
上一篇文章我们介绍了在关闭binlog的情况下,事务提交的大概流程. 之所以关闭binlog,是因为开启binlog后事务提交流程会变成两阶段提交,这里的两阶段提交并不涉及分布式事务,当然mysql把它称之为内部xa事务(Distributed Transactions),与之对应的还有一个外部xa事务.

Mysql和Redis数据同步策略 - 元思 - 博客园

- -
不更新缓存是防止并发更新导致的数据不一致. 所以为了降低数据不一致的概率,不应该更新缓存,而是直接将其删除,. 然后等待下次发生cache miss时再把数据库中的数据同步到缓存. 如果先删除缓存,有一个明显的逻辑错误:考虑两个并发操作,线程A删除缓存后,线程B读该数据时会发生Cache Miss,然后从数据库中读出该数据并同步到缓存中,此时线程A更新了数据库.

MySQL 数据库双向同步复制 - mindwind - 博客园

- -
MySQL 复制问题的最后一篇,关于双向同步复制架构设计的一些设计要点与制约. 数据库的双主双写并双向同步场景,主要考虑数据完整性、一致性和避免冲突. 对于同一个库,同一张表,同一个记录中的同一字段的两地变更,会引发数据一致性判断冲突,尽可能通过业务场景设计规避. 双主双写并同步复制可能引发主键冲突,需避免使用数据库自增类主键方案.

mysql主从同步设置的重要参数log_slave_updates_ITPUB博客

- -
说明:最近部署了mysql的集群环境,详细如下M01和M02为主主复制,M01和R01为主从复制;在测试的过程中发现了以下问题:. 1、M01和M02的主主复制是没有问题的(从M01写入数据能同步到M02,从M02写入数据能够同步到M01);. 2、主从同步的时候,当从M01写入的时候,数据可以写入到R01;.

mysql历史数据自动归档_sdmei-CSDN博客_mysql 归档

- -
数据库跑一段时间后,因为查询性能、磁盘容量,运维管理等方面的原因,需要将在线数据挪到历史库(不同的服务器). 如我们的在线订单只留3个月数据,3个月以前的就需要到历史库查了. 自动归档常见的方式有pt-archiver,但我还是觉得自己写存储过程更靠谱. 在线库实例打开federated支持,创建数据库dborder(业务库), linkhis(归档用);.

关于删除MySQL Logs的一点记录 - 刘浩de技术博客

- - 博客园_首页
五一前,一个DBA同事反馈,在日常环境中删除一个大的slow log文件(假设文件大小10G以上吧),然后在MySQL中执行flush slow logs,会发现mysqld hang住. 今天尝试着重现了此问题,这里简要分析下原因. 构造slow log (将long_query_time设成了0);.