MySQL主从复制：数据同步实战指南
MySQL 主从复制是一种数据同步机制，允许将一个 MySQL 数据库（主库）的数据复制到一个或多个 MySQL 数据库（从库）。这种机制常用于提高读取性能、实现数据备份和灾难恢复。
主从复制的工作原理
- 主库（Master）：将数据变更记录到二进制日志（binary log）
- 从库（Slave）：
- 启动一个 I/O 线程，连接主库并读取二进制日志内容，写入本地中继日志（relay log）
- 启动一个 SQL 线程，读取中继日志并执行其中的 SQL 语句，实现数据同步
配置步骤
1. 主库配置
编辑 MySQL 配置文件（my.cnf 或 my.ini）：
[mysqld]
# 启用二进制日志
log_bin = /var/log/mysql/mysql-bin.log
# 服务器唯一 ID（主从不能相同）
server-id = 1
# 需要同步的数据库（可选）
binlog_do_db = 需要同步的数据库名
# 不需要同步的数据库（可选）
binlog_ignore_db = mysql
重启主库后，创建用于复制的用户：
-- 创建复制用户
CREATE USER 'repl_user'@'从库IP' IDENTIFIED BY 'password';
-- 授予复制权限
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'从库IP';
-- 刷新权限
FLUSH PRIVILEGES;-- 查看主库状态
SHOW MASTER STATUS;
记录下 File 和 Position 的值，配置从库时需要用到。
2. 从库配置
编辑从库的 MySQL 配置文件：
[mysqld]
# 服务器唯一 ID（与主库不同）
server-id = 2
# 中继日志
relay_log = /var/log/mysql/mysql-relay-bin.log
# 只读模式（可选，提高安全性）
read_only = 1
重启从库后，配置主从关系：
-- 停止从库复制进程
STOP SLAVE;-- 配置主库信息
CHANGE MASTER TO
MASTER_HOST = '主库IP',
MASTER_USER = 'repl_user',
MASTER_PASSWORD = 'password',
MASTER_LOG_FILE = '前面记录的File值',
MASTER_LOG_POS = 前面记录的Position值;-- 启动从库复制进程
START SLAVE;-- 查看从库状态
SHOW SLAVE STATUS\G
在输出结果中，若 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes，表示主从复制配置成功。
主从复制的类型
- 异步复制：主库执行完事务后立即返回，不等待从库确认（默认方式）
- 半同步复制：主库执行完事务后，等待至少一个从库接收并写入中继日志后才返回
- 全同步复制：主库执行完事务后，等待所有从库都执行完该事务后才返回
常见问题及解决
- 复制延迟：可通过优化网络、调整从库配置或使用并行复制解决
- 复制中断：通常是由于主从数据不一致或 SQL 语句执行错误，可通过
STOP SLAVE修复后再START SLAVE - 权限问题：确保复制用户有正确的权限和网络访问权限
主从复制是 MySQL 高可用架构的基础，通过合理配置可以显著提高系统的可用性和读取性能。
mysql复制类型举例说明
MySQL 提供了多种复制类型，适用于不同的业务场景和数据一致性需求。以下是常见的复制类型及具体说明：
1. 异步复制（Asynchronous Replication）
原理：主库执行完 SQL 事务后，立即向客户端返回成功，无需等待从库确认是否已接收或执行该事务。二进制日志的传输和从库的应用是异步进行的。
举例：
- 电商网站的商品详情页查询，主库处理订单和库存更新，从库负责大量的商品信息查询。
- 主库执行
UPDATE products SET stock = 100 WHERE id = 1;后，立即返回成功给应用，无需等待从库同步。此时若主库突然宕机，可能存在已提交的事务未同步到从库的风险。
特点：
- 性能最好（主库无等待开销）
- 数据一致性最差（可能丢失数据）
- 是 MySQL 默认的复制方式
2. 半同步复制（Semi-Synchronous Replication）
原理：主库执行事务后，需等待至少一个从库将日志写入中继日志（relay log）并返回确认，才向客户端返回成功。但不等待从库执行完事务。
举例：
- 金融系统的转账业务，要求核心交易数据不能丢失。
- 主库执行
UPDATE accounts SET balance = balance - 100 WHERE user_id = 123;后，会等待从库的 I/O 线程确认已接收日志，再返回 “转账成功”。即使主库宕机，至少有一个从库保存了完整的事务日志，可避免数据丢失。
特点：
- 性能略低于异步复制（主库需等待从库确认）
- 数据一致性较高（至少一个从库有完整日志）
- 需要安装
semisync_master和semisync_slave插件启用
3. 全同步复制（Fully Synchronous Replication）
原理：主库执行事务后，必须等待所有从库都执行完该事务并返回确认，才向客户端返回成功。
举例：
- 银行核心系统的账户余额管理，要求所有节点数据实时完全一致。
- 主库执行
UPDATE balances SET amount = 5000 WHERE account_id = 456;后，需等待所有从库都执行完该更新并返回成功，才告知用户 “操作完成”。任何一个从库未完成，主库都会等待。
特点：
- 数据一致性最高（所有节点数据完全一致）
- 性能最差（主库等待时间长，受网络和从库性能影响大）
- 适用于对一致性要求极高的场景（如金融核心系统）
4. 延迟复制（Delayed Replication）
原理：从库故意延迟同步主库的日志，延迟时间可自定义（如 1 小时）。用于应对误操作（如删库）时的数据恢复。
举例：
- 运维人员误执行
DROP DATABASE db;操作，主库数据被删除。由于从库延迟 1 小时同步，可在从库还未执行该操作前，立即停止复制并恢复数据。
配置方式：
-- 从库设置延迟 3600 秒（1 小时）
CHANGE MASTER TO MASTER_DELAY = 3600;
特点：
- 本质是异步复制的变种，增加了可控的延迟时间
- 用于数据备份和灾难恢复，不能保证实时一致性
5. 并行复制（Parallel Replication）
原理：从库的 SQL 线程不再单线程执行日志，而是并行处理多个事务（按库或按事务组并行），提高同步效率。
举例：
- 高并发场景下，主库同时处理订单、支付、物流等多个库的事务。从库若使用并行复制（按库并行），可同时对
orders、payments、logistics三个库并行执行同步，减少复制延迟。
配置方式：
# 从库配置文件，设置并行复制线程数
slave_parallel_workers = 4 # 4 个并行线程
slave_parallel_type = LOGICAL_CLOCK # 按事务组并行（推荐）
特点：
- 解决单线程复制的性能瓶颈
- 适用于主库写入压力大的场景
总结
选择哪种复制类型，需在性能和数据一致性之间权衡：
- 追求高性能 → 异步复制
- 兼顾性能与安全 → 半同步复制
- 强一致性优先 → 全同步复制
- 需容错误操作 → 延迟复制
- 主库写入压力大 → 并行复制