第6章:高可用与复制原理
📖 章节概述
本章将深入讲解 MySQL 的高可用架构和主从复制机制,这是构建企业级数据库系统的核心技能。通过本章学习,你将掌握:
- MySQL 高可用架构的核心目标
- Binlog 的格式和作用
- 主从复制的原理和流程
- 半同步复制和 GTID 机制
- 延迟复制和自动切换方案
- Group Replication 集群技术
🧩 一、MySQL 高可用架构的核心目标
✅ 数据不丢、服务不中断、主从一致、可快速切换
常见 HA 方案
主从复制(Master-Slave)
├─ 异步复制(Async)
├─ 半同步复制(Semi-Sync)
├─ GTID 自动位点同步
├─ 延迟复制(Delay Slave)
└─ Group Replication(官方高可用集群)
🧠 二、Binlog(主从复制的核心)
1️⃣ Binlog 的定义
Binlog 是 MySQL Server 层日志,记录所有导致数据变化的操作(逻辑日志)。
位置:
/var/lib/mysql/mysql-bin.000001
作用:
- 复制(Replication)
- 主从恢复
- 数据恢复(Point-In-Time Recovery)
2️⃣ Binlog 的格式(3 种)
格式 | 含义 | 优点 | 缺点 |
---|---|---|---|
STATEMENT | 记录 SQL 语句 | 空间小 | 不可重放非确定性语句 |
ROW | 记录每行变化 | 精确、安全 | 文件大 |
MIXED | 混合模式 | 自动选择 | 复杂 |
📘 推荐: 生产环境使用 ROW 格式(最安全、复制一致性最好)
binlog_format = ROW
🔄 三、主从复制的原理流程
MySQL 主从复制是基于 Binlog 传输的异步流机制。
1️⃣ 流程示意图
Master Slave
+----------+ +-----------+
| Binlog | ===sync==> | Relay Log |
+----------+ +-----------+
│ │
▼ ▼
Dump Thread I/O Thread → SQL Thread
2️⃣ 工作机制
- 主库执行事务并写入 Binlog
- 从库 I/O 线程请求主库 Binlog
- 主库 Dump 线程发送 binlog 事件
- 从库写入 Relay Log(中继日志)
- 从库 SQL 线程重放 relay log,应用到本地
🧮 四、复制延迟的根源(面试必问)
原因 | 描述 |
---|---|
单线程 SQL 应用 | 从库 SQL 线程串行执行 Binlog |
主从性能差距 | 从库配置弱 |
大事务 | relay log 重放耗时 |
网络抖动 | dump thread 拉取延迟 |
✅ 优化方案:
slave_parallel_workers
多线程复制- 拆分大事务
- 提升从库硬件
- 使用 GTID + Semi-sync 提高同步性
⚙️ 五、半同步复制(Semi-sync Replication)
1️⃣ 异步复制的问题
主库事务提交后立即返回客户端,但从库可能还没接收日志 → 数据可能丢。
2️⃣ 半同步复制原理
主库只有在至少一个从库确认接收 Binlog 后,才认为事务提交成功。
流程:
Client → Master → 写 Binlog → 等至少一从库 ACK → COMMIT
📘 参数:
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_slave_enabled = 1
rpl_semi_sync_master_timeout = 5000
优点: ✅ 数据安全性提升(不易丢失) 缺点: ⚠️ 延迟增加(等待从库 ACK)
🧩 六、GTID(全局事务 ID)
GTID = Global Transaction Identifier
格式:
gtid = server_uuid:transaction_id
例:3E11FA47-71CA-11E1-9E33-C80AA9429562:32
作用:
- 每个事务拥有唯一标识
- 自动管理复制位点
- 主从切换更简单
- 防止重复执行事务
📘 启用方式:
gtid_mode = ON
enforce_gtid_consistency = ON
⚡ 七、延迟复制(Delayed Replication)
Slave 故意延迟 N 秒应用 relay log。
场景: 防止误操作
CHANGE MASTER TO MASTER_DELAY = 600; # 延迟 10 分钟
一旦主库误删数据,可立即切 Slave 恢复。
💥 八、主从切换与 MHA / Orchestrator
1️⃣ MHA(Master High Availability)
- Perl 实现的成熟方案
- 自动检测主库宕机
- 自动提升从库为主
- 支持半同步检测
组件:
- manager:管理节点
- node:部署在各 MySQL 节点上
- 支持自动复制位点同步
2️⃣ Orchestrator(更现代方案)
- Go 实现
- 图形化 Web 管理界面
- 拥有拓扑自愈能力
- 支持 GTID 环境下的自动 failover
- 被阿里云 RDS、Percona 官方采用
🧠 九、Group Replication(官方集群版)
MySQL 5.7+ 自带的高可用同步复制机制。
特点:
- 支持自动选主
- 强一致性(基于 Paxos 协议)
- 事务层面复制
- 可配读写分离
架构图:
┌──────────────┐
│ Group Member │
└─────┬────────┘
│
Replication Plugin (Paxos)
│
┌─────┴────────┐
│ Multi-Primary Mode │
优点: ✅ 数据强一致、自动修复 缺点: ⚠️ 性能比异步差,架构复杂
🔐 十、复制一致性与幂等性问题
问题 | 说明 | 解决方案 |
---|---|---|
重复事务执行 | crash 后可能重放 | Binlog + GTID 去重 |
顺序不一致 | 异步复制延迟 | 半同步复制 / 延迟补偿 |
主从不一致 | 网络中断或崩溃 | 定期校验:pt-table-checksum |
写冲突 | 多主复制场景 | 使用 UUID 或分片主键避免冲突 |
🛠️ 实操演示
实操1:查看 Binlog 配置
-- 查看 Binlog 相关配置
SHOW VARIABLES LIKE 'log_bin%';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
-- 查看当前 Binlog 文件
SHOW BINARY LOGS;
-- 查看当前 Binlog 位置
SHOW MASTER STATUS;
实操2:配置主从复制
主库配置:
-- 1. 创建复制用户
CREATE USER 'repl'@'%' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
-- 2. 查看主库状态
SHOW MASTER STATUS;
-- 记录 File 和 Position 值
从库配置:
-- 1. 配置主库信息
CHANGE MASTER TO
MASTER_HOST='192.168.1.100',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
-- 2. 启动复制
START SLAVE;
-- 3. 查看复制状态
SHOW SLAVE STATUS\G
实操3:GTID 配置
-- 主库配置
SET GLOBAL gtid_mode = ON;
SET GLOBAL enforce_gtid_consistency = ON;
-- 从库配置
CHANGE MASTER TO
MASTER_HOST='192.168.1.100',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_AUTO_POSITION = 1;
START SLAVE;
SHOW SLAVE STATUS\G
实操4:半同步复制配置
-- 主库配置
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_master_timeout = 5000;
-- 从库配置
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
STOP SLAVE;
START SLAVE;
-- 查看半同步状态
SHOW STATUS LIKE 'Rpl_semi_sync%';
实操5:延迟复制配置
-- 配置延迟复制
CHANGE MASTER TO MASTER_DELAY = 600; # 延迟 10 分钟
-- 查看延迟状态
SHOW SLAVE STATUS\G
-- 查看 Seconds_Behind_Master 字段
实操6:复制监控
-- 查看复制状态
SHOW SLAVE STATUS\G
-- 关注字段:
-- Slave_IO_Running: Yes
-- Slave_SQL_Running: Yes
-- Seconds_Behind_Master: 0
-- Last_IO_Error:
-- Last_SQL_Error:
-- 查看复制延迟
SELECT
MASTER_LOG_FILE,
READ_MASTER_LOG_POS,
RELAY_LOG_FILE,
RELAY_LOG_POS,
SLAVE_IO_RUNNING,
SLAVE_SQL_RUNNING,
SECONDS_BEHIND_MASTER
FROM performance_schema.replication_connection_status;
实操7:主从切换演练
-- 1. 停止从库复制
STOP SLAVE;
-- 2. 确保从库数据最新
-- 等待 Seconds_Behind_Master = 0
-- 3. 从库提升为主库
RESET MASTER;
SET GLOBAL read_only = 0;
-- 4. 原主库配置为从库
CHANGE MASTER TO
MASTER_HOST='192.168.1.101',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_AUTO_POSITION = 1;
START SLAVE;
实操8:数据一致性校验
-- 使用 pt-table-checksum 工具校验数据一致性
-- 需要安装 Percona Toolkit
-- 命令行执行:
pt-table-checksum --host=192.168.1.100 --user=root --password=password --databases=mysql_learning
-- 查看校验结果
pt-table-sync --host=192.168.1.100 --user=root --password=password --databases=mysql_learning --print
🎯 实战案例
案例1:电商系统主从架构设计
场景描述: 设计一个电商系统的高可用数据库架构,支持读写分离和自动故障切换。
架构设计:
-- 主库配置(写操作)
-- my.cnf 配置
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
rpl_semi_sync_master_enabled = 1
-- 从库配置(读操作)
[mysqld]
server-id = 2
log-bin = mysql-bin
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
rpl_semi_sync_slave_enabled = 1
read_only = 1
应用层配置:
-- 写操作路由到主库
INSERT INTO orders (user_id, amount) VALUES (1, 99.99);
-- 读操作路由到从库
SELECT * FROM orders WHERE user_id = 1;
-- 使用中间件(如 ProxySQL)自动路由
-- 配置读写分离规则
案例2:多机房容灾方案
场景描述: 设计一个跨机房的数据库容灾方案,确保数据安全和快速恢复。
架构设计:
机房A(主) 机房B(备)
┌─────────────┐ ┌─────────────┐
│ Master │ ──────────── │ Slave │
│ (写) │ │ (读) │
└─────────────┘ └─────────────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Slave │ │ Slave │
│ (读) │ │ (读) │
└─────────────┘ └─────────────┘
配置步骤:
-- 1. 主库配置
SET GLOBAL gtid_mode = ON;
SET GLOBAL enforce_gtid_consistency = ON;
SET GLOBAL rpl_semi_sync_master_enabled = 1;
-- 2. 同机房从库配置
CHANGE MASTER TO
MASTER_HOST='192.168.1.100',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_AUTO_POSITION = 1;
-- 3. 跨机房从库配置
CHANGE MASTER TO
MASTER_HOST='10.0.1.100',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_AUTO_POSITION = 1;
-- 4. 配置延迟复制(防误操作)
CHANGE MASTER TO MASTER_DELAY = 3600; # 延迟1小时
案例3:Group Replication 集群搭建
场景描述: 使用 Group Replication 搭建一个高可用的 MySQL 集群。
配置步骤:
-- 节点1配置
[mysqld]
server-id = 1
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
master_info_repository = TABLE
relay_log_info_repository = TABLE
transaction_write_set_extraction = XXHASH64
loose-group_replication_group_name = "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot = off
loose-group_replication_local_address = "192.168.1.101:33061"
loose-group_replication_group_seeds = "192.168.1.101:33061,192.168.1.102:33061,192.168.1.103:33061"
loose-group_replication_bootstrap_group = off
-- 初始化集群
SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;
-- 其他节点加入集群
START GROUP_REPLICATION;
📝 练习题目
基础题
- 什么是 Binlog?它有什么作用?
- 主从复制的原理是什么?有哪些类型?
- GTID 是什么?它解决了什么问题?
进阶题
- 半同步复制和异步复制的区别是什么?
- 如何解决主从复制延迟问题?
- Group Replication 和传统主从复制的区别是什么?
实战题
- 设计一个跨机房的高可用数据库架构
- 如何监控和调优主从复制性能?
- 在什么场景下会选择 Group Replication?
📚 扩展阅读
🔬 六、Binlog 事件类型与格式详解
深入理解 Binlog 的内部结构,这是复制和恢复的基础:
1️⃣ Binlog 事件类型
事件类型 | 说明 | 源码路径 |
---|---|---|
QUERY_EVENT | SQL 语句 | binlog_event.h |
TABLE_MAP_EVENT | 表结构映射 | binlog_event.h |
WRITE_ROWS_EVENT | INSERT 操作 | binlog_event.h |
UPDATE_ROWS_EVENT | UPDATE 操作 | binlog_event.h |
DELETE_ROWS_EVENT | DELETE 操作 | binlog_event.h |
XID_EVENT | 事务提交 | binlog_event.h |
2️⃣ Binlog 事件结构
// Binlog 事件头结构
struct Log_event_header {
uint32_t timestamp; // 时间戳
uint8_t event_type; // 事件类型
uint32_t server_id; // 服务器ID
uint32_t event_length; // 事件长度
uint32_t next_position; // 下一个事件位置
uint16_t flags; // 标志位
// 源码路径:log_event.h
};
3️⃣ Binlog 解析工具
# 解析 Binlog 文件
mysqlbinlog --verbose --base64-output=decode-rows /var/lib/mysql/mysql-bin.000001
# 输出示例:
# at 154
#200101 12:00:00 server id 1 end_log_pos 245 CRC32 0x1a2b3c4d
# Query event: BEGIN
# Table_map: `db`.`orders` mapped to number 108
# Update_rows event on table `orders`
🧵 七、复制线程与状态监控
深入理解复制线程的协作机制:
1️⃣ 复制线程架构
线程类型 | 作用 | 状态字段 | 监控命令 |
---|---|---|---|
Dump Thread | 主库发送 Binlog | Master_Log_File | SHOW PROCESSLIST |
I/O Thread | 从库接收 Binlog | Relay_Master_Log_File | SHOW SLAVE STATUS |
SQL Thread | 从库重放 Binlog | Exec_Master_Log_Pos | SHOW SLAVE STATUS |
2️⃣ 复制状态监控
-- 查看复制状态
SHOW SLAVE STATUS\G
-- 关键指标说明
-- Seconds_Behind_Master: 复制延迟秒数
-- Last_IO_Error / Last_SQL_Error: 错误信息
-- Relay_Log_Space: 中继日志累计大小
-- Master_Log_File: 主库当前日志文件
-- Read_Master_Log_Pos: 已读取的主库位置
-- Exec_Master_Log_Pos: 已执行的主库位置
3️⃣ 复制延迟分析
-- 查看复制延迟详情
SELECT
CHANNEL_NAME,
SOURCE_HOST,
SOURCE_PORT,
SLAVE_IO_RUNNING,
SLAVE_SQL_RUNNING,
SLAVE_LAG,
SLAVE_DELAY
FROM performance_schema.replication_connection_status;
-- 查看复制性能统计
SELECT
CHANNEL_NAME,
COUNT_TRANSACTIONS_RETRIES,
COUNT_DUPLICATE_KEYS,
COUNT_SLAVE_DELAY
FROM performance_schema.replication_applier_status;
🔄 八、GTID 内部机制与容灾
1️⃣ GTID 结构解析
// GTID 结构定义
struct Gtid {
rpl_sidno sidno; // 服务器ID编号
rpl_gno gno; // 事务编号
// 源码路径:rpl_gtid.h
};
// GTID 集合
struct Gtid_set {
rpl_sidno max_sidno; // 最大服务器ID编号
Gtid* gtids; // GTID数组
// 源码路径:rpl_gtid.h
};
2️⃣ GTID 同步过程
GTID 同步流程图
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 主库事务提交 │ │ Binlog写入 │ │ 从库应用 │
│ │ │ │ │ │
│ 1. 生成GTID │───▶│ 2. 记录GTID │───▶│ 3. 读取GTID │
│ UUID:N │ │ 到Binlog │ │ 跳过重复 │
└─────────────────┘ └─────────────────┘ └─────────────────┘
3️⃣ GTID 容灾恢复
-- 启用 GTID
SET GLOBAL gtid_mode = ON;
SET GLOBAL enforce_gtid_consistency = ON;
-- 配置 GTID 复制
CHANGE MASTER TO
MASTER_HOST = 'master.example.com',
MASTER_USER = 'repl',
MASTER_PASSWORD = 'password',
MASTER_AUTO_POSITION = 1;
-- 查看 GTID 状态
SHOW MASTER STATUS;
SHOW SLAVE STATUS\G
-- GTID 恢复实验
STOP SLAVE;
RESET SLAVE ALL;
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;
START SLAVE;
🏗️ 九、Group Replication 架构深入
1️⃣ Group Replication 协议
Group Replication 使用 XCom 协议(基于 Paxos)保证一致性:
// Group Replication 消息结构
struct Group_replication_message {
uint32_t version; // 协议版本
uint32_t payload_length; // 负载长度
byte* payload; // 消息负载
// 源码路径:plugin/group_replication/libmysqlgcs/src/interface/
};
2️⃣ 写入流程详解
Group Replication 写入流程
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 事务提交 │ │ WriteSet生成 │ │ Paxos投票 │
│ │ │ │ │ │
│ 1. 本地提交 │───▶│ 2. 生成哈希签名 │───▶│ 3. 多数派确认 │
│ │ │ transaction │ │ │
│ │ │ write_set │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 冲突检测 │ │ 顺序确认 │ │ 全局提交 │
│ │ │ │ │ │
│ 4. 哈希集合比较 │ │ 5. 确定提交顺序 │ │ 6. 所有节点提交 │
└─────────────────┘ └─────────────────┘ └─────────────────┘
3️⃣ 一致性等级配置
-- 配置一致性等级
SET GLOBAL group_replication_consistency = 'BEFORE_AND_AFTER';
-- 一致性等级说明
-- EVENTUAL: 最终一致性(默认)
-- BEFORE_ON_PRIMARY_FAILOVER: 主节点故障前一致性
-- AFTER: 主节点故障后一致性
-- BEFORE_AND_AFTER: 主节点故障前后一致性
4️⃣ Group Replication 监控
-- 查看组成员状态
SELECT
CHANNEL_NAME,
MEMBER_ID,
MEMBER_HOST,
MEMBER_PORT,
MEMBER_STATE,
MEMBER_ROLE
FROM performance_schema.replication_group_members;
-- 查看组成员统计
SELECT
CHANNEL_NAME,
MEMBER_ID,
COUNT_TRANSACTIONS_IN_QUEUE,
COUNT_TRANSACTIONS_CHECKED,
COUNT_CONFLICTS_DETECTED,
COUNT_TRANSACTIONS_ROWS_VALIDATING
FROM performance_schema.replication_group_member_stats;
5️⃣ 跨机房容灾方案
方案1:同城双活 + 异地灾备
┌─────────────────────────────────────────────────────────────┐
│ 跨机房容灾架构 │
├─────────────────────────────────────────────────────────────┤
│ 机房A(北京) │ 机房B(上海) │ 机房C(深圳) │
│ ┌─────────────┐ │ ┌─────────────┐ │ ┌─────────────┐ │
│ │ Group Rep │◄───────┤ │ Group Rep │ │ │ 灾备节点 │ │
│ │ (Primary) │ │ │ (Secondary) │ │ │ (Read Only) │ │
│ └─────────────┘ │ └─────────────┘ │ └─────────────┘ │
│ │ │ │ │ │ │
│ └────────────────┼─────────┘ │ │ │
│ │ │ │ │
│ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ 应用层负载均衡 │ │ │
│ │ (读写分离 + 故障转移) │ │ │
│ └─────────────────────────────────────────────────────────┘ │ │
└─────────────────────────────────────────────────────────────┘
配置示例:
# 机房A配置
[mysqld]
server-id = 1
group_replication_local_address = "10.0.1.10:33061"
group_replication_group_seeds = "10.0.1.10:33061,10.0.2.10:33061"
# 机房B配置
[mysqld]
server-id = 2
group_replication_local_address = "10.0.2.10:33061"
group_replication_group_seeds = "10.0.1.10:33061,10.0.2.10:33061"
# 机房C配置(灾备)
[mysqld]
server-id = 3
group_replication_local_address = "10.0.3.10:33061"
group_replication_group_seeds = "10.0.1.10:33061,10.0.2.10:33061"
方案2:异地多活架构
┌─────────────────────────────────────────────────────────────┐
│ 异地多活架构 │
├─────────────────────────────────────────────────────────────┤
│ 北京机房 │ 上海机房 │ 深圳机房 │
│ ┌─────────────┐ │ ┌─────────────┐ │ ┌─────────────┐ │
│ │ Group Rep │◄─────────┤ │ Group Rep │◄─────────┤ │ Group Rep │ │
│ │ (Primary) │ │ │ (Secondary) │ │ │ (Secondary) │ │
│ └─────────────┘ │ └─────────────┘ │ └─────────────┘ │
│ │ │ │ │ │ │
│ └─────────────────┼─────────┘ │ │ │
│ │ │ │ │
│ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ 全局负载均衡 (GSLB) │ │ │
│ │ (就近访问 + 故障转移) │ │ │
│ └─────────────────────────────────────────────────────────┘ │ │
└─────────────────────────────────────────────────────────────┘
网络延迟优化:
-- 配置网络延迟容忍度
SET GLOBAL group_replication_flow_control_mode = 'QUOTA';
SET GLOBAL group_replication_flow_control_certifier_threshold = 25000;
SET GLOBAL group_replication_flow_control_applier_threshold = 25000;
-- 配置超时参数
SET GLOBAL group_replication_communication_debug_options = 'GCS_DEBUG_BASIC';
SET GLOBAL group_replication_communication_max_message_size = 10485760;
故障转移策略:
-- 自动故障转移配置
SET GLOBAL group_replication_autorejoin_tries = 3;
SET GLOBAL group_replication_autorejoin_interval = 60;
-- 手动故障转移
STOP GROUP_REPLICATION;
START GROUP_REPLICATION;
-- 检查故障转移状态
SELECT * FROM performance_schema.replication_group_members
WHERE MEMBER_STATE != 'ONLINE';
📊 十、复制性能优化实战
1️⃣ 多线程复制配置
-- 启用多线程复制
SET GLOBAL slave_parallel_workers = 4;
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';
-- 配置并行复制参数
SET GLOBAL slave_preserve_commit_order = ON;
SET GLOBAL slave_transaction_retries = 128;
2️⃣ 复制过滤优化
-- 配置复制过滤
# 主库配置
[mysqld]
binlog-do-db = mysql_learning
binlog-ignore-db = test
# 从库配置
[mysqld]
replicate-do-db = mysql_learning
replicate-ignore-db = test
replicate-wild-do-table = mysql_learning.orders_%
3️⃣ 延迟监控与告警
-- 创建复制延迟监控视图
CREATE VIEW replication_lag_monitor AS
SELECT
CHANNEL_NAME,
SOURCE_HOST,
SLAVE_LAG,
CASE
WHEN SLAVE_LAG > 300 THEN 'CRITICAL'
WHEN SLAVE_LAG > 60 THEN 'WARNING'
ELSE 'OK'
END AS status
FROM performance_schema.replication_connection_status;
-- 查询延迟状态
SELECT * FROM replication_lag_monitor;
下一章预告: 第7章:性能与存储调优 - 深入理解 MySQL 性能优化的核心技巧和实战经验。