印刻数据库

外观

MySQL 逻辑复制监控 ​

逻辑复制的关键组件 ​

1. 二进制日志（Binary Log） ​

主库上记录所有数据更改事件的日志，逻辑复制的基础。

2. 复制源（Source） ​

提供数据更改事件的主库，原称为主库（Master）。

3. 复制通道（Replication Channel） ​

逻辑复制中的复制通道，用于管理特定的复制流。

4. 复制接收器（Receiver） ​

从库上接收主库二进制日志的组件。

5. 复制应用器（Applier） ​

从库上应用主库二进制日志事件的组件。

6. 中继日志（Relay Log） ​

从库上临时存储主库二进制日志的日志文件。

逻辑复制监控的重要性 ​

逻辑复制监控对于确保复制的可靠性和性能至关重要，主要体现在以下方面：

  • 及时发现复制故障：通过监控可以及时发现复制中断、错误等问题
  • 监控复制延迟：确保从库与主库的数据一致性
  • 优化复制性能：识别复制瓶颈，优化复制配置
  • 规划容量：基于复制负载规划系统容量
  • 故障诊断：当复制出现问题时，提供诊断依据

逻辑复制监控的核心指标 ​

1. 复制状态 ​

  • 复制是否运行：判断复制进程是否正常运行
  • 复制通道状态：每个复制通道的运行状态
  • 错误信息：复制过程中发生的错误

2. 复制延迟 ​

  • SQL 延迟：从库应用 SQL 线程的延迟
  • IO 延迟：从库接收二进制日志的延迟
  • 总延迟：从库与主库的总延迟

3. 复制吞吐量 ​

  • 每秒应用的事务数：从库每秒应用的事务数量
  • 每秒应用的事件数：从库每秒应用的二进制日志事件数量
  • 二进制日志传输速率：主库到从库的二进制日志传输速率

4. 复制队列 ​

  • 中继日志队列大小：从库上未应用的中继日志大小
  • 二进制日志队列大小：主库上未传输的二进制日志大小

5. 复制配置 ​

  • 复制过滤规则：应用的表级或库级过滤规则
  • 复制模式：异步、半同步或同步复制
  • 复制线程数：应用器线程数量

监控逻辑复制的方法 ​

1. 使用 MySQL 内置命令 ​

1.1 SHOW REPLICA STATUS ​

MySQL 8.0.22+ 推荐使用的命令，用于查看从库的复制状态。

sql
SHOW REPLICA STATUS\G

关键字段说明：

  • Replica_IO_State：从库 IO 线程的状态
  • Source_Host：主库主机名
  • Source_User：复制用户名
  • Source_Port：主库端口
  • Connect_Retry：连接重试间隔
  • Source_Log_File：当前读取的主库二进制日志文件
  • Read_Source_Log_Pos：当前读取的主库二进制日志位置
  • Relay_Log_File：当前写入的中继日志文件
  • Relay_Log_Pos：当前写入的中继日志位置
  • Relay_Master_Log_File：当前应用的主库二进制日志文件
  • Exec_Source_Log_Pos：当前应用的主库二进制日志位置
  • Relay_Log_Space：中继日志总大小
  • Replica_IO_Running：IO 线程是否运行
  • Replica_SQL_Running：SQL 线程是否运行
  • Replicate_Do_DB：需要复制的数据库
  • Replicate_Ignore_DB：需要忽略的数据库
  • Replicate_Do_Table：需要复制的表
  • Replicate_Ignore_Table：需要忽略的表
  • Replicate_Wild_Do_Table：需要复制的通配符表
  • Replicate_Wild_Ignore_Table：需要忽略的通配符表
  • Last_Errno：最后一个错误编号
  • Last_Error：最后一个错误信息
  • Skip_Counter：跳过的事件数
  • Exec_Master_Log_Pos：已执行的主库二进制日志位置
  • Relay_Log_Space：中继日志总大小
  • Until_Condition：复制停止条件
  • Until_Log_File：复制停止的日志文件
  • Until_Log_Pos：复制停止的日志位置
  • Master_SSL_Allowed：是否允许 SSL 连接
  • Seconds_Behind_Source：从库延迟秒数
  • Source_SSL_Verify_Server_Cert：是否验证主库 SSL 证书
  • Last_IO_Errno：最后一个 IO 错误编号
  • Last_IO_Error：最后一个 IO 错误信息
  • Last_SQL_Errno：最后一个 SQL 错误编号
  • Last_SQL_Error：最后一个 SQL 错误信息

1.2 SHOW SLAVE STATUS ​

MySQL 8.0.22 之前版本使用的命令，功能与 SHOW REPLICA STATUS 类似。

sql
SHOW SLAVE STATUS\G

1.3 SHOW REPLICA STATUS FOR CHANNEL ​

用于查看特定复制通道的状态。

sql
SHOW REPLICA STATUS FOR CHANNEL 'channel_name'\G

1.4 SHOW PROCESSLIST ​

查看复制相关进程的状态。

sql
SHOW PROCESSLIST;

2. 使用 Performance Schema ​

MySQL 5.6 引入的 Performance Schema 提供了丰富的复制监控指标。

2.1 监控复制源（Source） ​

sql
-- 查看二进制日志统计信息
SELECT * FROM performance_schema.global_status WHERE VARIABLE_NAME LIKE 'Binlog%';

-- 查看复制连接统计信息
SELECT * FROM performance_schema.replication_connection_status;

2.2 监控复制接收器（Receiver） ​

sql
-- 查看复制接收器统计信息
SELECT * FROM performance_schema.replication_applier_status_by_worker;

2.3 监控复制应用器（Applier） ​

sql
-- 查看复制应用器统计信息
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;

3. 使用 Sys Schema ​

MySQL 5.7 引入的 Sys Schema 提供了更友好的复制监控视图。

3.1 查看复制状态 ​

sql
-- 查看复制状态摘要
SELECT * FROM sys.replication_status;

-- 查看复制通道状态
SELECT * FROM sys.replication_connection_status;

-- 查看复制应用器状态
SELECT * FROM sys.replication_applier_status_by_worker;

3.2 监控复制延迟 ​

sql
-- 查看复制延迟
SELECT * FROM sys.replication_delay;

4. 使用第三方监控工具 ​

4.1 MySQL Enterprise Monitor ​

MySQL 官方提供的企业级监控工具，支持复制监控、性能监控、安全监控等。

特点：

  • 全面的复制监控
  • 实时告警
  • 历史趋势分析
  • 可视化仪表盘
  • 自动故障检测

4.2 Prometheus + Grafana ​

开源监控组合，通过 MySQL Exporter 收集复制指标。

配置步骤：

  1. 安装 MySQL Exporter
  2. 配置 Prometheus 采集 MySQL 指标
  3. 配置 Grafana 仪表盘

常用指标：

  • mysql_slave_status_seconds_behind_master：复制延迟
  • mysql_slave_status_slave_io_running：IO 线程状态
  • mysql_slave_status_slave_sql_running：SQL 线程状态

4.3 Zabbix ​

开源监控系统，支持 MySQL 复制监控。

配置步骤：

  1. 安装 Zabbix Agent
  2. 配置 MySQL 监控模板
  3. 添加复制监控项
  4. 配置告警规则

4.4 Nagios ​

开源监控系统，通过插件支持 MySQL 复制监控。

常用插件：

  • check_mysql_health：支持复制状态和延迟监控
  • check_mysql_replication：专门用于复制监控

逻辑复制延迟监控 ​

1. 延迟产生的原因 ​

  • 网络延迟：主从库之间的网络延迟
  • 主库负载：主库高负载导致二进制日志写入延迟
  • 从库负载：从库高负载导致中继日志应用延迟
  • 大事务：主库上的大事务导致从库应用延迟
  • DDL 操作：主库上的 DDL 操作导致从库应用延迟
  • 复制过滤：从库上的复制过滤规则增加处理开销

2. 延迟监控方法 ​

2.1 使用 Seconds_Behind_Source ​

最常用的复制延迟指标，通过 SHOW REPLICA STATUS 命令获取。

sql
SHOW REPLICA STATUS\G

注意：

  • 对于逻辑复制，该指标可能不准确，因为它基于主库和从库的时间戳
  • 当从库 SQL 线程停止时，该值会显示为 NULL

2.2 使用 GTID 集比较 ​

通过比较主库和从库的 GTID 集来计算复制延迟。

sql
-- 主库上获取已执行的 GTID 集
SELECT @@GLOBAL.gtid_executed;

-- 从库上获取已执行的 GTID 集
SELECT @@GLOBAL.gtid_executed;

-- 计算差异

2.3 使用心跳表 ​

在主库上创建一个心跳表，定期更新时间戳，从库上查询该表来计算延迟。

实现步骤：

  1. 在主库上创建心跳表
  2. 创建一个事件定期更新心跳表
  3. 在从库上查询心跳表，计算与主库的时间差

示例：

sql
-- 主库上创建心跳表
CREATE TABLE heartbeat (
    id INT PRIMARY KEY,
    update_time TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6)
);

-- 插入初始数据
INSERT INTO heartbeat (id) VALUES (1);

-- 创建事件定期更新心跳表
CREATE EVENT update_heartbeat
ON SCHEDULE EVERY 1 SECOND
DO
    UPDATE heartbeat SET update_time = CURRENT_TIMESTAMP(6) WHERE id = 1;

-- 从库上计算延迟
SELECT TIMESTAMPDIFF(SECOND, update_time, CURRENT_TIMESTAMP(6)) AS delay_seconds
FROM heartbeat;

3. 延迟阈值设置 ​

复制延迟阈值应根据业务需求设置，常见的阈值设置：

  • 实时业务：延迟应小于 1 秒
  • 近实时业务：延迟应小于 5 秒
  • 非实时业务：延迟可接受几分钟甚至几小时

逻辑复制故障监控 ​

1. 常见复制故障类型 ​

1.1 连接故障 ​

  • 主库不可达
  • 复制用户权限问题
  • 网络连接问题

1.2 日志故障 ​

  • 主库二进制日志丢失
  • 从库中继日志损坏
  • 二进制日志格式不兼容

1.3 SQL 应用故障 ​

  • 从库表结构与主库不一致
  • 从库数据与主库冲突
  • 从库缺少必要的权限
  • 复制过滤规则错误

1.4 配置故障 ​

  • 复制参数配置错误
  • 二进制日志配置错误
  • 复制通道配置错误

2. 故障检测方法 ​

2.1 监控复制线程状态 ​

sql
-- 检查复制线程是否运行
SHOW REPLICA STATUS\G

关键字段：

  • Replica_IO_Running：IO 线程状态
  • Replica_SQL_Running：SQL 线程状态

2.2 监控错误日志 ​

定期检查 MySQL 错误日志，查找复制相关错误。

bash
# 查看错误日志
tail -n 100 /var/log/mysql/error.log

2.3 使用 Performance Schema 监控错误 ​

sql
-- 查看复制错误
SELECT * FROM performance_schema.replication_applier_status_by_worker WHERE LAST_ERROR_NUMBER > 0;

3. 故障自动恢复 ​

3.1 使用 MySQL 内置的自动恢复 ​

MySQL 8.0 引入了复制自动恢复功能，可以自动处理某些复制故障。

配置参数：

ini
# 启用复制自动恢复
replica_auto_recovery = ON

# 自动恢复重试间隔
replica_parallel_type = LOGICAL_CLOCK

# 并行复制线程数
replica_parallel_workers = 4

3.2 使用第三方工具实现自动恢复 ​

  • MySQL Orchestrator：支持复制拓扑管理和自动故障转移
  • MHA (Master High Availability)：支持 MySQL 复制的自动故障转移
  • ProxySQL：支持读写分离和自动故障转移

逻辑复制性能监控 ​

1. 性能指标 ​

  • 二进制日志生成速率：主库每秒生成的二进制日志大小
  • 复制传输速率：主库到从库的二进制日志传输速率
  • 复制应用速率：从库每秒应用的二进制日志事件数
  • 复制线程负载：复制相关线程的 CPU 和内存使用率
  • 中继日志增长速率：从库中继日志的增长速率

2. 性能瓶颈识别 ​

2.1 主库瓶颈 ​

  • 二进制日志写入瓶颈：主库 IO 负载过高
  • 连接数过多：主库连接数达到上限
  • 大事务：主库上执行大事务

2.2 从库瓶颈 ​

  • SQL 应用瓶颈：从库 CPU 负载过高
  • 中继日志应用瓶颈：从库 IO 负载过高
  • 并行复制配置不当：并行复制线程数不足

3. 性能优化方法 ​

3.1 优化主库配置 ​

ini
# 增大二进制日志缓存
binlog_cache_size = 32M
max_binlog_cache_size = 1G

# 增大二进制日志文件大小
max_binlog_size = 1G

# 使用 row 格式
binlog_format = ROW

3.2 优化从库配置 ​

ini
# 启用并行复制
replica_parallel_type = LOGICAL_CLOCK
replica_parallel_workers = 8

# 增大中继日志缓存
relay_log_cache_size = 32M
max_relay_log_cache_size = 1G

# 增大中继日志文件大小
max_relay_log_size = 1G

3.3 优化网络配置 ​

  • 确保主从库之间的网络带宽充足
  • 减少主从库之间的网络延迟
  • 考虑使用专用网络进行复制

逻辑复制监控的最佳实践 ​

1. 建立完善的监控体系 ​

  • 多层次监控：结合内置命令、Performance Schema、第三方工具
  • 全面覆盖：监控复制状态、延迟、性能、故障等各个方面
  • 实时告警：设置合理的告警阈值，及时通知运维人员

2. 定期进行复制健康检查 ​

  • 每周至少进行一次全面的复制健康检查
  • 检查复制状态、延迟、性能等指标
  • 检查复制配置是否正确
  • 检查复制过滤规则是否生效

3. 建立复制故障应急预案 ​

  • 制定详细的复制故障处理流程
  • 定期进行故障演练
  • 准备必要的工具和脚本
  • 确保运维人员熟悉故障处理流程

4. 优化复制配置 ​

  • 根据业务需求调整复制配置
  • 优化并行复制线程数
  • 调整复制缓冲大小
  • 优化二进制日志格式

5. 监控复制拓扑变化 ​

  • 监控复制拓扑的变化
  • 确保复制拓扑的正确性
  • 及时发现异常的复制关系

不同版本的逻辑复制监控差异 ​

MySQL 8.0.0-8.0.21 ​

  • 使用 SHOW SLAVE STATUS 命令
  • 支持基本的逻辑复制监控
  • Performance Schema 中的复制监控视图有限

MySQL 8.0.22+ ​

  • 推荐使用 SHOW REPLICA STATUS 命令
  • 增强了 Performance Schema 中的复制监控视图
  • 引入了更多的复制监控指标
  • 支持更细粒度的复制监控

常见问题（FAQ） ​

Q1: 如何区分物理复制和逻辑复制的监控？ ​

A1: 物理复制和逻辑复制的监控有以下区别：

  • 监控命令：物理复制使用 SHOW SLAVE STATUS，逻辑复制推荐使用 SHOW REPLICA STATUS
  • 监控指标：逻辑复制增加了复制通道、复制过滤等监控指标
  • 延迟计算：逻辑复制的延迟计算可能更复杂，需要结合多种方法
  • 故障类型：逻辑复制可能出现更多的 SQL 应用错误

Q2: 如何处理逻辑复制延迟过高的问题？ ​

A2: 处理逻辑复制延迟过高的方法包括：

  • 优化主库性能，减少二进制日志生成延迟
  • 优化从库性能，增加并行复制线程数
  • 减少主库上的大事务
  • 优化网络连接，减少网络延迟
  • 检查复制过滤规则，避免不必要的过滤开销
  • 考虑使用多个从库分担负载

Q3: 如何监控多个复制通道？ ​

A3: 监控多个复制通道的方法包括：

  • 使用 SHOW REPLICA STATUS FOR CHANNEL 命令逐个检查
  • 查询 Performance Schema 中的复制监控视图
  • 使用第三方监控工具，如 MySQL Enterprise Monitor、Prometheus + Grafana
  • 编写脚本定期检查所有复制通道

Q4: 如何自动检测和恢复逻辑复制故障？ ​

A4: 自动检测和恢复逻辑复制故障的方法包括：

  • 启用 MySQL 8.0 的复制自动恢复功能（replica_auto_recovery = ON）
  • 使用 MySQL Orchestrator 实现自动故障转移
  • 使用 MHA 实现自动故障转移
  • 使用 ProxySQL 实现读写分离和自动故障转移
  • 编写自定义脚本监控复制状态，自动处理常见故障

Q5: 如何监控跨版本逻辑复制？ ​

A5: 监控跨版本逻辑复制的方法与监控同版本逻辑复制类似，但需要注意：

  • 确保主库和从库的二进制日志格式兼容
  • 监控复制过程中的兼容性错误
  • 关注跨版本复制的性能差异
  • 定期测试跨版本复制的可靠性

Q6: 如何使用 Performance Schema 监控逻辑复制？ ​

A6: 使用 Performance Schema 监控逻辑复制的方法包括：

  • 查询 replication_connection_status 表监控复制连接状态
  • 查询 replication_applier_status_by_worker 表监控复制应用状态
  • 查询 replication_applier_status_by_coordinator 表监控复制协调器状态
  • 查询 replication_asynchronous_connection_failover 表监控异步连接故障转移

Q7: 如何设置合理的复制延迟告警阈值？ ​

A7: 设置合理的复制延迟告警阈值需要考虑：

  • 业务对数据一致性的要求
  • 系统的正常复制延迟范围
  • 不同时间段的负载变化
  • 历史复制延迟趋势

一般建议设置多级告警：

  • 警告级：延迟超过 5 秒
  • 严重级：延迟超过 30 秒
  • 紧急级：延迟超过 5 分钟或复制中断