MySQL高可用架构：主从复制原理与读写分离实践

咱们先来看看最核心的原理：MySQL 的主从复制，本质上就是靠二进制日志（Binlog）这张“快递单”来同步数据的。主库把每一次数据变更记录到 Binlog 里，从库则派出两个“快递员”——IO线程负责把 Binlog 取回来存成中继日志（Relay Log），SQL线程再负责把中继日志里的内容在本地“拆包重放”，完成数据同步。听起来不复杂，但这里面每一个环节的优化，都直接关系到架构的稳定性和性能表现。

整个过程依赖三个关键线程来协作，它们的配合情况就是主从复制是否健康的晴雨表：

• 主库 Dump 线程：主库会为每一个连接的从库单独启动一个线程，专门负责从 Binlog 中读取最新的事件，并发给从库。这里有个细节需要注意：读取操作会在 Binlog 上加锁，读取完毕后再释放，这样做是为了保证日志的完整性和一致性。所以，并发从库越多，主库可能面临的压力也越大。
• 从库 IO 线程：这个线程负责连接主库，不停地请求最新的 Binlog 内容，然后把接收到的数据写入本地的 Relay Log（中继日志），相当于一个搬运工。
• 从库 SQL 线程：这个线程则是负责“消化”的。它从 Relay Log 里读取事件，在从库本地进行重放（Replay），从而让从库的数据持续更新。整个复制的实时性，很大程度上取决于这个线程的执行效率。

一、核心概念体系

1.1 主从复制基础架构

-- 架构示意图
Master (主库) → Binary Log → Relay Log → Sla ve (从库)
    ↓
Write Operations          Read Operations

这个示意图很直观地解释了数据的流动方向：主库只处理写入操作（Write Operations），而从库则可以承担读操作（Read Operations），这也是读写分离架构的物理基础。

1.2 复制类型对比

谈到主从复制，很多开发者第一个纠结的问题就是：到底用哪种复制模式？市场上常见的三种模式，它们的差异主要在于数据一致性和性能之间的取舍。

市场共识是：没有完美的复制类型，只有最适合业务场景的选择。如果你做的是读写分离架构，对延迟敏感且能接受短暂的数据不一致，异步复制就足够了；如果是金融交易场景，半同步复制是行业标准；至于全同步复制，虽然能保证强一致，但代价是极高的延迟，绝大多数场景都不建议碰。

二、主从复制工作原理

2.1 二进制日志(Binlog)格式

Binlog 是整个复制逻辑的“燃料”，其格式直接影响复制效率和安全性。MySQL 提供了三种格式，选择哪一种历来有争议，但行业趋势已经非常明确。

-- 查看当前binlog格式
SHOW VARIABLES LIKE 'binlog_format';

-- 三种格式对比
-- 1. STATEMENT: 记录SQL语句
-- 2. ROW: 记录行数据变更(推荐)
-- 3. MIXED: 混合模式

可以确定的是：生产环境中，强烈推荐使用 ROW 格式。STATEMENT 格式虽然日志量小，但遇到非确定性函数、存储过程等场景时极易导致主从不一致，几乎被主流实践所淘汰。ROW格式虽然会产生更大的日志量，但换来的是精确的数据还原，这一点在故障恢复时尤为重要。

2.2 复制工作流程

配置主从复制并不复杂，但每一个参数的选择都藏着细节。我们先看看主库端怎么配。

-- Master端配置示例
-- my.cnf配置
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
expire_logs_days = 7
max_binlog_size = 100M
sync_binlog = 1

-- 创建复制用户
CREATE USER 'repl'@'%' IDENTIFIED BY 'Repl123456';
GRANT REPLICATION SLA VE ON *.* TO 'repl'@'%';

-- 查看Master状态
SHOW MASTER STATUS;
/*
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      107 |              |                  |
+------------------+----------+--------------+------------------+
*/

有一点需要特别提醒：sync_binlog = 1 这个参数虽然会带来一定的性能开销，但它是保证主库崩溃后 Binlog 不丢失的关键。同样，从库的 innodb_flush_log_at_trx_commit = 1 也要这样设置，才能构成完整的数据安全防线。

2.3 Sla ve端配置

从库端配置时，server-id 必须与主库不同，这是集群内唯一标识。同时，log_sla ve_updates 选项虽然会让从库再记录一份 Binlog，但如果你未来有级联复制（从库再同步给其他从库）的计划，这个选项务必开启。

-- my.cnf配置
[mysqld]
server-id = 2
relay-log = mysql-relay-bin
read_only = 1
log_sla ve_updates = 1

-- 配置复制链路
CHANGE MASTER TO 
    MASTER_HOST = 'master_host',
    MASTER_USER = 'repl',
    MASTER_PASSWORD = 'Repl123456',
    MASTER_PORT = 3306,
    MASTER_LOG_FILE = 'mysql-bin.000001',
    MASTER_LOG_POS = 107,
    MASTER_CONNECT_RETRY = 60,
    MASTER_HEARTBEAT_PERIOD = 10;

-- 启动复制
START SLA VE;

-- 查看复制状态
SHOW SLA VE STATUS\G
/*
Sla ve_IO_Running: Yes      # I/O线程状态
Sla ve_SQL_Running: Yes     # SQL线程状态
Seconds_Behind_Master: 0   # 复制延迟秒数
Last_IO_Error:             # 最后IO错误
Last_SQL_Error:            # 最后SQL错误
*/

配置完成后，SHOW SLA VE STATUS 就是你的“复制体检报告”。尤其是 Sla ve_IO_Running 和 Sla ve_SQL_Running 这两个字段，只要有一个不是 Yes，就意味复制链路已经中断。

三、主从延迟分析与优化

主从延迟是运维中最常遇到的问题。表面上看是 Seconds_Behind_Master 在跳动，但背后的原因可能是网络、可能是硬件、也可能是糟糕的SQL设计。要根治延迟，你得先搞清楚“病根”在哪。

3.1 延迟原因深度分析

3.1.1 硬件资源瓶颈

很多时候，延迟不是配置问题，而是机器本身扛不住了。磁盘 IO 是典型的瓶颈，尤其是当从库需要同时处理读请求和数据重放时，竞争会更加激烈。

-- 监控指标查询
-- 磁盘IO性能
SHOW GLOBAL STATUS LIKE 'Innodb_data_%';

-- 网络延迟检测
-- Master执行
SELECT NOW();
-- Sla ve执行对比时间差

-- CPU负载
SHOW PROCESSLIST;

经验表明：如果从库的磁盘 IOPS 持续接近上限，再精细的复制参数调整都是徒劳。直接升级磁盘（比如换成 NVMe SSD）往往是最立竿见影的解决方案。

3.1.2 配置参数影响

除了硬件，配置参数也会对延迟产生决定性影响。几个关键参数值得你反复确认。

-- 关键参数检查
SHOW VARIABLES LIKE '%sync_binlog%';  -- 建议=1
SHOW VARIABLES LIKE '%innodb_flush_log_at_trx_commit%'; -- 建议=1
SHOW VARIABLES LIKE '%sla ve_parallel_workers%'; -- 并行复制
SHOW VARIABLES LIKE '%sla ve_parallel_type%';    -- LOGICAL_CLOCK

必须警惕的是：很多团队在配置从库时，仍然使用单线程复制（即默认的 sla ve_parallel_workers = 0）。在主库写入量较大的情况下，单线程重放几乎必然会成为瓶颈。从 MySQL 5.7 开始，并行复制已经很成熟了，不开启它相当于浪费了从库的大半性能。

3.2 延迟监控方案

要想管理好延迟，首先要“看得见”。建立一个自动化的监控表并定时采集数据，是运维的标配动作。

-- 创建延迟监控表
CREATE TABLE replication_monitor (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    check_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    sla ve_host VARCHAR(50),
    seconds_behind_master INT,
    sla ve_io_running VARCHAR(3),
    sla ve_sql_running VARCHAR(3),
    last_io_error TEXT,
    last_sql_error TEXT,
    KEY idx_check_time (check_time)
);

-- 监控存储过程
DELIMITER $$
CREATE PROCEDURE monitor_replication_lag()
BEGIN
    DECLARE v_seconds_behind_master INT;
    DECLARE v_sla ve_io_running VARCHAR(3);
    DECLARE v_sla ve_sql_running VARCHAR(3);
    DECLARE v_last_io_error TEXT;
    DECLARE v_last_sql_error TEXT;
    
    SELECT 
        Seconds_Behind_Master,
        Sla ve_IO_Running,
        Sla ve_SQL_Running,
        Last_IO_Error,
        Last_SQL_Error
    INTO 
        v_seconds_behind_master,
        v_sla ve_io_running,
        v_sla ve_sql_running,
        v_last_io_error,
        v_last_sql_error
    FROM performance_schema.replication_applier_status_by_worker
    WHERE CHANNEL_NAME = '';
    
    INSERT INTO replication_monitor 
    (sla ve_host, seconds_behind_master, sla ve_io_running, 
     sla ve_sql_running, last_io_error, last_sql_error)
    VALUES 
    (@@hostname, v_seconds_behind_master, v_sla ve_io_running, 
     v_sla ve_sql_running, v_last_io_error, v_last_sql_error);
END$$
DELIMITER ;

-- 创建定时事件
CREATE EVENT IF NOT EXISTS monitor_replication_event
ON SCHEDULE EVERY 30 SECOND
DO CALL monitor_replication_lag();

这个方案可以每30秒记录一次复制状态，配合后续的告警，能让你在延迟超标的第一时间收到通知。

3.3 优化策略实践

3.3.1 并行复制配置

提效最快的手段之一就是开启并行复制。从 MySQL 5.7 开始，基于 LOGICAL_CLOCK 的并行方案已经够用，配置也非常直接。

-- MySQL 5.7+ 并行复制配置
STOP SLA VE;
SET GLOBAL sla ve_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL sla ve_parallel_workers = 8;  -- 根据CPU核心数调整
START SLA VE;

-- 查看并行复制状态
SHOW VARIABLES LIKE 'sla ve_parallel%';
SELECT * FROM performance_schema.replication_applier_status_by_worker;

需要注意的是，并行复制并不是万能的——它只在同一个数据库内的事务之间才能并行重放。如果你的业务把所有写入都集中到了一个库甚至一张表上，那么并行复制的作用就很有限。此时更应该考虑的是业务拆分。

3.3.2 大事务优化

大事务是复制延迟的头号杀手。一个执行了几秒甚至几十秒的事务，在主库上可能还不算什么，但在从库上，它会阻塞后续所有事务的重放，导致延迟瞬间飙升。

-- 1. 拆分大事务
-- 不推荐
START TRANSACTION;
INSERT INTO large_table SELECT * FROM huge_source; -- 百万行
COMMIT;

-- 推荐：分批提交
SET autocommit = 0;
INSERT INTO large_table SELECT * FROM huge_source LIMIT 10000;
COMMIT;
-- 循环处理...

-- 2. 使用pt-online-schema-change避免DDL锁表
-- 示例命令
pt-online-schema-change \
  --alter="ADD INDEX idx_name (name)" \
  D=test,t=large_table \
  --execute

行业共识是：任何超过10万行数据变更的单个事务，都应该被视为大事务并加以拆分。此外，DDL 操作也属于一种特殊的“大事务”，用 pt-online-schema-change（PT-OSC）这类工具来执行，可以避免锁表造成的复制阻塞。

3.3.3 网络优化配置

有时候，瓶颈出在主从之间的网络链路上。调整一些网络相关的选项能带来不小改观。

-- 增大复制缓冲区
SET GLOBAL sla ve_net_timeout = 60;  -- 默认60秒
SET GLOBAL sla ve_compressed_protocol = ON;  -- 开启压缩

-- Master端增大binlog缓存
SET GLOBAL binlog_cache_size = 4M;
SET GLOBAL max_binlog_size = 512M;

开启压缩协议会消耗额外的CPU资源，但能显著降低网络带宽占用，尤其适合跨数据中心复制场景。

四、读写分离实现方案

读写分离是主从复制的核心应用场景之一。实现方式主要分成两条路：应用层路由和中间件袋里。两条路线各有优劣，需要根据团队能力和业务需求来选。

4.1 应用层分离方案

应用层方案的优点是对SQL的掌控力极强，缺点是需要侵入业务代码。在 Ja va Spring Boot 生态中，一种常见的做法是基于注解实现动态数据源路由。

// Spring Boot + MyBatis 多数据源配置示例
@Configuration
public class DataSourceConfig {
    
    @Primary
    @Bean(name = "masterDataSource")
    @ConfigurationProperties(prefix = "spring.datasource.master")
    public DataSource masterDataSource() {
        return DataSourceBuilder.create().build();
    }
    
    @Bean(name = "sla veDataSource")
    @ConfigurationProperties(prefix = "spring.datasource.sla ve")
    public DataSource sla veDataSource() {
        return DataSourceBuilder.create().build();
    }
    
    @Bean(name = "dynamicDataSource")
    public DataSource dynamicDataSource() {
        Map targetDataSources = new HashMap<>();
        targetDataSources.put("master", masterDataSource());
        targetDataSources.put("sla ve", sla veDataSource());
        
        DynamicDataSource dynamicDataSource = new DynamicDataSource();
        dynamicDataSource.setTargetDataSources(targetDataSources);
        dynamicDataSource.setDefaultTargetDataSource(masterDataSource());
        
        return dynamicDataSource;
    }
}

// 自定义路由数据源
public class DynamicDataSource extends AbstractRoutingDataSource {
    
    @Override
    protected Object determineCurrentLookupKey() {
        // 根据注解选择数据源
        return DynamicDataSourceContextHolder.getDataSourceType();
    }
}

// 自定义注解
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DataSource {
    String value() default "master";
}

// 使用示例
@Service
public class UserService {
    
    @DataSource("master")
    public void createUser(User user) {
        // 写操作，使用主库
        userMapper.insert(user);
    }
    
    @DataSource("sla ve")
    public User getUserById(Long id) {
        // 读操作，使用从库
        return userMapper.selectById(id);
    }
}

这种注解方式的语义非常清晰——@DataSource("master") 标明写操作，@DataSource("sla ve") 标明读操作。但要注意，事务内的所有操作必须路由到主库，否则会出现“写后读不一致”的脏数据问题。

4.2 中间件方案（ProxySQL示例）

如果你不想侵入代码，或者需要更灵活的流量调度能力，中间件方案是更好的选择。ProxySQL 是目前最成熟的选择之一，配置起来也非常直观。

-- 1. 安装后配置后端服务器
INSERT INTO mysql_servers(hostgroup_id, hostname, port) 
VALUES (10, 'master_host', 3306),   -- 写组
       (20, 'sla ve1_host', 3306),   -- 读组
       (20, 'sla ve2_host', 3306);

-- 2. 配置监控用户
UPDATE global_variables SET variable_value='monitor' 
WHERE variable_name='mysql-monitor_username';
UPDATE global_variables SET variable_value='monitor_password' 
WHERE variable_name='mysql-monitor_password';

-- 3. 配置路由规则
-- 写操作路由到hostgroup 10
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply) 
VALUES (1, 1, '^INSERT', 10, 1),
       (2, 1, '^UPDATE', 10, 1),
       (3, 1, '^DELETE', 10, 1),
       (4, 1, '^SELECT.*FOR UPDATE', 10, 1);

-- 读操作路由到hostgroup 20
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply) 
VALUES (5, 1, '^SELECT', 20, 1);

-- 4. 加载配置
LOAD MYSQL SERVERS TO RUNTIME;
SA VE MYSQL SERVERS TO DISK;
LOAD MYSQL QUERY RULES TO RUNTIME;
SA VE MYSQL QUERY RULES TO DISK;

-- 5. 配置读写分离用户
INSERT INTO mysql_users(username, password, default_hostgroup) 
VALUES ('app_user', 'password', 10);

注意，SELECT...FOR UPDATE 这类读操作其实隐含了写意图，必须路由到主库，ProxySQL 的路由规则应该覆盖这种场景。

4.3 延迟感知路由

单纯的轮询或随机负载均衡，在从库延迟较大时可能导致应用读到“旧数据”。一个成熟的架构必须能够感知从库的复制延迟，并做出智能选择。

// 延迟感知的负载均衡策略
public class LagAwareLoadBalance {
    
    private List sla ves = new ArrayList<>();
    private static final int MAX_LAG_THRESHOLD = 5; // 最大允许延迟5秒
    
    public DataSource selectSla ve() {
        List a vailableSla ves = sla ves.stream()
            .filter(s -> s.getLagSeconds() <= MAX_LAG_THRESHOLD)
            .collect(Collectors.toList());
        
        if (a vailableSla ves.isEmpty()) {
            // 所有从库延迟过高，降级到主库
            return masterDataSource;
        }
        
        // 加权随机选择（延迟越低权重越高）
        return selectByWeight(a vailableSla ves);
    }
    
    private DataSource selectByWeight(List sla ves) {
        int totalWeight = sla ves.stream()
            .mapToInt(s -> calculateWeight(s.getLagSeconds()))
            .sum();
        
        int random = new Random().nextInt(totalWeight);
        int current = 0;
        
        for (Sla veInfo sla ve : sla ves) {
            current += calculateWeight(sla ve.getLagSeconds());
            if (random < current) {
                return sla ve.getDataSource();
            }
        }
        
        return sla ves.get(0).getDataSource();
    }
    
    private int calculateWeight(int lagSeconds) {
        // 延迟越低，权重越高
        return Math.max(10 - lagSeconds, 1);
    }
}

这个策略的核心在于“降级到主库”：当所有从库的延迟都超过阈值时，让读流量直接回到主库，虽然这会增加主库的压力，但至少保证了数据的实时性，而不是让用户读到过时信息。

五、故障处理与恢复

主从复制故障是运维中无法完全避免的。应对之道不在于永不故障，而在于能够快速定位和修复。

5.1 常见故障处理

下面列出了三种最典型的故障以及对应的修复流程。

-- 1. 主从复制中断
-- 查看错误信息
SHOW SLA VE STATUS\G

-- 常见错误1：主键冲突
-- 解决方案：跳过错误
STOP SLA VE;
SET GLOBAL sql_sla ve_skip_counter = 1;
START SLA VE;

-- 或指定GTID跳过
STOP SLA VE;
SET GTID_NEXT='aaa-bbb-ccc-ddd:N';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLA VE;

-- 2. 数据不一致修复
-- 使用pt-table-checksum检查
pt-table-checksum \
   --replicate=test.checksums \
   --databases=your_db \
   h=master_host,u=user,p=password

-- 使用pt-table-sync修复
pt-table-sync \
   --execute \
   --replicate test.checksums \
   h=master_host,u=user,p=password \
   h=sla ve_host,u=user,p=password

-- 3. 重新同步数据
-- 方法1：使用mysqldump
-- Master端
mysqldump --master-data=2 --single-transaction -uroot -p dbname > dbname.sql
-- Sla ve端
STOP SLA VE;
source dbname.sql;
START SLA VE;

-- 方法2：使用xtrabackup
# Master备份
xtrabackup --backup --target-dir=/backup/master/
# Sla ve恢复
xtrabackup --prepare --target-dir=/backup/master/
xtrabackup --copy-back --target-dir=/backup/master/

修复时有一个原则需要牢记：“跳过错误”只应用在你能确认该错误可以安全跳过的场景。比如主键冲突，确认主库上已经不存在该记录，偶尔的跳过是可以的。但如果频繁出现跳过，说明主从数据已经不在一套逻辑上了，必须彻底重建从库。

5.2 高可用架构

主从复制本身并不能实现高可用——因为主库宕机后不会自动切换。要实现这一点，需要借助 MHA（Master High A vailability）这类工具。

-- MHA (Master High A vailability) 配置示例
-- 1. 配置SSH免密登录
-- 2. 编辑配置文件 /etc/mha/app1.cnf
[server default]
manager_workdir=/var/log/mha/app1
manager_log=/var/log/mha/app1/manager.log
ssh_user=mysql
user=repl
password=Repl123456
repl_user=repl
repl_password=Repl123456

[server1]
hostname=master_host
candidate_master=1

[server2]
hostname=sla ve1_host
candidate_master=1

[server3]
hostname=sla ve2_host
no_master=1

-- 3. 启动MHA监控
masterha_manager --conf=/etc/mha/app1.cnf

MHA 的工作原理是监控主库的健康状态，一旦发现主库不可用，会从候选从库中选举一个并提升为新的主库，同时让其他从库指向新的主库重建复制关系。整个切换过程通常在30秒以内完成，是很多中小型团队的首选方案。

不过，随着 MySQL 8.0 的兴起源自官方推出的 InnoDB Cluster / Group Replication，MHA 的地位正在被逐渐取代。如果你的版本较新，可以直接考虑 InnoDB Cluster 方案搭建。

六、监控与告警体系

人工巡检主从状态已经不够现实了，一套完善的监控和告警体系是现代数据库运维的基础设施。

6.1 Prometheus监控配置

结合 Prometheus 和 mysqld_exporter 可以很方便地采集 MySQL 的各类指标。

# prometheus.yml 配置
scrape_configs:
  - job_name: 'mysql'
    static_configs:
      - targets: ['master_host:9104', 'sla ve1_host:9104']
    params:
      collect[]:
        - global_status
        - sla ve_status
        - info_schema.innodb_metrics

# mysqld_exporter启动
./mysqld_exporter \
   --collect.sla ve_status \
   --collect.info_schema.innodb_metrics \
   --collect.global_status \
   --web.listen-address=":9104"

6.2 Grafana监控面板

数据采集上来后，用 Grafana 面板可视化展示，能帮你一眼看出问题。

// 关键监控指标
{
  "panels": [
    {
      "title": "复制延迟",
      "targets": [{
        "expr": "mysql_sla ve_status_seconds_behind_master",
        "legendFormat": "{{instance}}"
      }],
      "thresholds": [
        {"color": "green", "value": 0},
        {"color": "yellow", "value": 5},
        {"color": "red", "value": 30}
      ]
    },
    {
      "title": "复制线程状态",
      "targets": [{
        "expr": "mysql_sla ve_status_sla ve_io_running",
        "legendFormat": "IO线程 {{instance}}"
      }]
    }
  ]
}

6.3 告警规则

有了数据和面板还不够，告警才是最后一道防线。Alertmanager 的配置示例如下。

# alertmanager配置
groups:
  - name: mysql_alerts
    rules:
      - alert: HighReplicationLag
        expr: mysql_sla ve_status_seconds_behind_master > 30
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "MySQL复制延迟过高"
          description: "实例 {{ $labels.instance }} 复制延迟已达 {{ $value }} 秒"
      
      - alert: Sla veNotRunning
        expr: mysql_sla ve_status_sla ve_io_running == 0 or mysql_sla ve_status_sla ve_sql_running == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "MySQL从库复制停止"

七、最佳实践总结

说了这么多理论和实践，最后总结一下，要构建一套稳定且高效的主从架构，有几件事一定得做到位。

7.1 配置清单

以下是主库和从库各自的标准配置清单，可以直接拿来参考。

-- 主库配置要点
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
expire_logs_days = 7
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

-- 从库配置要点
[mysqld]
server-id = 2
relay-log = mysql-relay-bin
read_only = 1
log_sla ve_updates = 1
sla ve_parallel_type = LOGICAL_CLOCK
sla ve_parallel_workers = 4

7.2 维护脚本

日常巡检最常用的是一个简单的 shell 脚本，可以定期检查复制状态并输出告警。

#!/bin/bash
# 复制状态检查脚本
check_replication() {
    local host=$1
    local user=$2
    local password=$3
    
    result=$(mysql -h$host -u$user -p$password -e "SHOW SLA VE STATUS\G")
    
    io_running=$(echo "$result" | grep "Sla ve_IO_Running" | awk '{print $2}')
    sql_running=$(echo "$result" | grep "Sla ve_SQL_Running" | awk '{print $2}')
    lag=$(echo "$result" | grep "Seconds_Behind_Master" | awk '{print $2}')
    
    if [ "$io_running" = "Yes" ] && [ "$sql_running" = "Yes" ]; then
        echo "Replication is running. Lag: ${lag} seconds"
        if [ $lag -gt 30 ]; then
            echo "WARNING: High replication lag detected!"
            return 2
        fi
        return 0
    else
        echo "ERROR: Replication is broken!"
        return 1
    fi
}

# 定期检查
while true; do
    check_replication "sla ve_host" "monitor" "password"
    sleep 60
done

7.3 性能优化检查表

最后，整理一份简明扼要的检查清单，方便你对照排查。

• 使用ROW格式的binlog
• 开启并行复制
• 合理设置innodb_buffer_pool_size
• 监控和优化慢查询
• 定期清理无用binlog
• 配置适当的网络超时时间
• 实现延迟感知的路由策略
• 建立完善的监控告警体系

结论

MySQL主从架构是企业级应用的基础架构，合理配置和优化主从复制、有效管理主从延迟、智能实现读写分离是保障系统稳定性和扩展性的三件头等大事。从基础配置到高级优化，每一步都需要结合实际业务场景做出取舍。建议根据自身业务选择合适的复制策略和读写分离方案，并建立完善的监控体系，这样才能确保数据库服务既稳定可靠，又能在需要时从容扩展。