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

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介:

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

最近发现一种情况,在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中的信息是否一致。当然,如果你使用了别的引擎,这些信息就没什么作用了。
关于该选项的文档:
相关链接:

 


相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
5天前
|
SQL 关系型数据库 MySQL
MySQL基础:事务
本文详细介绍了数据库事务的概念及操作,包括事务的定义、开启、提交与回滚。事务作为一组不可分割的操作集合,确保了数据的一致性和完整性。文章还探讨了事务的四大特性(原子性、一致性、隔离性、持久性),并分析了并发事务可能引发的问题及其解决方案,如脏读、不可重复读和幻读。最后,详细讲解了不同事务隔离级别的特点和应用场景。
37 4
MySQL基础:事务
|
19天前
|
SQL 关系型数据库 MySQL
说一下MySQL主从复制的原理?
【8月更文挑战第24天】说一下MySQL主从复制的原理?
45 0
|
9天前
|
SQL 安全 数据库
基于SQL Server事务日志的数据库恢复技术及实战代码详解
基于事务日志的数据库恢复技术是SQL Server中一个非常强大的功能,它能够帮助数据库管理员在数据丢失或损坏的情况下,有效地恢复数据。通过定期备份数据库和事务日志,并在需要时按照正确的步骤恢复,可以最大限度地减少数据丢失的风险。需要注意的是,恢复数据是一个需要谨慎操作的过程,建议在执行恢复操作之前,详细了解相关的操作步骤和注意事项,以确保数据的安全和完整。
20 0
|
12天前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
42 0
|
12天前
|
C# Windows 监控
WPF应用跨界成长秘籍:深度揭秘如何与Windows服务完美交互,扩展功能无界限!
【8月更文挑战第31天】WPF(Windows Presentation Foundation)是 .NET 框架下的图形界面技术,具有丰富的界面设计和灵活的客户端功能。在某些场景下,WPF 应用需与 Windows 服务交互以实现后台任务处理、系统监控等功能。本文探讨了两者交互的方法,并通过示例代码展示了如何扩展 WPF 应用的功能。首先介绍了 Windows 服务的基础知识,然后阐述了创建 Windows 服务、设计通信接口及 WPF 客户端调用服务的具体步骤。通过合理的交互设计,WPF 应用可获得更强的后台处理能力和系统级操作权限,提升应用的整体性能。
29 0
|
12天前
|
存储 关系型数据库 MySQL
MySQL 中的事务存储引擎深入解析
【8月更文挑战第31天】
11 0
|
19天前
|
存储 关系型数据库 MySQL
深入MySQL:事务日志redo log详解与实践
【8月更文挑战第24天】在MySQL的InnoDB存储引擎中,为确保事务的持久性和数据一致性,采用了redo log(重做日志)机制。redo log记录了所有数据修改,在系统崩溃后可通过它恢复未完成的事务。它由内存中的redo log buffer和磁盘上的redo log file组成。事务修改先写入buffer,再异步刷新至磁盘,最后提交事务。若系统崩溃,InnoDB通过redo log重放已提交事务并利用undo log回滚未提交事务,确保数据完整。理解redo log工作流程有助于优化数据库性能和确保数据安全。
75 0
|
21天前
|
SQL 关系型数据库 MySQL
【揭秘】MySQL binlog日志与GTID:如何让数据库备份恢复变得轻松简单?
【8月更文挑战第22天】MySQL的binlog日志记录数据变更,用于恢复、复制和点恢复;GTID为每笔事务分配唯一ID,简化复制和恢复流程。开启binlog和GTID后,可通过`mysqldump`进行逻辑备份,包含binlog位置信息,或用`xtrabackup`做物理备份。恢复时,使用`mysql`命令执行备份文件,或通过`innobackupex`恢复物理备份。GTID模式下的主从复制配置更简便。
94 2
|
16天前
|
弹性计算 关系型数据库 数据库
手把手带你从自建 MySQL 迁移到云数据库,一步就能脱胎换骨
阿里云瑶池数据库来开课啦!自建数据库迁移至云数据库 RDS原来只要一步操作就能搞定!点击阅读原文完成实验就可获得一本日历哦~
|
20天前
|
关系型数据库 MySQL 数据库
RDS MySQL灾备服务协同解决方案构建问题之数据库备份数据的云上云下迁移如何解决
RDS MySQL灾备服务协同解决方案构建问题之数据库备份数据的云上云下迁移如何解决