Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > MySQL主从延迟根因诊断法

MySQL主从延迟根因诊断法全面详解

作者:独隅

在高并发场景下,MySQL主从延迟(Replication Lag)是导致数据不一致、业务受损的定时炸弹,本文系统性地介绍了MySQL主从延迟问题的诊断与解决方案,需要的朋友可以参考下

摘要

本文系统性地介绍了MySQL主从延迟问题的诊断与解决方案。首先分析了主从复制的五个关键环节(主库写入、Binlog生产、网络传输、Relay Log写入、SQL重放),指出延迟可能发生在任一环节。文章提出了"先量化→再定位→后优化"的黄金法则,并详细阐述了三个核心诊断步骤:通过SHOW SLAVE STATUS等命令量化真实延迟、采用三层定位法快速锁定瓶颈环节、以及针对网络层、IO线程层和SQL线程层的具体排查方法。针对不同层级的瓶颈,文章提供了包括binlog压缩、TCP参数优化、磁盘IO调整、慢SQL分析等在内的多种优化方案,帮助开发者建立完整的延迟治理体系。

前言:主从延迟——数据库的"时空裂缝"

在高并发场景下,MySQL主从延迟(Replication Lag)是导致数据不一致、业务受损的"定时炸弹"。凌晨三点,监控告警炸了——主库QPS冲到两万八,从库延迟曲线像坐了火箭,业务侧已经出现数据不一致的客诉…

延迟的本质:主库写入速度 > 从库同步+回放速度

本文将带你彻底攻克这个困扰无数开发者的难题,从底层原理到实战应用,建立一套完整的诊断与治理体系。

一、核心诊断思路:瓶颈逐层排查

1.1 复制流程剖析(五环节链条)

主库写入 → Binlog生产 → 网络传输 → Relay Log写入 → SQL重放
    ↓         ↓           ↓           ↓           ↓
  应用层    主库IO     网络层     从库IO     从库SQL

延迟可能发生在任一环节

1.2 诊断黄金法则

先量化 → 再定位 → 后优化
  ↓        ↓       ↓
真实延迟  瓶颈层次  针对性方案

二、系统化诊断步骤与排查要点

2.1 第一步:量化延迟(别被假数据骗了)

2.1.1 核心指标查看

-- 基础延迟查看
SHOW SLAVE STATUS\G

-- 关键字段解读
Seconds_Behind_Master: 0              -- 从库落后主库秒数(可能不准确)
Relay_Master_Log_File: mysql-bin.001  -- 当前正在重放的主库binlog文件
Exec_Master_Log_Pos: 1234567          -- 已执行到的位置
Read_Master_Log_Pos: 1234567          -- 已读取到的位置

-- 计算真实延迟(推荐)
SELECT 
    TIMESTAMPDIFF(SECOND, 
        FROM_UNIXTIME(@@global.sql_slave_skip_counter), 
        NOW()
    ) AS real_delay_seconds;

2.1.2 真实延迟计算方法

-- 方法1:基于binlog位置计算
SELECT 
    (Master_Log_File_Position - Exec_Master_Log_Pos) / 
    (主库binlog生成速度) AS estimated_delay_seconds;

-- 方法2:基于心跳表(最准确)
-- 主库定期插入时间戳
INSERT INTO heartbeat_table (ts) VALUES (NOW());

-- 从库查询延迟
SELECT TIMESTAMPDIFF(SECOND, ts, NOW()) AS real_delay 
FROM heartbeat_table ORDER BY id DESC LIMIT 1;

2.1.3 延迟分级标准

延迟范围等级影响处理优先级
< 1秒正常无影响无需处理
1-10秒警告轻微影响观察
10-60秒严重业务影响立即处理
> 60秒危急数据不一致紧急处理

2.2 第二步:三层定位法(快速锁定瓶颈)

2.2.1 定位流程图

延迟高?
   ↓
IO线程延迟? ←─ Relay_Log_Space_Increase 快?
   ↓ 是              ↓ 是
网络/主库问题       从库IO问题
   ↓ 否              ↓ 否
SQL线程延迟? ←─ Seconds_Behind_Master 增长?
   ↓ 是
SQL执行问题
   ↓ 否
其他问题

2.2.2 判断IO线程还是SQL线程延迟

-- 查看线程状态
SHOW SLAVE STATUS\G

-- 关键判断:
-- 1. IO线程延迟特征
Relay_Master_Log_File != Master_Log_File  -- 读取落后
Read_Master_Log_Pos - Exec_Master_Log_Pos 很大  -- 堆积多

-- 2. SQL线程延迟特征
Relay_Master_Log_File = Master_Log_File  -- 读取跟上
但 Seconds_Behind_Master 很大  -- 执行慢

2.3 第三步:网络层诊断(数据传输的"生命线")

2.3.1 网络延迟检测

# 1. 基础ping测试
ping -c 10 主库IP
# 正常:< 1ms(同机房),< 10ms(同城)
# 2. 带宽测试
iperf3 -c 主库IP -t 30
# 正常:> 100Mbps
# 3. 丢包率测试
ping -c 100 主库IP | grep packet
# 正常:丢包率 < 0.1%
# 4. TCP连接质量
netstat -s | grep retrans
# 正常:重传率 < 0.01%

2.3.2 网络瓶颈特征

现象可能原因解决方案
ping延迟高跨机房/跨地域同城部署、专线优化
带宽不足主库QPS过高升级带宽、压缩binlog
丢包率高网络设备故障联系网络团队排查
TCP重传多网络拥塞调整TCP参数

2.3.3 网络优化方案

# 1. 启用binlog压缩(MySQL 8.0+)
SET GLOBAL binlog_transaction_compression = ON;
SET GLOBAL binlog_transaction_compression_level_zstd = 3;

# 2. 调整TCP参数
echo "net.ipv4.tcp_window_scaling = 1" >> /etc/sysctl.conf
echo "net.core.rmem_max = 16777216" >> /etc/sysctl.conf
echo "net.core.wmem_max = 16777216" >> /etc/sysctl.conf
sysctl -p

# 3. 使用专线/内网
# 避免公网传输,使用VPC内网或专线

2.4 第四步:IO线程层诊断(从库写入的"吞吐量")

2.4.1 Relay Log堆积检测

-- 查看relay log堆积情况
SHOW SLAVE STATUS\G

-- 关键指标
Relay_Log_Space: 536870912  -- relay log总大小(字节)
Relay_Log_File: relay-bin.000123  -- 当前relay log文件
Relay_Log_Pos: 1234567  -- 当前位置

-- 计算堆积量
SELECT 
    (Read_Master_Log_Pos - Exec_Master_Log_Pos) / 1024 / 1024 AS堆积_MB;

2.4.2 磁盘IO性能检测

# 1. iostat监控
iostat -x 1 10
# 关键指标
# %util: 磁盘利用率(>80%表示瓶颈)
# await: IO等待时间(<10ms正常)
# svctm: 服务时间(<5ms正常)
# 2. fio测试
fio --filename=/var/lib/mysql/test.io --direct=1 --rw=write \
    --bs=16k --size=1G --numjobs=1 --runtime=60 --group_reporting
# 3. 查看relay log写入速度
watch -n 1 'ls -lh /var/lib/mysql/relay-bin.* | tail -5'

2.4.3 IO线程瓶颈特征

现象可能原因解决方案
Relay_Log_Space快速增长磁盘写入慢升级SSD、优化IO调度
IO线程CPU占用高解析binlog慢升级CPU、启用并行IO
磁盘%util > 80%IO瓶颈优化磁盘、调整innodb_flush

2.4.4 IO层优化方案

-- 1. 调整relay log相关参数
SET GLOBAL relay_log_recovery = ON;  -- 崩溃恢复更快
SET GLOBAL relay_log_purge = ON;     -- 及时清理

-- 2. 优化磁盘IO
[mysqld]
# relay log优化
relay_log_info_repository = TABLE
relay_log_recovery = ON
sync_relay_log = 10000  # 每10000个事件同步一次

# InnoDB优化
innodb_flush_log_at_trx_commit = 2  # 从库可设为2
innodb_flush_method = O_DIRECT
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000

-- 3. 使用更快的存储
# SSD/NVMe替代HDD
# RAID 10配置

2.5 第五步:SQL线程层诊断(最常见根因)

2.5.1 SQL执行慢查询分析

-- 1. 查看当前SQL线程状态
SHOW PROCESSLIST;
-- 找到"Slave_SQL_Running_State"字段

-- 2. 开启慢查询日志(从库)
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;  -- 1秒以上记录
SET GLOBAL log_slow_slave_statements = ON;  -- 记录复制的慢SQL

-- 3. 分析慢查询日志
mysqldumpslow -s t /var/log/mysql/slow.log | head -20

-- 4. 实时监控SQL线程
SELECT * FROM performance_schema.replication_applier_status_by_worker;

2.5.2 常见延迟场景及特征

场景特征诊断方法
大事务单个事务执行时间长SHOW ENGINE INNODB STATUS
无索引更新UPDATE/DELETE全表扫描慢查询日志、EXPLAIN
锁竞争SQL线程等待锁SHOW ENGINE INNODB STATUS
DDL操作ALTER TABLE阻塞进程列表、元数据锁
主从硬件差异从库性能弱对比主从配置

2.5.3 大事务诊断

-- 1. 查看当前执行的事务
SELECT * FROM information_schema.innodb_trx 
WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;

-- 2. 查看长时间运行的SQL
SELECT 
    id, user, host, db, command, time, state, info
FROM information_schema.processlist 
WHERE command != 'Sleep' AND time > 60
ORDER BY time DESC;

-- 3. 分析binlog中的大事务
mysqlbinlog --base64-output=DECODE-ROWS \
    --start-position=1234567 \
    /var/lib/mysql/mysql-bin.000001 | \
    grep -A 100 "BEGIN" | head -200

2.5.4 锁竞争诊断

-- 1. 查看InnoDB锁等待
SELECT 
    r.trx_id AS waiting_trx_id,
    r.trx_mysql_thread_id AS waiting_thread,
    r.trx_query AS waiting_query,
    b.trx_id AS blocking_trx_id,
    b.trx_mysql_thread_id AS blocking_thread,
    b.trx_query AS blocking_query
FROM information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;

-- 2. 查看元数据锁(DDL阻塞)
SELECT * FROM performance_schema.metadata_locks 
WHERE OWNER_THREAD_ID != CONNECTION_ID();

2.5.5 SQL线程优化方案

-- 1. 启用并行复制(MySQL 5.7+)
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL slave_parallel_workers = 8;  -- 根据CPU核心数设置
SET GLOBAL slave_preserve_commit_order = ON;

-- 2. 优化SQL执行
-- 主库优化:添加索引、拆分大事务、避免DDL高峰
-- 从库优化:调整buffer pool、优化查询缓存

-- 3. 调整复制参数
[mysqld]
# 并行复制
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
slave_preserve_commit_order = ON

# SQL线程优化
slave_transaction_retries = 10
slave_net_timeout = 60

# Buffer优化
innodb_buffer_pool_size = 12G  # 物理内存的70-80%
innodb_log_file_size = 2G

三、深层陷阱:高并发场景特殊问题

3.1 大事务问题

3.1.1 大事务特征

-- 单个事务包含大量操作
BEGIN;
-- 插入10万条记录
INSERT INTO orders SELECT * FROM temp_orders;
COMMIT;

-- 影响:从库必须顺序执行,无法并行

3.1.2 解决方案

-- 1. 拆分大事务
DELIMITER $$
CREATE PROCEDURE split_large_transaction()
BEGIN
    DECLARE i INT DEFAULT 0;
    WHILE i < 100 DO
        START TRANSACTION;
        INSERT INTO orders 
        SELECT * FROM temp_orders 
        LIMIT 1000 OFFSET i*1000;
        COMMIT;
        SET i = i + 1;
    END WHILE;
END$$
DELIMITER ;

-- 2. 使用批量插入优化
INSERT INTO orders (col1, col2) VALUES 
    (val1, val2),
    (val3, val4),
    ...;

3.2 DDL操作阻塞

3.2.1 在线DDL工具

# 使用pt-online-schema-change
pt-online-schema-change \
    --alter "ADD COLUMN new_col INT" \
    --execute \
    D=your_db,t=your_table,h=localhost

# 使用gh-ost
gh-ost \
    --user="user" \
    --password="pass" \
    --host=localhost \
    --database="your_db" \
    --table="your_table" \
    --alter="ADD COLUMN new_col INT" \
    --execute

3.3 主从硬件差异

3.3.1 配置对比检查

-- 主从配置对比脚本
SELECT 
    '主库' AS server,
    @@innodb_buffer_pool_size AS buffer_pool,
    @@innodb_log_file_size AS log_file_size,
    @@max_connections AS max_connections
UNION ALL
SELECT 
    '从库',
    @@innodb_buffer_pool_size,
    @@innodb_log_file_size,
    @@max_connections;

3.3.2 硬件升级建议

组件主库配置从库最低配置推荐配置
CPU16核8核16核
内存32GB16GB32GB
磁盘NVMe SSDSSDNVMe SSD
网络10Gbps1Gbps10Gbps

四、诊断工具链:程序员的"透视眼"

4.1 内置诊断工具

-- 1. 复制状态查看
SHOW SLAVE STATUS\G
SHOW MASTER STATUS\G
SHOW PROCESSLIST\G

-- 2. 性能模式监控
SELECT * FROM performance_schema.replication_connection_status;
SELECT * FROM performance_schema.replication_applier_status;
SELECT * FROM performance_schema.replication_applier_status_by_worker;

-- 3. InnoDB状态
SHOW ENGINE INNODB STATUS\G

-- 4. 锁信息
SELECT * FROM information_schema.innodb_locks;
SELECT * FROM information_schema.innodb_lock_waits;

4.2 外部监控工具

4.2.1 Prometheus + Grafana

# prometheus.yml
- job_name: 'mysql'
  static_configs:
    - targets: ['主库IP:9104', '从库IP:9104']

关键监控指标

4.2.2 Percona Monitoring

# 安装PMM
docker run -d \
  -p 443:443 \
  -v pmm-data:/srv \
  --name pmm-server \
  --restart always \
  percona/pmm-server:2

# 安装客户端
pmm-admin config --server-insecure-tls --server-url=https://admin:admin@pmm-server
pmm-admin add mysql --username=root --password=your_password

4.3 自动化诊断脚本

#!/bin/bash
# mysql_replication_diagnose.sh

echo "=== MySQL主从延迟诊断报告 ==="
echo "时间: $(date '+%Y-%m-%d %H:%M:%S')"

# 1. 基础信息
mysql -e "SHOW SLAVE STATUS\G" | grep -E "Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master|Relay_Master_Log_File|Exec_Master_Log_Pos"

# 2. 延迟计算
DELAY=$(mysql -N -e "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master" | awk '{print $2}')
echo "当前延迟: ${DELAY}s"

# 3. 线程状态
echo "--- 线程状态 ---"
mysql -e "SHOW PROCESSLIST\G" | grep -A 5 "Slave"

# 4. 磁盘IO
echo "--- 磁盘IO状态 ---"
iostat -x 1 3 | tail -20

# 5. 网络延迟
echo "--- 网络延迟 ---"
ping -c 5 $(mysql -N -e "SHOW SLAVE STATUS\G" | grep "Master_Host" | awk '{print $2}')

echo "=== 诊断完成 ==="

五、适用场景与选型指南

5.1 不同业务场景的延迟容忍度

业务场景延迟容忍度推荐架构关键参数
电商订单< 1秒半同步复制rpl_semi_sync_master_wait_for_slave_count=1
社交消息< 5秒异步复制+并行slave_parallel_workers=8
报表分析< 60秒异步复制无需特殊配置
金融交易< 100ms组复制(MGR)group_replication_single_primary_mode=ON
日志归档< 300秒异步复制调整sync_binlog

5.2 复制模式选型对比

复制模式延迟一致性可用性适用场景
异步复制最终一致读多写少、容忍延迟
半同步复制强一致金融、电商核心业务
组复制(MGR)强一致高可用、强一致性要求
InnoDB Cluster强一致极高企业级关键业务

5.3 MySQL版本特性对比

版本并行复制半同步组复制推荐度
5.6基于库支持不支持⭐⭐
5.7基于组提交增强实验性⭐⭐⭐⭐
8.0增强并行优化生产可用⭐⭐⭐⭐⭐

六、全链路环境标准化实战

6.1 生产环境配置模板

# my.cnf 生产环境标准配置
[mysqld]
# 基础配置
server-id = 101  # 主库
log-bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL
# 复制优化
sync_binlog = 1000  # 主库可适当降低
innodb_flush_log_at_trx_commit = 1  # 主库保持1
# 并行复制(从库)
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
slave_preserve_commit_order = ON
# Relay Log优化
relay_log_info_repository = TABLE
relay_log_recovery = ON
sync_relay_log = 10000
# Buffer优化
innodb_buffer_pool_size = 12G
innodb_log_file_size = 2G
innodb_flush_method = O_DIRECT
# 监控
performance_schema = ON
log_slow_slave_statements = ON
long_query_time = 1

6.2 自动化监控告警体系

# alert_rules.yml
groups:
  - name: mysql_replication
    rules:
      - alert: MySQLReplicationDelay
        expr: mysql_slave_seconds_behind_master > 10
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "MySQL主从延迟过高"
          description: "从库 {{ $labels.instance }} 延迟 {{ $value }} 秒"
      - alert: MySQLReplicationStopped
        expr: mysql_slave_sql_running == 0 or mysql_slave_io_running == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "MySQL复制停止"
          description: "从库 {{ $labels.instance }} 复制线程停止"
      - alert: MySQLRelayLogAccumulation
        expr: rate(mysql_slave_relay_log_pos[5m]) < 10000
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "MySQL Relay Log堆积"
          description: "从库 {{ $labels.instance }} Relay Log堆积"

6.3 故障自愈脚本

#!/bin/bash
# auto_heal_replication.sh
DELAY_THRESHOLD=60
MAX_RETRY=3
while true; do
    # 获取当前延迟
    DELAY=$(mysql -N -e "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master" | awk '{print $2}')
    # 检查延迟是否超标
    if [ "$DELAY" -gt "$DELAY_THRESHOLD" ]; then
        echo "$(date): 检测到延迟 $DELAY 秒,开始自动修复"
        # 检查SQL线程状态
        SQL_RUNNING=$(mysql -N -e "SHOW SLAVE STATUS\G" | grep "Slave_SQL_Running" | awk '{print $2}')
        if [ "$SQL_RUNNING" == "No" ]; then
            echo "SQL线程停止,尝试重启"
            mysql -e "STOP SLAVE; START SLAVE;"
        fi
        # 检查是否有错误
        LAST_ERROR=$(mysql -N -e "SHOW SLAVE STATUS\G" | grep "Last_SQL_Error" | awk '{$1=$2=""; print $0}')
        if [ -n "$LAST_ERROR" ]; then
            echo "检测到错误: $LAST_ERROR"
            # 跳过错误(谨慎使用)
            mysql -e "STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;"
        fi
    fi
    sleep 60
done

七、关键参数速查表

7.1 主库关键参数

参数推荐值说明影响
sync_binlog1000binlog同步频率延迟↑, 性能↑
binlog_group_commit_sync_delay100组提交延迟延迟↑, 吞吐↑
binlog_transaction_compressionONbinlog压缩网络↓, CPU↑
innodb_flush_log_at_trx_commit1日志刷新策略一致性↑, 性能↓

7.2 从库关键参数

参数推荐值说明影响
slave_parallel_typeLOGICAL_CLOCK并行复制类型延迟↓, CPU↑
slave_parallel_workers8并行工作线程数延迟↓, CPU↑
slave_preserve_commit_orderON保持提交顺序一致性↑
relay_log_recoveryONRelay Log恢复可靠性↑
sync_relay_log10000Relay Log同步频率延迟↓, 可靠性↓
innodb_flush_log_at_trx_commit2从库日志策略性能↑, 可靠性↓

7.3 监控相关参数

参数推荐值说明
log_slow_slave_statementsON记录从库慢查询
long_query_time1慢查询阈值(秒)
performance_schemaON性能模式
relay_log_info_repositoryTABLERelay信息存储方式

八、建立持续治理SOP

8.1 日常巡检清单

每日检查

每周检查

每月检查

8.2 故障处理流程

发现延迟告警
    ↓
确认延迟真实性(心跳表验证)
    ↓
定位瓶颈层次(IO/SQL/网络)
    ↓
针对性处理
    ├─ 网络问题 → 联系网络团队
    ├─ IO问题 → 优化磁盘、调整参数
    └─ SQL问题 → 优化查询、启用并行
    ↓
验证修复效果
    ↓
记录故障报告
    ↓
优化预防措施

8.3 性能基线建立

-- 建立性能基线表
CREATE TABLE replication_baseline (
    id INT AUTO_INCREMENT PRIMARY KEY,
    record_time DATETIME,
    avg_delay_seconds DECIMAL(10,2),
    max_delay_seconds DECIMAL(10,2),
    io_thread_status VARCHAR(20),
    sql_thread_status VARCHAR(20),
    relay_log_size_mb DECIMAL(10,2),
    network_latency_ms DECIMAL(10,2),
    INDEX idx_record_time (record_time)
);

-- 定时记录基线数据
DELIMITER $$
CREATE EVENT record_replication_baseline
ON SCHEDULE EVERY 1 HOUR
DO
BEGIN
    INSERT INTO replication_baseline 
    SELECT 
        NOW(),
        AVG(Seconds_Behind_Master),
        MAX(Seconds_Behind_Master),
        Slave_IO_Running,
        Slave_SQL_Running,
        Relay_Log_Space / 1024 / 1024,
        -- 网络延迟需要外部脚本获取
        0
    FROM information_schema.slave_status;
END$$
DELIMITER ;

九、总结与最佳实践

9.1 核心要点回顾

  1. 诊断三步法:量化 → 定位 → 优化
  2. 瓶颈定位:网络 → IO → SQL → 参数
  3. 关键指标:真实延迟、Relay Log堆积、线程状态
  4. 并行复制:MySQL 5.7+必须启用
  5. 监控告警:建立全链路监控体系

9.2 最佳实践清单

架构设计

参数配置

监控告警

运维管理

9.3 常见误区避坑

误区正确做法
只看Seconds_Behind_Master使用心跳表计算真实延迟
从库配置远低于主库主从同规格或从库更高
忽视网络质量定期网络性能测试
大事务不拆分拆分为小事务
不启用并行复制MySQL 5.7+必须启用

十、附录

附录A:快速诊断命令集

# 1. 基础状态
mysql -e "SHOW SLAVE STATUS\G" | grep -E "Running|Behind|Position"
# 2. 真实延迟(心跳表)
mysql -e "SELECT TIMESTAMPDIFF(SECOND, ts, NOW()) AS delay FROM heartbeat ORDER BY id DESC LIMIT 1;"
# 3. Relay Log堆积
mysql -e "SHOW SLAVE STATUS\G" | awk '/Read_Master_Log_Pos|Exec_Master_Log_Pos/{print $2}' | awk 'NR==1{a=$1} NR==2{print "堆积: " (a-$1)/1024/1024 " MB"}'
# 4. 线程状态
mysql -e "SHOW PROCESSLIST\G" | grep -A 3 "Slave"
# 5. 网络延迟
ping -c 5 $(mysql -N -e "SHOW SLAVE STATUS\G" | grep Master_Host | awk '{print $2}')
# 6. 磁盘IO
iostat -x 1 5 | grep -A 5 "Device"

附录B:推荐工具清单

工具用途链接
pt-heartbeat真实延迟监控https://www.percona.com/doc/percona-toolkit/LATEST/pt-heartbeat.html
pt-online-schema-change在线DDLhttps://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html
gh-ostGitHub在线DDLhttps://github.com/github/gh-ost
Prometheus监控采集https://prometheus.io/
Grafana可视化https://grafana.com/
PMMPercona监控https://www.percona.com/doc/percona-monitoring-and-management/index.html

附录C:参考配置文件

完整my.cnf配置示例

# MySQL 8.0 主从复制生产配置
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld]
# 基础配置
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
datadir = /var/lib/mysql
tmpdir = /tmp
# 网络配置
bind-address = 0.0.0.0
port = 3306
max_connections = 500
# 复制配置(主库)
server-id = 101
log-bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL
sync_binlog = 1000
binlog_group_commit_sync_delay = 100
binlog_transaction_compression = ON
binlog_transaction_compression_level_zstd = 3
# 复制配置(从库)
# server-id = 102
# relay_log = mysql-relay-bin
# read_only = ON
# super_read_only = ON
# 并行复制(从库)
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
slave_preserve_commit_order = ON
relay_log_info_repository = TABLE
relay_log_recovery = ON
sync_relay_log = 10000
log_slow_slave_statements = ON
# InnoDB配置
innodb_buffer_pool_size = 12G
innodb_log_file_size = 2G
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 1  # 从库可设为2
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
innodb_file_per_table = ON
# 性能优化
performance_schema = ON
thread_cache_size = 100
table_open_cache = 4000
query_cache_type = 0
query_cache_size = 0
# 监控配置
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = ON
# 安全配置
skip_name_resolve = ON
sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
[mysqldump]
quick
quote-names
max_allowed_packet = 64M
[mysql]
no-auto-rehash
[isamchk]
key_buffer_size = 16M

适用版本:MySQL 5.7 / 8.0
适用场景:高并发写入、主从延迟告警、从库追不上主库

通过本文的系统化诊断方法,你可以快速定位主从延迟的根因,并采取针对性的优化措施。记住:延迟不是单一故障,是系统病的综合症。建立完善的监控告警体系和持续治理机制,才能从根本上解决主从延迟问题。

以上就是MySQL主从延迟根因诊断法全面详解的详细内容,更多关于MySQL主从延迟根因诊断法的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文