当前位置:首页 > 文章列表 > 数据库 > MySQL > 技术分享 | slave_relay_log_info 表认知的一些展开

技术分享 | slave_relay_log_info 表认知的一些展开

来源:SegmentFault 2023-01-28 09:06:35 0浏览 收藏

本篇文章向大家介绍《技术分享 | slave_relay_log_info 表认知的一些展开》,主要包括MySQL、数据库,具有一定的参考价值,需要的朋友可以参考一下。

作者:胡呈清

slave_relay_log_info 表是这样的:

mysql> select * from mysql.slave_relay_log_info\G

 *************************** 1. row ***************************
  Number_of_lines: 7
   Relay_log_name: ./mysql-relay.000015
    Relay_log_pos: 621
  Master_log_name: mysql-bin.000001
   Master_log_pos: 2407
        Sql_delay: 0
Number_of_workers: 16
               Id: 1
     Channel_name:
slave_relay_log_info 表存储 slave sql thread 的工作位置。

在从库启动的时候时,读取 slave_relay_log_info 表中存储的位置,并把值传给 "show slave status" 中的 Relay_Log_File、Relay_Log_Pos,下次 "start slave" 是从这个位置开始继续回放 relay log。
slave_relay_log_info 表存储的是持久化的状态、show slave status 输出的是内存中的状态:

  • 两者输出的位置可能不一样
  • stop slave 或者正常关闭 mysqld,都会将内存中的状态持久化到磁盘上(slave_relay_log_info表中)
  • 启动 mysqld 时会读取磁盘状态,初始化给内存状态
  • start slave 时生效的是内存状态

slave io thread 按照 Master_Log_File、Read_Master_Log_Pos 位置读取主库的 binlog,并写入到本地 relay log(注意这两个位点信息保存在 slave_master_info 表中);slave sql thread 按照 Relay_Log_Name、Relay_Log_Pos 位置进行 realy log 的回放。

但是同一个事务在从库 relay log 中的 position 和主库 binlog 中的 position 是不相等的,slave_relay_log_info 表通过 Master_log_name、Master_log_pos 这两个字段记录了 relay log 中事务对应在主库 binlog 中的 position。
我们得知道如果 slave io thread 重复、遗漏的读取主库 binlog 写入到 relay log 中,sql thread 也会重复、遗漏地回放这些 relay log。也就是说从库的数据是否正确,io thread 的位置是否正确也非常重要。
在 MySQL 5.6 以前,复制位点信息只能存储在数据目录的 master.info 文件中,在回放事务后更新到文件中(默认每次回放10000个事务更新,受参数 sync_relay_log_info 控制)。即使每个事务都更新文件,意外宕机时也没法保证持久性一致性。
MySQL 5.6 开始,可以设置 --relay-log-info-repository=TABLE,将 slave sql thread 的工作位置存储在 mysql.slave_relay_log_info 表中,如果这个表是 InnoDB 这样的支持事务的引擎,则从库每回放一个事务时都会在这个事务里同时更新 mysql.slave_relay_log_info 表,使得 sql thread 的位置与数据保持一致。事实上在 5.6.0-5.6.5 的版本,slave_relay_log_info 表默认使用的是 MyISAM 引擎,之后的版本才改为 InnoDB,不过再考虑到 MySQL 5.6.10 才 GA,这个坑踩过的人应该不多。

更新机制

引用手册:

sync_relay_log_info = 0
  If relay_log_info_repository is set to FILE, the MySQL server performs no synchronization of the relay-  log.info file to disk; instead, the server relies on the operating system to flush its contents periodically as with any other file.
  If relay_log_info_repository is set to TABLE, and the storage engine for that table is transactional, the table is updated after each transaction. (Thesync_relay_log_info setting is effectively ignored in this case.)
  If relay_log_info_repository is set to TABLE, and the storage engine for that table is not transactional, the table is never updated.

sync_relay_log_info = N > 0
  If relay_log_info_repository is set to FILE, the slave synchronizes its relay-log.info file to disk (using fdatasync()) after every N transactions.
  If relay_log_info_repository is set to TABLE, and the storage engine for that table is transactional, the table is updated after each transaction. (Thesync_relay_log_info setting is effectively ignored in this case.)
  If relay_log_info_repository is set to TABLE, and the storage engine for that table is not transactional, the table is updated after every N events.

一般的运维规范都会要求 relay_log_info_repository=TABLE,默认值 sync_relay_log_info=10000 此时会失效,变成每回放一个事务都会在这个事务里同时更新 mysql.slave_relay_log_info 表,保证持久性,以最终保证复制的数据一致。当然 InooDB 的持久性需要 innodb_flush_log_at_trx_commit=1 来保证。

前面有一句话“也就是说从库的数据是否正确,io thread 的位置是否正确也非常重要”。简单来说 io thread 位置保存在 slave_master_info 表中,其实设置和 relay_log_info_repository 类似,不同的是它的持久化保障通常与性能冲突很大:

  • 必须设置 master_info_repository = TABLE 和 sync_master_info=1,刷盘的单位是 binlog event 而不是事务,写放大很严重,性能损耗大

所以通常 sync_master_info 使用默认值 10000, io thread 的位置无法保证持久化,也就没法保证正确。MySQL 有另一个参数 relay_log_recovery 提供一种机制来保证 mysqld crash 后 io thread 位置的准确性,稍后进行介绍。

master_auto_position

master_auto_position 的作用是根据从库的 Executed_Gtid_Set 自动寻找主库上对应 binlog 位置,这是在 GTID 出现后的一个功能。

这里思考一个问题:开启 master_auto_position 后,slave io thread 能直接根据从库的 Executed_Gtid_Set 定位主库上 binlog 的位置吗?还需要 slave_relay_log_info、slave_master_info 表中记录的位点信息吗?

其实 slave_relay_log_info、slave_master_info 表依然发挥作用:

  • 当第一次或者 reset slave 后,执行 start slave,io thread 将从库的 Executed_Gtid_Set 发往主库,获取到对应的 File、Position,之后更新到从库的 slave_relay_log_info、slave_master_info 表中
  • 当 slave_relay_log_info、slave_master_info 表中存在位置信息后,此后无论是重启复制还是重启 mysqld,都是直接从这两个地方获取 File、Position,并从这里开始读取 binlog 和回放 relay log

注意:执行 "reset slave" 会删除从库上的 relay log,并且重置 slave_relay_log_info 表,即重置复制位置。如果 master_auto_position=0,下次启动复制时会从新开始获取并回放主库的 binlog,造成错误。

relay_log_recovery

当启用 relay_log_recovery,mysqld 启动时,recovery 过程会生成一个新的 relay log,并初始化 slave sql thread 的位置,表现为:

  • slave_relay_log_info 表的 Relay_Log_Name 值更新为最新的日志名, Relay_Log_Pos 值更新为一个固定值 4(应该是头部固定信息占 4个偏移量)
  • 内存状态即 show slave status 输出中的 Relay_Log_File、Relay_Log_Pos,也更新成上面一样的

并且 slave io thread 的位置也会初始化,表现为:

  • slave_master_info 表中的 Master_log_name、Master_log_pos 不会改变
  • 内存状态即 show slave status 输出中的 Master_Log_File、Read_Master_Log_Pos,会更新为 slave_relay_log_info 表中 Master_Log_Name、Master_Log_Pos

io thread 这个位置的初始化思路就是:既然以前记录的位置不确定是否准确,那就直接不要了。sql thread 回放到哪,我就从哪开始重新拿主库的 binlog,这样准没错。一个事务在 relay log 中的 position 对应到主库 binlog 的 position 是这样来确定的:

  • slave_relay_log_info 表中的 Relay_log_name 与 Master_log_name,Relay_Log_Pos 与 Master_Log_Pos 始终一一对应,代表同一个事务的位置。

所以,即使 sync_master_info 表的持久化无法保证,relay_log_recovery 也会将 io thread 重置到已经回放的那个位置。
relay_log_recovery 的另一个作用是防止 relay log 的损坏,因为默认 relay log 是不保证持久化的(也不推荐设置 sync_relay_log=1),当操作系统或者 mysqld crash 后,sql thread 可能会因为 relay log 的损坏、丢失导致错误。

一些结论

  • 当开启 GTID 和 master_auto_position,并设置 relay_log_recovery=1,即使 relay_log_info_repository 设置为 file,操作系统或者 mysqld crash 后,mysqld 下次重启启动复制都能保证数据与主库一致。即使 slave_relay_log_info 表中记录的位置不是最新的,sql thread 可能会重复回放一部分事务,但是从库已经存在这些事务的 GTID,这部分重复的事务会被跳过。
  • 当未开启 GTID 和 master_auto_position,必须要设置 relay_log_info_repository=table、relay_log_recovery=1,操作系统或者 mysqld crash 后,mysqld 下次重启启动复制才能保证数据与主库一致。

理论要掌握,实操不能落!以上关于《技术分享 | slave_relay_log_info 表认知的一些展开》的详细介绍,大家都掌握了吧!如果想要继续提升自己的能力,那么就来关注golang学习网公众号吧!

版本声明
本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
MySql使用总结MySql使用总结
上一篇
MySql使用总结
MySQL 8.0.18 GA 正式发布!
下一篇
MySQL 8.0.18 GA 正式发布!
查看更多
最新文章
查看更多
课程推荐
  • 前端进阶之JavaScript设计模式
    前端进阶之JavaScript设计模式
    设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
    542次学习
  • GO语言核心编程课程
    GO语言核心编程课程
    本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
    508次学习
  • 简单聊聊mysql8与网络通信
    简单聊聊mysql8与网络通信
    如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
    497次学习
  • JavaScript正则表达式基础与实战
    JavaScript正则表达式基础与实战
    在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
    487次学习
  • 从零制作响应式网站—Grid布局
    从零制作响应式网站—Grid布局
    本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
    484次学习
查看更多
AI推荐
  • 互联网信息服务算法备案系统:如何完成算法备案流程
    互联网信息服务算法备案系统
    了解互联网信息服务算法备案系统,掌握如何进行算法备案的详细步骤和要求,确保您的互联网服务合规运营。
    54次使用
  • SEO标题魔匠AI:高质量学术写作平台,毕业论文生成与优化专家
    魔匠AI
    SEO摘要魔匠AI专注于高质量AI学术写作,已稳定运行6年。提供无限改稿、选题优化、大纲生成、多语言支持、真实参考文献、数据图表生成、查重降重等全流程服务,确保论文质量与隐私安全。适用于专科、本科、硕士学生及研究者,满足多语言学术需求。
    99次使用
  • PPTFake答辩PPT生成器:一键生成高效专业的答辩PPT
    PPTFake答辩PPT生成器
    PPTFake答辩PPT生成器,专为答辩准备设计,极致高效生成PPT与自述稿。智能解析内容,提供多样模板,数据可视化,贴心配套服务,灵活自主编辑,降低制作门槛,适用于各类答辩场景。
    123次使用
  • SEO标题Lovart AI:全球首个设计领域AI智能体,实现全链路设计自动化
    Lovart
    SEO摘要探索Lovart AI,这款专注于设计领域的AI智能体,通过多模态模型集成和智能任务拆解,实现全链路设计自动化。无论是品牌全案设计、广告与视频制作,还是文创内容创作,Lovart AI都能满足您的需求,提升设计效率,降低成本。
    227次使用
  • 美图AI抠图:行业领先的智能图像处理技术,3秒出图,精准无误
    美图AI抠图
    美图AI抠图,依托CVPR 2024竞赛亚军技术,提供顶尖的图像处理解决方案。适用于证件照、商品、毛发等多场景,支持批量处理,3秒出图,零PS基础也能轻松操作,满足个人与商业需求。
    118次使用
微信登录更方便
  • 密码登录
  • 注册账号
登录即同意 用户协议隐私政策
返回登录
  • 重置密码