Mysql 主从复制、读写分离

graph LR
    A[Master] -->|1. 写入操作| B[Binary Log]
    B -->|2. 推送日志| C[Slave I/O Thread]
    C -->|3. 保存日志| D[Relay Log]
    D -->|4. 重放操作| E[Slave SQL Thread]
    E --> F[Slave 数据同步完成]

3. 关键特性

（1）异步复制（Asynchronous）

默认模式下，主节点提交事务后无需等待从节点确认，可能产生短暂延迟（毫秒级）。

（2）数据一致性

最终一致性：从节点数据最终与主节点一致。
强一致性需求：可通过半同步复制（Semi-Synchronous）或同步复制实现。

4. 应用场景

读写分离：将读请求分发到从节点，减轻主节点压力。
数据备份：从节点作为实时备份。
高可用：主节点故障时，从节点可切换为主节点（需配合哨兵或集群管理工具）。

5. 注意事项

延迟风险：网络波动或从节点负载过高可能导致数据延迟。
版本兼容：主从节点的数据库版本需兼容。
日志格式 ：需确保二进制日志格式（如ROW/STATEMENT）一致。

二、MySQL主从复制的工作过程

1. 主库（Master）操作

二进制日志（Binlog）记录

主库将所有数据修改操作（如INSERT、UPDATE、DELETE）以事件形式记录到二进制日志文件中。

日志格式支持：
- Statement-based：记录SQL语句
- Row-based：记录每行数据的变化
- Mixed：混合模式
Binlog Dump线程

当从库连接时，主库启动一个Binlog Dump线程，负责读取并发送Binlog内容到从库。

2. 从库（Slave）操作

I/O线程

从库的I/O线程连接主库：
1. 请求指定位置的Binlog内容
2. 接收数据并写入本地Relay Log（中继日志）
SQL线程

从库的SQL线程读取Relay Log：
1. 解析日志中的事件
2. 按顺序重放（执行）这些事件，实现数据同步

3. 复制流程示意图

plaintext 复制代码

主库
  │ 1. 数据修改写入Binlog
  │ 2. Binlog Dump线程发送日志
  ↓
从库
  │ 3. I/O线程接收日志→写入Relay Log
  │ 4. SQL线程重放Relay Log→更新数据

4. 关键配置参数

6. 典型应用场景

主库配置
ini 复制代码
```
server-id=1
log-bin=mysql-bin
 
```

从库配置

ini 复制代码

server-id=2
relay-log=mysql-relay
replicate-do-db=指定数据库

5. 数据一致性保障

GTID模式（Global Transaction Identifier）

通过全局唯一事务ID追踪复制进度，确保事务顺序一致。 $$ \text{GTID} = \text{server_uuid}:\text{transaction_id} $$
半同步复制（Semisynchronous）

主库需等待至少一个从库确认接收Binlog后才返回成功响应。
读写分离：主库写，从库读
数据备份：从库作为热备节点
故障转移：主库宕机时切换至从库

四、主从复制实验

实验环境配置

系统环境

操作系统：CentOS 7.9
虚拟机平台：VMware/KVM（需确保三台服务器网络互通）
MySQL版本：5.7（三台服务器版本必须完全一致）

服务器信息

角色	IP地址	主机名（示例）
Master	192.168.100.249	master-node
Slave1	192.168.100.248	slave1-node
Slave2	192.168.100.247	slave2-node

关键配置步骤

1. Master服务器配置

bash 复制代码

# 编辑MySQL配置文件
vi /etc/my.cnf

[mysqld]
server-id = 1                 # 唯一ID（主库设为1）
log-bin = mysql-bin           # 开启二进制日志
binlog_format = ROW            # 推荐使用ROW模式
binlog-do-db = test_db         # 需同步的数据库（可选）

2. Slave服务器配置

bash 复制代码

# Slave1配置（Slave2同理修改server-id）
vi /etc/my.cnf

[mysqld]
server-id = 2                 # Slave1设为2，Slave2设为3（不可重复）
relay-log = relay-log         # 开启中继日志
read_only = ON                # 从库只读模式（建议）

3. 创建复制账户（Master执行）

sql 复制代码

CREATE USER 'repl'@'192.168.100.%' IDENTIFIED BY 'ReplPass123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.100.%';
FLUSH PRIVILEGES;

4. 启动复制链路（Slave执行）

sql 复制代码

CHANGE MASTER TO
MASTER_HOST = '192.168.100.249',
MASTER_USER = 'repl',
MASTER_PASSWORD = 'ReplPass123!',
MASTER_LOG_FILE = 'mysql-bin.000001', -- 通过SHOW MASTER STATUS获取
MASTER_LOG_POS = 154;                 -- 同上

验证命令

sql 复制代码

-- 在Master查看状态
SHOW MASTER STATUS;

-- 在Slave启动复制
START SLAVE;
SHOW SLAVE STATUS\G

-- 关键指标检查
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

注意事项

防火墙配置

bash 复制代码

firewall-cmd --permanent --add-service=mysql
firewall-cmd --reload

时间同步
使用ntpdate确保三台服务器时间一致：
bash 复制代码
```
ntpdate ntp.aliyun.com
 
```
GTID模式（可选）

若启用GTID，需在配置文件中添加：
ini 复制代码
```
gtid_mode = ON
enforce_gtid_consistency = ON
 
```
建议操作 ：配置完成后，在Master创建测试数据库test_db并插入数据，观察Slave是否实时同步。通过STOP SLAVE/START SLAVE模拟故障切换场景以验证高可用性。

五、MySQL读写分离

1.概述

MySQL读写分离是一种数据库架构优化策略，通过将读操作和写操作分发到不同的数据库服务器上，以提高系统整体性能和可用性。写操作通常集中在主库（Master），而读操作分散到多个从库（Slave），从而减轻主库负载并提升查询效率。

2.实现原理

主库负责处理所有写操作（INSERT、UPDATE、DELETE等），并通过二进制日志（binlog）记录数据变更。从库通过复制主库的binlog实现数据同步，确保数据一致性。应用程序通过中间件或代码逻辑将读请求路由到从库，写请求路由到主库。

核心组件与技术

主从复制（Replication）：MySQL原生支持的主从同步机制，从库通过IO线程拉取主库的binlog，SQL线程重放日志实现数据同步。
GTID（全局事务标识）：MySQL 5.6引入的机制，为每个事务分配唯一ID，简化主从切换和故障恢复流程。
半同步复制（Semi-Synchronous Replication）：确保至少一个从库接收并写入relay log后，主库才提交事务，增强数据安全性。

3.配置步骤

主库配置（my.cnf）

ini 复制代码

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

从库配置（my.cnf）

ini 复制代码

[mysqld]
server-id=2
relay-log=mysql-relay-bin
read_only=1

主库创建复制账号

sql 复制代码

CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

从库启动复制

sql 复制代码

CHANGE MASTER TO
MASTER_HOST='master_ip',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
START SLAVE;

4.读写分离实现方式

1. 应用层实现 在代码中直接区分读写数据源，例如Spring框架通过AbstractRoutingDataSource实现动态数据源切换。

2. 中间件方案

ProxySQL：高性能代理，支持查询规则路由、连接池管理。
MySQL Router：官方轻量级中间件，支持读写分离和故障转移。
ShardingSphere-JDBC：国产开源生态，集成读写分离与分库分表。

5.性能优化建议

从库数量根据读负载动态扩展，避免过度复制导致主库压力。
监控复制延迟（Seconds_Behind_Master），确保从库数据及时性。
对一致性要求高的读操作可强制走主库（如SELECT ... FOR UPDATE）。

总结

MySQL主从复制与读写分离实现了：

性能质变 ：通过读写分离策略，系统吞吐量提升可建模为： $T_{\\text{总}} = T_{\\text{写}} + \\sum_{i=1}\^{n} T_{\\text{读}*i}$ 其中 $n$ 为从节点数量， $T*{\\text{写}}$ 由主节点承担
故障容灾：主节点故障时，从节点可快速切换为新的主节点
数据一致性：基于binlog的异步复制机制保证最终一致性

实际部署需注意：

主从延迟监控（如Seconds_Behind_Master指标）
写后立即读的场景需路由至主节点
从节点水平扩展的硬件成本平衡

该架构以较低复杂度显著提升了数据库系统的可用性与扩展性。

Mysql 主从复制、读写分离

前言

一、主从复制原理

1. 基础架构

2. 核心流程

（1）主节点记录变更

（2）从节点同步日志

（3）从节点重放日志

3. 关键特性

（1）异步复制（Asynchronous）

（2）数据一致性

4. 应用场景

5. 注意事项

二、MySQL****主从复制的工作过程

1. 主库（Master）操作

2. 从库（Slave）操作

3. 复制流程示意图

4. 关键配置参数

6. 典型应用场景

5. 数据一致性保障

四、主从复制实验

实验环境配置

关键配置步骤

1. Master服务器配置

2. Slave服务器配置

3. 创建复制账户（Master执行）

4. 启动复制链路（Slave执行）

验证命令

注意事项

五、MySQL****读写分离

1.概述

2.实现原理

核心组件与技术

3.配置步骤

4.读写分离实现方式

5.性能优化建议

总结

二、MySQL主从复制的工作过程

五、MySQL读写分离