Mysql-主从架构篇（一主多从，半同步案例搭建）

'# Mysql-主从架构篇（一主多从，半同步案例搭建）

一、背景与问题

在分布式系统中，数据库的高可用和数据一致性是核心挑战。MySQL 主从架构通过将数据从主库复制到从库，实现了读写分离、数据备份和故障转移。但传统主从复制存在两个致命问题：

主从延迟：当主库写入大量数据时，从库可能因处理不过来而产生延迟，导致读取到过期数据
数据一致性风险：当主库发生故障时，从库可能丢失未同步的数据

为了解决这些问题，MySQL 引入了半同步复制（Semisync Replication）机制。本文将深入解析主从架构原理，结合半同步技术，构建一个具备高可用性的MySQL集群。

二、基本原理

1. 主从复制核心机制

MySQL 主从复制基于二进制日志（binlog）实现，包含三个核心组件：

Binlog Server（主库）：记录所有写操作
I/O Thread（从库）：从主库获取binlog日志
SQL Thread（从库）：重放binlog日志到从库

主从复制流程

2. 半同步复制原理

半同步复制通过确认机制确保数据一致性：

主库在提交事务前，等待至少一个从库确认收到binlog
支持两种模式：
- Wait for acknowledgment（等待确认）
- Wait for timeout（超时等待）

这种机制在保证数据一致性的同时，有效减少了主从延迟。

3. 一主多从架构优势

优势	说明
读写分离	主库处理写操作，从库处理读操作
负载均衡	多从库分担查询压力
故障转移	从库可作为主库的热备
数据备份	自动同步数据到从库

三、环境准备

1. 系统要求

三台Linux服务器（推荐CentOS 7）
MySQL 5.7+ 版本（支持半同步复制）
网络互通（确保各节点之间可通信）

2. 软件安装

# 安装MySQL 5.7
wget https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-community-server-5.7.44-1.el7.x86_64.rpm
rpm -ivh mysql-community-server-5.7.44-1.el7.x86_64.rpm

# 启动MySQL服务
systemctl start mysqld

3. 配置文件准备

创建配置文件my.cnf，包含以下关键配置：

[mysqld]
server-id=1
log-bin=mysql-bin
binlog-format=ROW
binlog-row-image=FULL
sync_binlog=1
innodb_flush_log_at_trx_commit=1

# 半同步配置
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=5000
rpl_semi_sync_master_wait_for_slave_count=1

四、核心实现

1. 主库配置

-- 创建复制用户
CREATE USER 'repl'@'%' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

# 查看主库状态
SHOW MASTER STATUS;

输出示例：

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 | 154      |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

2. 从库配置

-- 配置从库
CHANGE MASTER TO
MASTER_HOST='主库IP',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;

-- 启动从库
START SLAVE;

验证从库状态：

SHOW SLAVE STATUS\G

关键字段说明：

Slave_IO_Running: Yes（表示I/O线程正常）
Slave_SQL_Running: Yes（表示SQL线程正常）
Seconds_Behind_Master: 0（表示主从同步延迟）

3. 半同步配置

-- 在主库启用半同步
SET GLOBAL rpl_semi_sync_master_enabled=1;
SET GLOBAL rpl_semi_sync_master_timeout=5000;
SET GLOBAL rpl_semi_sync_master_wait_for_slave_count=1;

-- 在从库启用半同步
SET GLOBAL rpl_semi_sync_slave_enabled=1;

验证半同步状态：

SHOW VARIABLES LIKE 'rpl_semi%';

五、完整案例

1. 架构拓扑

主库（192.168.1.100） -- 从库1（192.168.1.101） -- 从库2（192.168.1.102）

2. 配置步骤

主库配置：

[mysqld]
server-id=1
log-bin=mysql-bin
binlog-format=ROW
sync_binlog=1
innodb_flush_log_at_trx_commit=1
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=5000
rpl_semi_sync_master_wait_for_slave_count=1

从库配置（以从库1为例）：

[mysqld]
server-id=2
log-bin=mysql-bin
binlog-format=ROW
sync_binlog=1
innodb_flush_log_at_trx_commit=1
rpl_semi_sync_slave_enabled=1

验证主从同步：

-- 主库创建测试数据
CREATE DATABASE test;
USE test;
CREATE TABLE test_table (id INT PRIMARY KEY);
INSERT INTO test_table VALUES (1), (2), (3);

从库验证：

-- 从库查询数据
SELECT * FROM test.test_table;

输出结果：

+----+
| id |
+----+
|  1 |
|  2 |
|  3 |
+----+

六、源码解析

1. 主库binlog生成机制

MySQL通过binlog_format=ROW模式记录行级变更，确保从库能精确还原操作。关键代码位于server/sql/binlog.cc，主要处理：

void Binlog_log_event::write_event() {
    // 写入事件到binlog文件
    if (sync_binlog) {
        fsync();
    }
}

2. 半同步确认机制

半同步核心逻辑在plugin/semisync/semisync_slave.cc，关键函数：

void SemiSyncSlave::wait_for_ack() {
    // 等待至少一个从库确认
    while (ack_count < wait_for_slave_count) {
        sleep(1);
    }
}

3. 主从同步延迟计算

在server/sql/slave.cc中，计算延迟的代码：

void Slave_IO_Thread::run() {
    while (running) {
        if (sync_binlog) {
            // 计算主从延迟
            delay = get_delay();
        }
    }
}

七、进阶使用

1. 多从库负载均衡

通过配置read_only参数，将读操作分发到从库：

-- 主库配置
read_only=0

-- 从库配置
read_only=1

2. 故障转移方案

结合Keepalived实现自动切换：

# Keepalived配置示例
virtual_server 192.168.1.100 3306 {
    delay 5
    lb_algo roundrobin
    lb_kind active
    protocol TCP

    real_server 192.168.1.100 3306 {
        weight 100
        TCP_CHECK {
            connect_timeout 10
            retry 3
            delay 2
        }
    }

    real_server 192.168.1.101 3306 {
        weight 50
        TCP_CHECK {
            connect_timeout 10
            retry 3
            delay 2
        }
    }
}

3. 数据一致性保障

使用GTID（Global Transaction Identifier）实现精确复制：

-- 配置GTID
gtid_mode=ON
enforce_gtid_consistency=1

八、性能与工程实践

1. 性能优化策略

优化项	方法	效果
网络带宽	使用千兆网卡	降低传输延迟
磁盘IO	使用SSD	提升写入速度
内存配置	调整innodb_buffer_pool_size	提高缓存命中率
索引优化	建立合适索引	加快查询速度

2. 安全风险分析

数据泄露：从库未设置read_only可能导致数据被修改
权限管理：复制用户应仅拥有REPLICATION SLAVE权限
SSL加密：配置require_secure_transport=1防止中间人攻击

3. 性能监控指标

指标	说明	警戒线
Seconds_Behind_Master	主从延迟	> 10s
Threads_connected	连接数	> 100
Innodb_buffer_pool_read_requests	缓存命中率	< 95%

九、常见问题与踩坑

1. 主从不同步的排查

错误现象：Seconds_Behind_Master持续增大

解决办法：

检查网络是否通畅
验证主库binlog是否正常生成
检查从库SQL线程是否运行
使用SHOW PROCESSLIST查看阻塞进程

2. 半同步失效的排查

错误现象：从库未确认主库事务