zoukankan      html  css  js  c++  java
  • MySQL 事务提交过程

    开发老大要求通过binlog查询一条被修改的数据,数据被查出后问我,有没有可能binlog中不会记录,回答不会,因为数据被修改,若失败直接回滚,不会在binlog中记录,此刻一个朋友用了洪荒之力告诉我,失败的话也会记录,坐地无语,因为他sqlserver dba,用sqlserver的思维考虑mysql,哈哈哈哈哈,用实验让他闭嘴!

    简单测试步骤如下:
    root(yoon)> flush logs;
    Query OK, 0 rows affected (0.01 sec)

    root((none))> show binlog events in 'mysql-bin.000041';  
    +------------------+-----+-------------+-----------+-------------+---------------------------------------+
    | Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                  |
    +------------------+-----+-------------+-----------+-------------+---------------------------------------+
    | mysql-bin.000041 |   4 | Format_desc |    232242 |         120 | Server ver: 5.6.26-log, Binlog ver: 4 |
    +------------------+-----+-------------+-----------+-------------+---------------------------------------+


    root(yoon)> begin;
    Query OK, 0 rows affected (0.00 sec)


    root(yoon)> update yoon set id=7 where id=1;
    Query OK, 1 row affected (0.02 sec)
    Rows matched: 1  Changed: 1  Warnings: 0


    在没有commit情况下,二进制日志的位置偏移量未发生变化:
    root(yoon)> show binlog events in 'mysql-bin.000041';
    +------------------+-----+-------------+-----------+-------------+---------------------------------------+
    | Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                  |
    +------------------+-----+-------------+-----------+-------------+---------------------------------------+
    | mysql-bin.000041 |   4 | Format_desc |    232242 |         120 | Server ver: 5.6.26-log, Binlog ver: 4 |
    +------------------+-----+-------------+-----------+-------------+---------------------------------------+




    root(yoon)> commit;
    Query OK, 0 rows affected (1.01 sec)

    提交后再次查看日志偏移量,发生变化,并记录在binlog中
    root(yoon)> show binlog events in 'mysql-bin.000041';
    +------------------+-----+-------------+-----------+-------------+---------------------------------------------+
    | Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                        |
    +------------------+-----+-------------+-----------+-------------+---------------------------------------------+
    | mysql-bin.000041 |   4 | Format_desc |    232242 |         120 | Server ver: 5.6.16-log, Binlog ver: 4       |
    | mysql-bin.000041 | 120 | Query       |    232242 |         199 | BEGIN                                       |
    | mysql-bin.000041 | 199 | Query       |    232242 |         304 | use `yoon`; update yoon set id=7 where id=1 |
    | mysql-bin.000041 | 304 | Xid         |    232242 |         335 | COMMIT /* xid=18 */                         |
    +------------------+-----+-------------+-----------+-------------+---------------------------------------------+



    MySQL事务提交过程
    开启binlog后事务提交流程会变成两阶段提交,这里的两阶段提交并不涉及分布式事务,当然mysql把它称之为内部xa事务(Distributed Transactions),与之对应的还有一个外部xa事务。


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


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


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


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


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




    数据库版本:5.6.16


    操作系统版本:CentOS 6.5


    配置文件参数:
    log-bin=/my/log/mysql-bin


    binlog_format=ROW


    set autocommit=0


    innodb_support_xa=1


    sync_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;


    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_PREPARED


                    2.设置事务状态为TRX_STATE_PREPARED


                    3.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  //  刷binlog


    2.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_ins else row_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 与本地数据一致就可以保证主从库数据一致(暂且忽略网络传输引发的主从不一致)。



      参考:http://www.cnblogs.com/exceptioneye/p/5451976.html

  • 相关阅读:
    Jenkins与Hudson的关系
    Jenkins企业版与CloudBees
    NSLookup命令
    XCopy提示“访问遭到拒绝”问题解决
    npm配置文件
    npm下载包时代理配置
    Jenkins实现测试环境到生产环境一键部署(Windows)
    可能是迄今为止最好的GitHub代码浏览插件--赞
    Ali OSS服务端签名直传并设置上传回调
    导入https证书
  • 原文地址:https://www.cnblogs.com/hankyoon/p/5779405.html
Copyright © 2011-2022 走看看