1. MySQL主从复制基础概念
第一次接触MySQL主从复制时,我被它的设计理念深深吸引。简单来说,主从复制就是将一个MySQL服务器(主库)的数据自动同步到一个或多个MySQL服务器(从库)的过程。这种架构不仅提高了数据的可用性,还能有效分担主库的读压力。
在实际生产环境中,我们通常会遇到这样的场景:一个电商网站在大促期间,数据库查询请求暴增,单台服务器难以承受。这时主从复制的优势就显现出来了——我们可以把读操作分散到多个从库上,而写操作仍然集中在主库。这种读写分离的架构设计,让系统整体性能得到显著提升。
重要提示:主从复制虽然能提高系统可用性,但并不是严格意义上的高可用方案。因为当主库宕机时,需要人工干预才能将从库提升为主库。
2. 主从复制核心原理剖析
2.1 二进制日志(Binlog)机制
主从复制的核心在于主库的二进制日志(Binary Log)。每当我们对主库执行写操作(INSERT、UPDATE、DELETE等)时,这些操作都会被记录到Binlog中。Binlog有三种格式,每种都有其特点:
-
STATEMENT:记录SQL语句本身
- 优点:日志量小
- 缺点:某些函数(如NOW())在主从库可能产生不同结果
-
ROW:记录行数据的变化
- 优点:精确复制数据变化
- 缺点:日志量大,特别是批量操作时
-
MIXED:混合模式,默认使用STATEMENT,在特定情况下自动切换为ROW
- 优点:兼顾了日志量和准确性
- 缺点:配置相对复杂
sql复制-- 查看当前Binlog格式
SHOW VARIABLES LIKE 'binlog_format';
2.2 复制线程工作机制
主从复制涉及三个关键线程:
-
主库的Binlog Dump线程:
- 当从库连接主库时创建
- 负责将Binlog中的事件发送给从库的I/O线程
-
从库的I/O线程:
- 连接主库并请求Binlog
- 将获取的Binlog事件写入从库的relay log
-
从库的SQL线程:
- 读取relay log中的事件
- 重放这些事件,实现数据同步
sql复制-- 查看从库复制状态
SHOW SLAVE STATUS\G
3. 主从复制配置实战
3.1 主库配置
首先需要在主库的my.cnf配置文件中添加以下参数:
ini复制[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_format = ROW
sync_binlog = 1
binlog_cache_size = 4M
max_binlog_size = 1G
expire_logs_days = 7
配置完成后,需要创建用于复制的专用账号:
sql复制CREATE USER 'repl'@'%' IDENTIFIED BY 'SecurePassword123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
3.2 从库配置
从库的my.cnf配置:
ini复制[mysqld]
server-id = 2
relay_log = mysql-relay-bin
log_slave_updates = 1
read_only = ON
skip_slave_start = ON
注意:server-id必须唯一,不能与主库或其他从库重复。
3.3 建立复制关系
- 首先在主库上获取当前Binlog位置:
sql复制FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
-- 记录File和Position值
UNLOCK TABLES;
- 在从库上配置复制源:
sql复制CHANGE MASTER TO
MASTER_HOST='master_host',
MASTER_USER='repl',
MASTER_PASSWORD='SecurePassword123!',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
- 启动复制:
sql复制START SLAVE;
4. 主从复制高级特性
4.1 半同步复制
默认的异步复制存在数据丢失风险。半同步复制确保至少一个从库接收到事务后,主库才向客户端返回成功。
配置方法:
主库:
sql复制INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled = 1;
从库:
sql复制INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
4.2 多线程复制
MySQL 5.6+支持基于库的并行复制,5.7+支持基于逻辑时钟的并行复制,大幅提升复制性能。
配置示例:
sql复制STOP SLAVE;
SET GLOBAL slave_parallel_workers = 8;
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';
START SLAVE;
4.3 GTID复制
全局事务标识符(GTID)简化了复制管理和故障恢复:
sql复制-- 主从库都需要配置
gtid_mode = ON
enforce_gtid_consistency = ON
-- 从库配置复制源时使用GTID
CHANGE MASTER TO
MASTER_AUTO_POSITION = 1;
5. 常见问题排查与优化
5.1 复制延迟问题
复制延迟是常见问题,可能原因包括:
- 从库性能不足
- 网络带宽限制
- 大事务阻塞
解决方案:
sql复制-- 监控延迟
SHOW SLAVE STATUS\G
-- Seconds_Behind_Master字段显示延迟秒数
-- 优化建议
1. 升级从库硬件配置
2. 调整以下参数:
slave_parallel_workers = 8
slave_parallel_type = 'LOGICAL_CLOCK'
3. 避免在主库执行大事务
5.2 数据不一致处理
当发现主从不一致时,可以使用pt-table-checksum和pt-table-sync工具:
bash复制# 检查数据一致性
pt-table-checksum --replicate=test.checksums h=master_host
# 修复不一致数据
pt-table-sync --replicate=test.checksums h=master_host --sync-to-master
5.3 主从切换流程
计划内主从切换步骤:
- 停止主库写入
- 确保从库完全同步
- 在从库执行:
sql复制STOP SLAVE; RESET MASTER; SET GLOBAL read_only = OFF; - 修改应用连接配置
- 将原主库配置为新主库的从库
6. 生产环境最佳实践
经过多年实践,我总结了以下经验:
-
监控策略:
- 实时监控Seconds_Behind_Master
- 设置Slave_SQL_Running和Slave_IO_Running告警
- 定期检查数据一致性
-
备份策略:
- 从库是理想的备份源
- 使用mysqldump或Percona XtraBackup
- 备份前执行STOP SLAVE SQL_THREAD确保一致性
-
性能优化:
- 为从库配置足够大的relay log空间
- 调整slave_parallel_workers数量(建议CPU核心数的2-4倍)
- 使用SSD存储提升I/O性能
-
安全建议:
- 复制账号使用强密码
- 限制复制账号的访问IP
- 定期审计复制账号权限
sql复制-- 定期执行的维护命令
STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1; -- 跳过错误事件(谨慎使用)
START SLAVE;
在实际运维中,我发现很多问题都源于配置不当或监控缺失。建议至少每周检查一次复制状态,并在每次数据库变更后验证复制是否正常。主从复制虽然原理简单,但要确保长期稳定运行,需要持续的关注和优化。