[MySQL源码] 在复制线程事务提交与更新relay-log.info之间crash导致的复制不一致

简介:

——————————————-

最近发现一种情况,在xid event和flush_relay_log_info中间crash,可能会导致数据不一致。

即事务提交了,但relay-log.info文件还没更新,这会造成重启crash recovery后事务被重复执行一次。
幸好,在innodb层记录了这些信息。并且Percona也提供了一个选项来利用这些信息。
1.相关全局变量
在trx/trx0sys.c文件中定义了如下变量
最后一个commit的事务的slave信息:
trx_sys_mysql_master_log_name
trx_sys_mysql_master_log_pos
trx_sys_mysql_relay_log_name
trx_sys_mysql_relay_log_pos
最后一个commit的binlog信息:
trx_sys_mysql_bin_log_name
trx_sys_mysql_bin_log_pos
2.写入信息
那么在什么时候会记录这些信息呢?
在函数mysql_bin_log_commit_pos中,确定写入innodb的binlog位置,backtrace如下
#0  mysql_bin_log_commit_pos
#1  0x00000000007c88d4 in innobase_commit_ordered_low
#2  0x00000000007cca97 in innobase_commit_ordered
#3  0x000000000071efc5 in run_commit_ordered
#4  MYSQL_BIN_LOG::trx_group_commit_leader
#5  0x000000000071f49d in MYSQL_BIN_LOG::write_transaction_to_binlog_events
#6  0x000000000071f681 in MYSQL_BIN_LOG::write_transaction_to_binlog
#7  0x000000000071ff6b in binlog_flush_cache
#8  binlog_commit_flush_trx_cache
#9  MYSQL_BIN_LOG::log_and_order
#10 0x000000000068a112 in ha_commit_trans
#11 0x000000000062f2fd in trans_commit_stmt
#12 0x000000000057c6bc in mysql_execute_command
在函数innobase_commit_ordered_low中先调用mysql_bin_log_commit_pos确定位置
再调用innobase_commit_low,如果是slave线程,直接访问active_mi->rli,将当前执行完的relay log坐标及对应binlog坐标拷贝到trx的成员变量中。然后调用trx_commit_for_mysql->trx_commit_off_kernel
当有对数据做更改时,及insert_undo和update_undo不为空时,调用trx_write_serialisation_history
这里会先更新undo,然后调用trx_sys_update_mysql_binlog_offset来更新ibdata中的relaylog/binlog里的坐标信息。这些都是在一个mtr中提交。
3.
重启后,会在完成crash recovery后,打印相关信息。
innobase_init
   –>innobase_start_or_create_for_mysql
         –>recv_recovery_from_checkpoint_finish
             –>trx_sys_print_mysql_master_log_pos 打印relay log信息,并将其拷贝到上述变量中
             –>trx_sys_print_mysql_binlog_offset  打印binlog信息
然后如果变量将相关信息记录到以上几个变量中。
在回到innobase_init函数后,会根据innobase_overwrite_relay_log_info来重写relay-log.info文件。
2977     if(innobase_overwrite_relay_log_info) {
……
直接重写relay-log.info文件
}
innobase_overwrite_relay_log_info 对应的MySQL选项是innodb_recovery_update_relay_log。
我们只要开启该参数,就会进入这部分代码逻辑。
因此,最好开启skip-slave-start,并需要关注err log中打印出来的信息与relay-log.info中的信息是否一致。当然,如果你使用了别的引擎,这些信息就没什么作用了。
关于该选项的文档:
相关链接:

 


相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
存储 SQL 关系型数据库
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
|
SQL 关系型数据库 MySQL
MySQL锁机制:并发控制与事务隔离
本文深入解析了MySQL的锁机制与事务隔离级别,涵盖锁类型、兼容性、死锁处理及性能优化策略,助你掌握高并发场景下的数据库并发控制核心技巧。
|
存储 监控 Oracle
MySQL事务
MySQL事务具有ACID特性,包括原子性、一致性、隔离性和持久性。其默认隔离级别为可重复读,通过MVCC和间隙锁解决幻读问题,确保事务间数据的一致性和并发性。
MySQL事务
|
SQL 运维 关系型数据库
深入探讨MySQL的二进制日志(binlog)选项
总结而言,对MySQL binlogs深度理解并妥善配置对数据库运维管理至关重要;它不仅关系到系统性能优化也是实现高可靠性架构设计必须考虑因素之一。通过精心规划与周密部署可以使得该机能充分发挥作用而避免潜在风险带来影响。
421 6
|
关系型数据库 MySQL 数据库
【赵渝强老师】MySQL的事务隔离级别
数据库并发访问时易引发数据不一致问题。如客户端读取到未提交的事务数据,可能导致“脏读”。MySQL通过四种事务隔离级别(读未提交、读已提交、可重复读、可序列化)控制并发行为,默认为“可重复读”,以平衡性能与数据一致性。
592 0
|
关系型数据库 MySQL 数据库
MySql事务以及事务的四大特性
事务是数据库操作的基本单元,具有ACID四大特性:原子性、一致性、隔离性、持久性。它确保数据的正确性与完整性。并发事务可能引发脏读、不可重复读、幻读等问题,数据库通过不同隔离级别(如读未提交、读已提交、可重复读、串行化)加以解决。MySQL默认使用可重复读级别。高隔离级别虽能更好处理并发问题,但会降低性能。
431 0
|
安全 关系型数据库 MySQL
mysql事务隔离级别
事务隔离级别用于解决脏读、不可重复读和幻读问题。不同级别在安全与性能间权衡,如SERIALIZABLE最安全但性能差,READ_UNCOMMITTED性能高但易导致数据不一致。了解各级别特性有助于合理选择以平衡并发性与数据一致性需求。
405 1
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
720 158
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格:MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB,多种引擎优惠上线!MySQL倚天版88元/年,SQL Server 2核4G仅299元/年,PostgreSQL 227元/年起。高可用、可弹性伸缩,安全稳定。详情见官网活动页。
1909 152

推荐镜像

更多