暂无图片
暂无图片
1
暂无图片
暂无图片
1
暂无图片

MySQL 8 复制延迟观测新方式,更全面更精准

玩转MySQL 2020-02-09
302


一直以来MySQL复制延迟观测是不完善的,既无法观测到真实的主从延迟,也无法支持复杂的复制拓扑环境,常用的second_behind_master指标更多是判断是否存在回放延迟,以及趋势变化。你无法直观的观测到事务精确的延迟情况,因为slave无法获知事务在master上的提交时间。


社区贡献的基于心跳表延迟检测方法,其流程是master上创建一张心跳表,心跳进程每秒更新表上的时间戳字段,slave同步后计算时间差。这应该是在不改动MySQL代码的最好方案了,虽然也会有些不足。


  • 心跳进程单点风险,心跳进程不可用则延迟检测失效。

  • 并不能反应真实的业务事务同步或回放延迟,体现的是主从复制链路全局的连通性和延迟。

  • 观测粒度只能达到秒级,精度不够。

  • 污染binlog,大量心跳事件占据binlog,更多空间占用,干扰排查和日志恢复。


MySQL 8 复制延迟观测的改进


WL#7319和WL#7374共同完善了复制延迟观测,WL#7319 Infrastructure for GTID based delayed replication and replication lag monitoring 在binlog的gtid_log_event (启用GTID)和anonymous_gtid_log_event(未启用GTID)新增事务提交时间戳。将事务原始提交时间写在binlog中,提交时间在复制链路上传递,使得slave可以计算事务延迟。

  • original_commit_timestamp 事务在master提交binlog的时间戳(微秒),该时间戳每个节点都是一样的。

  • immediate_commit_timestamp 事务在slave(包括中继节点)提交binlog的时间戳(微秒),该时间戳在relay log中与original_commit_timestamp一样,在slave的binlog是完成回放的时间戳。


WL#7374 Performance schema tables to monitor replication lags and queue 为performance_schema复制相关表新增观测点。

  • replication_connection_status 记录事件接收线程(IO Thread)工作状态

  • replication_applier_status_by_coordinator 记录启用并行回放的协调线程工作状态,

  • replication_applier_status_by_worker 记录事件回放线程(SQL Thread)工作状态


replication_connection_status


LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 已写入relay log事务ORIGINAL_COMMIT_TIMESTAMP时间戳


LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 写入relay log事务IMMEDIATE_COMMIT_TIMESTAMP时间戳


LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP 写入relay log的事务开始时间戳


LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP 写入relay log的事务结束时间戳


QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 正在写relay log的事务ORIGINAL_COMMIT_TIMESTAMP时间戳


QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 正在写relay log的事务IMMEDIATE_COMMIT_TIMESTAMP时间戳


QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP 正在写relay log的事务首个事件的时间戳


replication_applier_status_by_coordinator


LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 已调度事务的ORIGINAL_COMMIT_TIMESTAMP时间戳

LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 已调度事务的IMMEDIATE_COMMIT_TIMESTAMP时间戳

LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMP 已调度事务到worker 线程buffer的开始时间戳

LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP 已调度事务到worker 线程buffer的结束时间戳

PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 正在调度事务的ORIGINAL_COMMIT_TIMESTAMP时间戳

PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 正在调度事务的IMMEDIATE_COMMIT_TIMESTAMP时间戳

PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP 正在调度事务写入worker 线程buffer的开始时间戳


replication_applier_status_by_worker


LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 回放事务的ORIGINAL_COMMIT_TIMESTAMP时间戳


LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 回放事务的IMMEDIATE_COMMIT_TIMESTAMP时间戳


LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP 回放事务的开始时间戳


LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP 回放事务的结束时间戳


APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 正在回放事务的ORIGINAL_COMMIT_TIMESTAMP时间戳


APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 正在回放事务的IMMEDIATE_COMMIT_TIMESTAMP时间戳


APPLYING_TRANSACTION_START_APPLY_TIMESTAMP 正在回放事务的开始时间戳


如何观测事务复制过程中在不同位置的延迟,A是Master 节点,C 是中继Slave节点,D 是Slave节点。



位置1:事务从主节点A到从节点D回放完的延迟,最常用的查看事务完整的同步延迟

    SELECT LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP
    FROM performance_schema.replication_applier_status_by_worker
    复制


    事务从中继节点C到从节点D回放完的延迟,与上面类似,若没有中继节点效果和上面一样,也是事务完整的同步延迟

      SELECT LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP
      FROM performance_schema.replication_applier_status_by_worker
      复制


      位置2:当前已调度完的事务到开始回放的延迟

        SELECT APPLYING_TRANSACTION_START_APPLY_TIMESTAMP - APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP
        FROM performance_schema.replication_applier_status_by_worker
        复制


        位置3:已调度完的事务等待回放的延迟,MTS 开启

          SELECT LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP - LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP
          FROM performance_schema.replication_applier_status_by_coordinator
          复制


          位置4:当前已同步到中继日志的事务,等待开始调度的延迟,MTS 开启

            SELECT PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP - PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP
            FROM performance_schema.replication_applier_status_by_coordinator
            复制


            位置5:事务同步到从机中继日志的延迟

              SELECT LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP
              FROM performance_schema.replication_connection_status
              复制


              位置6:当前同步事务的网络传输延迟

                SELECT QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP - QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP
                FROM performance_schema.replication_connection_status
                复制


                MySQL 8 从根源上解决了过往版本缺少事务提交时间且无法传递的问题,PS视图暴露更多观测点简化了观测方式,帮助工程师更精准的诊断复制延迟问题。 

                文章转载自玩转MySQL,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

                评论

                bigdog1985
                暂无图片
                2年前
                评论
                暂无图片 0
                挺好
                2年前
                暂无图片 点赞
                评论