MySQL:show slave status 关键值和MGRrelay log的清理策略

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:

简单记录一下,有朋友问 @richard
一、show slave status关键值

1. row **

           Slave_IO_State: Waiting for master to send event (IO THREAD状态)
              Master_Host: 192.168.99.42(通道主库IP)
              Master_User: repl991(同步用户名)
              Master_Port: 3310(端口)
            Connect_Retry: 60(IO thread 重试时间)
          Master_Log_File: binlog.000002(读取到的binlog文件名)
      Read_Master_Log_Pos: 44688(读取到的binlog位置)
           Relay_Log_File: test-relay-bin.000003(本IO THREAD replay文件名)
            Relay_Log_Pos: 24360(当前写到relay log的位置)
    Relay_Master_Log_File: binlog.000002(SQL thread应用到的binlog的文件名)
         Slave_IO_Running: Yes (IO thread状态是否正常)
        Slave_SQL_Running: Yes (SQL THREAD状态是否正常)

...

               Last_Errno: 0 (错误号)
               Last_Error:   (错误信息)
             Skip_Counter: 0
      Exec_Master_Log_Pos: 44688 (SQL thread应用到的binlog的位置)
          Relay_Log_Space: 44599 (relay 日志文件总的的大小)

...

    Seconds_Behind_Master: 0 (延迟)

...

         Master_Server_Id: 9942 (主库的server_id)
              Master_UUID: 0e733bbb-a594-11e7-ab07-52540020afef (主库的UUID)
         Master_Info_File: /root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/mysqld.1/data/master.info (master info的文件或者表)
                SQL_Delay: 0(是否配置延时应用)

...

  Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates (sql thread状态)
       Master_Retry_Count: 86400 (可以重试的总次数)

...

       Retrieved_Gtid_Set: 0e733bbb-a594-11e7-ab07-52540020afef:9-129 (收到的GTID)
        Executed_Gtid_Set: 0e733bbb-a594-11e7-ab07-52540020afef:1-129 (应用的GTID)
            Auto_Position: 1 (是否通过GTID自动寻找binlog位置)

...

             Channel_Name: 通道名

...

二、MGR relaylog 清理策略

普通sql线程删除relay文件

#0  MYSQL_BIN_LOG::purge_logs (this=0x37ea570, to_log=0x7fff2400d1a0 "./test-relay-bin.000004", included=false, need_lock_index=false, need_update_threads=false, 
    decrease_log_space=0x37ec628, auto_purge=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:5950
#1  0x000000000185073f in MYSQL_BIN_LOG::purge_first_log (this=0x37ea570, rli=0x37e9b30, included=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:5818
#2  0x0000000001892224 in next_event (rli=0x37e9b30) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_slave.cc:9299
#3  0x0000000001886443 in exec_relay_log_event (thd=0x7fff24000950, rli=0x37e9b30) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_slave.cc:5145
#4  0x000000000188d092 in handle_slave_sql (arg=0x3790690) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_slave.cc:7387
#5  0x0000000001d7b4b0 in pfs_spawn_thread (arg=0x7fff3c01b5f0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/perfschema/pfs.cc:2188
#6  0x0000003f74807aa1 in start_thread () from /lib64/libpthread.so.0
#7  0x0000003f740e8bcd in clone () from /lib64/libc.so.6

MGR group_replication_applier通道的sql线程删除relay文件

#0  MYSQL_BIN_LOG::purge_logs (this=0x7fff9c0562f0, to_log=0x7fff800160b0 "./gp4-relay-bin-group_replication_applier.000006", included=false, need_lock_index=false, 
    need_update_threads=false, decrease_log_space=0x7fff9c058320, auto_purge=true) at /root/softm/percona-server-5.7.22-22/sql/binlog.cc:6391
#1  0x0000000001870333 in MYSQL_BIN_LOG::purge_first_log (this=0x7fff9c0562f0, rli=0x7fff9c0558a0, included=false)
    at /root/softm/percona-server-5.7.22-22/sql/binlog.cc:6259
#2  0x00000000018b6bcf in next_event (rli=0x7fff9c0558a0) at /root/softm/percona-server-5.7.22-22/sql/rpl_slave.cc:9480
#3  0x00000000018aa5a6 in exec_relay_log_event (thd=0x7fff80007e10, rli=0x7fff9c0558a0) at /root/softm/percona-server-5.7.22-22/sql/rpl_slave.cc:5193
#4  0x00000000018b1980 in handle_slave_sql (arg=0x7fff9c04e850) at /root/softm/percona-server-5.7.22-22/sql/rpl_slave.cc:7543
#5  0x0000000001932112 in pfs_spawn_thread (arg=0x7fff9803ff60) at /root/softm/percona-server-5.7.22-22/storage/perfschema/pfs.cc:2190
#6  0x00007ffff7bc6aa1 in start_thread () from /lib64/libpthread.so.0
#7  0x00007ffff6719bcd in clone () from /lib64/libc.so.6

可以看出没有什么区别。实际上都是一样的还是通过sql线程应用了event后删除。当然有如下代码 受到参数relay_log_purge控制

      if (relay_log_purge)
      {
        /*
          purge_first_log will properly set up relay log coordinates in rli.
          If the group's coordinates are equal to the event's coordinates
          (i.e. the relay log was not rotated in the middle of a group),
          we can purge this relay log too.
          We do ulonglong and string comparisons, this may be slow but
          - purging the last relay log is nice (it can save 1GB of disk), so we
          like to detect the case where we can do it, and given this,
          - I see no better detection method
          - purge_first_log is not called that often
        */
        if (rli->relay_log.purge_first_log
            (rli,
             rli->get_group_relay_log_pos() == rli->get_event_relay_log_pos()
             && !strcmp(rli->get_group_relay_log_name(),rli->get_event_relay_log_name())))
        {
          errmsg = "Error purging processed logs";
          goto err;
        }
        DBUG_PRINT("info", ("next_event group master %s %lu  group relay %s %lu event %s %lu\n",
          rli->get_group_master_log_name(),
          (ulong) rli->get_group_master_log_pos(),
          rli->get_group_relay_log_name(),
          (ulong) rli->get_group_relay_log_pos(),
          rli->get_event_relay_log_name(),
          (ulong) rli->get_event_relay_log_pos()));
      }
      else
  • flush logs等命令不会影响MGR的repay log包括recovery通道和applier通道

作者微信号码:gp_22389860

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
11天前
|
缓存 关系型数据库 MySQL
MySQL执行计划选择策略:揭秘查询优化的艺术
【10月更文挑战第15天】 在数据库性能优化中,选择最优的执行计划是提升查询效率的关键。MySQL作为一个强大的关系型数据库管理系统,提供了复杂的查询优化器来生成执行计划。本文将深入探讨如何选择合适的执行计划,以及为什么某些计划更优。
26 2
|
29天前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1607 14
|
7天前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第27天】本文深入探讨了MySQL的索引策略和查询性能调优技巧。通过介绍B-Tree索引、哈希索引和全文索引等不同类型,以及如何创建和维护索引,结合实战案例分析查询执行计划,帮助读者掌握提升查询性能的方法。定期优化索引和调整查询语句是提高数据库性能的关键。
39 0
|
8天前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第26天】数据库作为现代应用系统的核心组件,其性能优化至关重要。本文主要探讨MySQL的索引策略与查询性能调优。通过合理创建索引(如B-Tree、复合索引)和优化查询语句(如使用EXPLAIN、优化分页查询),可以显著提升数据库的响应速度和稳定性。实践中还需定期审查慢查询日志,持续优化性能。
34 0
|
1月前
|
SQL 存储 关系型数据库
Mysql主从同步 清理二进制日志的技巧
Mysql主从同步 清理二进制日志的技巧
24 1
|
1月前
|
关系型数据库 MySQL 数据库
DZ社区 mysql日志清理 Discuz! X3.5数据库可以做定期常规清理的表
很多站长在网站日常维护中忽略了比较重要的一个环节,就是对于数据库的清理工作,造成数据库使用量增加必须多的原因一般有2个:后台站点功能开启了家园,此功能现在很少有论坛会用到,但是灌水机会灌入大量垃圾信息致使站长长时间未能发觉;再有就是程序默认的一些通知类表单会存放大量的、对于网站日常运行并无意义的通知信息。
53 2
|
17天前
|
存储 关系型数据库 MySQL
MySQL中的Redo Log、Undo Log和Binlog:深入解析
【10月更文挑战第21天】在数据库管理系统中,日志是保障数据一致性和完整性的关键机制。MySQL作为一种广泛使用的关系型数据库管理系统,提供了多种日志类型来满足不同的需求。本文将详细介绍MySQL中的Redo Log、Undo Log和Binlog,从背景、业务场景、功能、底层实现原理、使用措施等方面进行详细分析,并通过Java代码示例展示如何与这些日志进行交互。
25 0
|
2月前
|
存储 关系型数据库 MySQL
MySQL索引失效及避免策略:优化查询性能的关键
MySQL索引失效及避免策略:优化查询性能的关键
261 3
|
2月前
|
SQL 关系型数据库 MySQL
MySQL中外键的使用及外键约束策略
这篇文章讨论了MySQL中使用外键的重要性,包括外键的概念、不使用外键可能导致的问题、如何设置外键约束以及不同的外键约束策略(如CASCADE和SET NULL),并通过示例演示了这些概念。
MySQL中外键的使用及外键约束策略
|
2月前
|
关系型数据库 MySQL 数据处理
针对MySQL亿级数据的高效插入策略与性能优化技巧
在处理MySQL亿级数据的高效插入和性能优化时,以上提到的策略和技巧可以显著提升数据处理速度,减少系统负担,并保持数据的稳定性和一致性。正确实施这些策略需要深入理解MySQL的工作原理和业务需求,以便做出最适合的配置调整。
296 6