Java-105 深入浅出 MySQL 主从复制详解：读写分离、高可用与半同步复制全覆盖-CSDN博客

🚀 AI篇持续更新中！（长期更新）

AI炼丹日志-31- 千呼万唤始出来 GPT-5 发布！“快的模型 + 深度思考模型 + 实时路由”，持续打造实用AI工具指南！📐🤖

💻 Java篇正式开启！（300篇）

目前2025年08月18日更新到：
Java-100 深入浅出 MySQL事务隔离级别：读未提交、已提交、可重复读与串行化
MyBatis 已完结，Spring 已完结，Nginx已完结，Tomcat已完结，分布式服务正在更新！深入浅出助你打牢基础！

📊 大数据板块已完成多项干货更新（300篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！
大数据-278 Spark MLib - 基础介绍机器学习算法梯度提升树 GBDT案例详解

请添加图片描述

主从模式

适用场景

MySQL 主从模式（Master-Slave Replication）是指数据可以从一个MySQL数据库服务器主节点复制到一个或者多个从节点的数据库架构模式。这种架构在多种场景下都有广泛应用：

1. 读写分离

主节点负责处理写操作（INSERT、UPDATE、DELETE等），而从节点可以分担读操作（SELECT）的负载。这种架构特别适用于读多写少的应用场景，如：

电商网站的浏览商品页面
新闻门户的文章阅读
社交媒体的信息流展示

2. 数据备份

从节点可以作为主节点的实时数据备份，当主节点出现故障时，可以快速切换到从节点继续提供服务。例如：

定期备份重要业务数据
金融系统的交易记录备份
医疗系统的病历数据备份

3. 数据分析

可以在不影响主库性能的情况下，使用从库进行数据分析和大数据处理。典型应用包括：

生成业务报表
运行数据挖掘算法
执行复杂的统计分析

4. 高可用性

通过配置多个从节点，可以构建高可用性系统架构。常见用例：

容灾系统
故障自动切换
多地部署

5. 特定需求复制

MySQL支持灵活的复制配置，可以：

复制所有数据库（默认配置）
只复制特定数据库（通过配置replicate-do-db参数）
只复制特定表（通过配置replicate-wild-do-table参数）

复制方式说明

MySQL默认采用异步复制方式，这种模式下：

主节点执行完事务后立即返回，不等待从节点确认
从节点通过I/O线程获取主节点的二进制日志（binlog）
从节点的SQL线程重放这些日志事件
复制延迟通常在毫秒级别

这种设计使得从节点不需要持续访问主服务器，降低了网络带宽消耗，但也可能造成短暂的数据不一致（最终一致）。对于需要强一致性的场景，可以考虑半同步复制或组复制等方案。

在这里插入图片描述

主要用途

MySQL 主从复制的核心用途及详细说明：

1. 实时灾备（高可用性保障）

故障自动切换机制：当主库出现故障时，可以快速将业务切换到从库继续提供服务，实现业务连续性
典型应用场景：
- 金融交易系统：确保交易数据不丢失
- 电商平台：避免订单处理中断
- 在线服务：保持服务24/7可用
实现方式：通常配合HAProxy、Keepalived等工具实现自动故障转移

2. 读写分离（读性能扩展）

负载均衡：将读请求分发到多个从库，减轻主库压力
典型应用场景：
- 报表系统：从从库生成报表不影响主库性能
- 大数据分析：在从库执行复杂查询
- 高并发网站：将用户浏览请求导向从库
实现方案：
- 通过中间件（如MyCat、ProxySQL）实现自动路由
- 应用层实现读写分离逻辑

3. 数据备份（业务无感知备份）

备份优势：
- 不影响主库性能：备份操作在从库执行
- 备份时间灵活：可随时对从库进行备份
- 备份一致性：从库数据与主库保持同步
备份策略：
- 物理备份：使用xtrabackup工具
- 逻辑备份：使用mysqldump
- 增量备份：基于binlog实现
典型场景：
- 定期数据归档
- 数据恢复测试
- 跨机房数据同步

4. 其他重要用途

版本升级测试：先在从库测试新版本MySQL
数据仓库构建：基于从库构建OLAP系统
地理分布式部署：在不同地区部署从库降低访问延迟

必要条件

主从部署必要条件：

网络连接要求
- 从库服务器必须能够通过TCP/IP协议访问主库服务器
- 需要确保主从服务器之间的网络延迟在可接受范围内（建议<100ms）
- 防火墙需要开放MySQL服务端口（默认3306）
主库配置要求
- 必须启用二进制日志（binlog）
  - 在my.cnf配置文件中设置：log-bin=mysql-bin
  - 建议设置binlog_format=ROW以获得最佳的数据一致性
- 建议设置sync_binlog=1以确保事务安全
- 需要创建具有复制权限的用户：
```
CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
```
服务器标识要求
- 每台MySQL服务器必须有唯一的server-id
  - 主从配置中，server-id不能相同
  - 建议设置范围：主库1，从库2,3,4…
  - 配置示例：server-id=2
- 修改server-id后需要重启MySQL服务生效
其他建议配置
- 从库建议设置read_only=ON防止误操作
- 建议配置log_slave_updates（特别是级联复制场景）
- 确保主从服务器时间同步（建议配置NTP服务）
版本兼容性
- 建议主从服务器使用相同大版本的MySQL
- 从库版本可以高于主库，但不建议主库版本高于从库
- 跨大版本复制需要特别测试兼容性

实现原理

主从复制

在这里插入图片描述

主从复制原理详解

主从复制是MySQL数据库实现数据同步的核心机制，其整体工作流程可分为以下三个关键步骤：

1. 主库Binlog日志记录阶段

主库(Master)在执行任何会修改数据的操作（如INSERT、UPDATE、DELETE等）时，会将这些变更事件按照顺序记录到二进制日志(Binary Log，简称Binlog)中
Binlog采用追加写入方式，确保事务的完整性和顺序性
典型配置示例：log-bin=mysql-bin 表示启用binlog并设置日志文件前缀

2. 从库Relay Log写入阶段

从库(Slave)的I/O Thread会建立与主库的连接，定期轮询请求新的binlog事件
主库的Binlog Dump Thread接收到请求后，读取binlog内容并发送给从库
从库I/O Thread接收到数据后，会将这些变更事件写入到本地的中继日志(Relay Log)中
网络传输采用半同步机制确保数据安全，可配置rpl_semi_sync_master_timeout等参数

3. 从库数据重放阶段

从库的SQL Thread会实时监控Relay Log的变化
解析Relay Log中的事件内容，按照事务顺序在从库上执行相同的SQL语句
执行成功后更新relay-log.info文件记录同步位置
可通过slave_parallel_workers参数配置多线程复制提高效率

核心线程功能说明

线程名称	所属服务器	主要职责
Binlog Dump Thread	Master	读取binlog内容并发送给从库
I/O Thread	Slave	接收主库binlog并写入Relay Log
SQL Thread	Slave	解析执行Relay Log中的事件

性能优化建议

主库配置sync_binlog=1确保事务安全
从库设置slave_parallel_workers=8实现并行复制
定期使用SHOW SLAVE STATUS命令监控复制延迟
对大表操作建议分批提交，避免长时间阻塞复制线程

典型应用场景

读写分离：主库处理写请求，从库处理读请求
数据备份：从库作为实时备份服务器
故障转移：主库故障时可快速提升从库为主库
数据分析：在从库执行大量统计查询不影响主库性能

上述过程都是异步操作，俗称为异步复制，存在数据延迟的现象。
在这里插入图片描述

在这种模式情况下，会出现的问题：
● 主库宕机之后，数据可能丢失
● 从库只有一个 SQL Thread，主库写压力过大，复制很可能会延时

那针对上述的问题，解决方法有：
● 半同步复制，解决数据库丢失的问题
● 并行复制，解决从库复制延迟的问题

半同步复制

半同步复制（Semi-Synchronous Replication）是 MySQL 提供的一种介于异步复制和完全同步复制之间的复制机制。它通过在主库提交事务时等待至少一个从库确认接收并写入 relay log 后才返回给客户端，从而显著降低了数据丢失的风险。

背景与原理

在传统的异步复制模式下，主库执行完事务后立即返回给客户端，而不关心从库是否已经接收并应用了这些变更。这种机制虽然性能较高，但在主库发生故障时可能会导致已提交的事务数据丢失。

半同步复制通过引入 ACK 确认机制来解决这个问题：

主库执行事务并写入二进制日志（binlog）
主库等待至少一个从库确认已接收并写入中继日志（relay log）
收到确认后，主库才完成事务提交并返回客户端响应
如果超时未收到确认，会自动降级为异步复制模式

MySQL 从 5.5 版本开始引入半同步复制插件（rpl_semi_sync_master/slave），5.7 版本后对机制进行了优化改进。

事务写入与复制流程

在启用半同步复制的情况下，主库事务写入的完整过程如下：

InnoDB Redo File Write（Prepare Write）
- 事务开始，写入 redo log（prepare 状态）
- 示例：执行 INSERT 语句时，先将数据变更写入 redo log buffer
Binlog File Flush & Sync to Binlog File
- 生成 binlog 事件并刷盘
- 通过 sync_binlog 参数控制刷盘策略
- 典型配置：sync_binlog=1 确保每次事务都刷盘
等待从库确认（半同步关键步骤）
- 主库发送 binlog 给从库
- 等待从库返回 ACK 确认（通过 rpl_semi_sync_master_timeout 设置超时时间，默认 10 秒）
- 从库需要将事件写入 relay log 并刷盘（取决于 sync_relay_log 配置）
InnoDB Redo File Commit（Commit Write）
- 收到从库确认后，提交 redo log（commit 状态）
- 此时事务才真正完成
返回客户端响应
- 向应用程序返回事务执行结果

应用场景与配置建议

典型应用场景：

金融交易系统
订单支付系统
其他对数据一致性要求较高的业务

配置建议：

# 主库配置
plugin-load = "rpl_semi_sync_master=semisync_master.so"
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_timeout = 10000 # 10秒超时

# 从库配置
plugin-load = "rpl_semi_sync_slave=semisync_slave.so"
rpl_semi_sync_slave_enabled = 1

性能考虑：

网络延迟会影响事务响应时间
建议部署在低延迟网络环境中
对于跨机房部署，需要合理设置超时时间

当Master不需要关注Slave是否接受到Binlog Event时，即为传统的主从复制。
当Master需要在第三步等待Slave返回ACK时，即为After-Commit，半同步复制（MySQL 5.5 引入）
当Master需要在第二步等待Slave返回ACK时，即为 After-Sync，增强半同步（MySQL 5.7 引入）

半同步复制时，主库等待从库写入 Relay Log并返回ACK后才进行 Engine Commit。

在这里插入图片描述