HiHuo
首页
博客
手册
工具
首页
博客
手册
工具
  • 学习 MySQL

    • MySQL 深入学习手册
    • 第1章:MySQL 架构与存储引擎
    • 第2章:事务与隔离级别原理
    • 第3章:索引底层实现
    • 第4章:查询优化与执行计划
    • 第5章:存储引擎深度解析
    • 第6章:高可用与复制原理
    • 第7章:性能与存储调优
    • 第8章:MySQL 面试题大全

第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️⃣ 工作机制

  1. 主库执行事务并写入 Binlog
  2. 从库 I/O 线程请求主库 Binlog
  3. 主库 Dump 线程发送 binlog 事件
  4. 从库写入 Relay Log(中继日志)
  5. 从库 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;

📝 练习题目

基础题

  1. 什么是 Binlog?它有什么作用?
  2. 主从复制的原理是什么?有哪些类型?
  3. GTID 是什么?它解决了什么问题?

进阶题

  1. 半同步复制和异步复制的区别是什么?
  2. 如何解决主从复制延迟问题?
  3. Group Replication 和传统主从复制的区别是什么?

实战题

  1. 设计一个跨机房的高可用数据库架构
  2. 如何监控和调优主从复制性能?
  3. 在什么场景下会选择 Group Replication?

📚 扩展阅读

  • MySQL 官方文档 - 复制
  • MySQL 官方文档 - Group Replication
  • Percona Toolkit 使用指南

🔬 六、Binlog 事件类型与格式详解

深入理解 Binlog 的内部结构,这是复制和恢复的基础:

1️⃣ Binlog 事件类型

事件类型说明源码路径
QUERY_EVENTSQL 语句binlog_event.h
TABLE_MAP_EVENT表结构映射binlog_event.h
WRITE_ROWS_EVENTINSERT 操作binlog_event.h
UPDATE_ROWS_EVENTUPDATE 操作binlog_event.h
DELETE_ROWS_EVENTDELETE 操作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主库发送 BinlogMaster_Log_FileSHOW PROCESSLIST
I/O Thread从库接收 BinlogRelay_Master_Log_FileSHOW SLAVE STATUS
SQL Thread从库重放 BinlogExec_Master_Log_PosSHOW 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 性能优化的核心技巧和实战经验。

Prev
第5章:存储引擎深度解析
Next
第7章:性能与存储调优