这次我们来看 MySQL 主从同步。对于任何需要数据高可用、读写分离或负载均衡的线上业务主从架构都是最基础、最核心的解决方案之一。它不是什么新概念但能否快速、稳定地部署起来并理解其背后的运行机制是区分“会用”和“懂用”的关键。本文不绕弯子直接切入主题先讲清楚主从同步的核心原理让你明白数据是如何“流动”的然后我们会手把手完成一个“一主一从”的完整部署流程从环境准备、配置修改到同步验证每一步都给出可执行的命令和配置示例。最后我们会扩展到“一主多从”的架构并讨论其适用场景与性能观察点。无论你是为了应对面试还是为了给现有系统增加一层数据保障这篇文章都能提供一套可直接落地的操作指南。1. 核心能力速览在深入细节之前我们先通过一个表格快速了解 MySQL 主从同步的核心特性和价值这有助于你判断它是否适合解决你当前面临的问题。能力项说明与价值核心功能将主库Master的数据变更异步复制到一个或多个从库Slave。解决什么问题高可用HA主库宕机可从库快速切换。读写分离写操作走主库读操作分散到多个从库提升并发能力。数据备份从库可作为实时备份用于数据分析或灾难恢复。典型架构一主一从最简单的基础架构用于容灾备份。一主多从最常见的生产架构用于读写分离和负载均衡。多级复制适用于跨地域或网络隔离场景。硬件/环境门槛无特殊硬件要求。主从库可位于同一服务器不同端口或不同服务器。需要网络互通。同步原理基于二进制日志Binlog。主库写 Binlog从库的 I/O 线程读取SQL 线程重放。部署复杂度中等。需要理解配置参数但流程标准化按步骤操作成功率很高。是否支持“批量”天然支持。所有写入主库的操作都会自动、持续地同步到所有从库无需手动触发。监控与排错通过SHOW SLAVE STATUS\G命令可查看同步状态、延迟和错误信息易于排查。2. 适用场景与使用边界了解一个技术的最佳实践首先要明确它在哪里能发挥最大价值以及它的局限性在哪里。适合场景读多写少的应用如内容网站、电商商品页、报表系统。绝大多数请求是查询可以通过增加从库来水平扩展读能力。对数据可靠性要求较高的业务主库数据丢失风险高通过从库实现实时热备主库故障时可快速启用从库。数据分析与报表复杂的统计查询可以在从库上执行避免影响主库的线上交易性能。灰度发布与测试可以将新版本应用连接到从库进行测试或者将部分流量导入从库进行灰度验证。不适合或需谨慎使用的场景写密集型应用如果业务 90% 以上都是写操作增加从库对提升性能帮助有限反而可能因复制延迟带来复杂性问题。对数据强一致性要求极高的场景主从复制是异步的半同步复制可改善但非完全同步存在毫秒到秒级的延迟。要求“写入后立即读到”的业务需要特殊处理如读主库。网络环境极差主从库之间网络延迟高或不稳定会导致复制严重延迟甚至中断。重要边界与提醒数据安全从库拥有和主库几乎一致的数据其访问权限需同等重视防止数据从从库泄露。操作规范严禁在从库执行写操作INSERT/UPDATE/DELETE这会导致数据不一致和复制中断。版本兼容建议主从库使用相同大版本的 MySQL从库版本可以等于或高于主库版本反之可能不兼容。3. 环境准备与前置条件在开始配置之前请确保你的环境满足以下要求。我们以 Linux 环境如 CentOS 7/8, Ubuntu 20.04/22.04为例进行说明。操作系统支持主流 Linux 发行版、Windows 和 macOS。生产环境推荐 Linux。MySQL 版本本文以 MySQL 5.7 或 8.0 为例。确保主从服务器上已安装相同大版本的 MySQL。检查命令mysql --version网络互通主库和从库服务器之间需要通过 IP 地址和端口默认 3306相互访问。可以使用ping和telnet命令测试。# 在从库服务器上测试连接主库 ping 主库IP telnet 主库IP 3306服务器规划角色确定哪台服务器作主Master哪台作从Slave。本文假设有两台服务器主库192.168.1.100从库192.168.1.101数据建议在主从同步开始前主库已有部分测试数据以便验证同步效果。防火墙与SELinux确保防火墙开放了 MySQL 端口默认3306或临时关闭防火墙进行测试。SELinux 也可能阻止访问可设置为 permissive 模式。# CentOS 7/8 防火墙 sudo firewall-cmd --add-port3306/tcp --permanent sudo firewall-cmd --reload # 或临时关闭测试环境 sudo systemctl stop firewalld # 查看SELinux状态 getenforce # 临时设置为 permissive sudo setenforce 04. 主库Master配置与操作配置的第一步是设置主库告诉它“你需要开启日志并允许一个从库来连接你拉取数据。”4.1 修改主库配置文件编辑 MySQL 配置文件通常是/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf在[mysqld]段落下添加或修改以下参数[mysqld] # 启用二进制日志这是复制的基石 log-binmysql-bin # 设置服务器唯一ID主从不能相同 server-id100 # 可选指定需要复制的数据库多个则写多行不指定则默认复制所有库 # binlog-do-dbtest_db # 可选指定不需要复制的数据库 # binlog-ignore-dbmysql # binlog-ignore-dbinformation_schema # binlog-ignore-dbperformance_schema # binlog-ignore-dbsys关键参数解释log-bin二进制日志文件的前缀。开启后所有数据变更操作都会记录在此类日志中。server-id整个主从复制集群中每个节点的唯一标识必须是一个正整数。4.2 重启主库 MySQL 服务修改配置后需要重启 MySQL 服务使配置生效。sudo systemctl restart mysqld # 或 sudo systemctl restart mysql (Ubuntu)4.3 创建用于复制的专用账户为了安全我们创建一个仅用于复制权限的账户而不是直接使用 root。 登录主库 MySQLmysql -u root -p执行以下 SQL-- 创建一个用户名为 repl允许从 192.168.1.101从库IP登录的用户密码为 Repl123456 CREATE USER repl192.168.1.101 IDENTIFIED BY Repl123456; -- 授予该用户复制所需的权限 GRANT REPLICATION SLAVE ON *.* TO repl192.168.1.101; -- 刷新权限 FLUSH PRIVILEGES;4.4 查看主库状态并记录关键信息在主库执行以下命令记录下File和Position的值从库配置时需要用到。SHOW MASTER STATUS\G输出示例*************************** 1. row *************************** File: mysql-bin.000001 Position: 154 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set:请记下File: mysql-bin.000001和Position: 154。你的实际值可能不同。至此主库的配置就完成了。主库现在正在记录二进制日志并等待从库连接。5. 从库Slave配置与操作现在配置从库告诉它“你的数据源是哪个主库从哪里开始同步。”5.1 修改从库配置文件编辑从库的 MySQL 配置文件同样在[mysqld]段落下修改[mysqld] # 从库也需要 server-id且必须与主库不同 server-id101 # 可选开启中继日志从库I/O线程从主库拉取的日志会先存到这里 relay-logmysql-relay-bin # 可选防止从库被意外写入只读模式但复制线程的写入不受影响 read-onlyON5.2 重启从库 MySQL 服务sudo systemctl restart mysqld5.3 配置从库复制源登录从库 MySQLmysql -u root -p执行以下 SQL 命令指定主库信息。请将下面命令中的参数替换为你实际的环境信息-- 停止从库复制线程如果是首次配置它们本来就是停止的 STOP SLAVE; -- 配置主库连接信息 CHANGE MASTER TO MASTER_HOST192.168.1.100, -- 主库IP MASTER_USERrepl, -- 主库创建的复制账号 MASTER_PASSWORDRepl123456, -- 复制账号密码 MASTER_LOG_FILEmysql-bin.000001, -- 主库 SHOW MASTER STATUS 看到的 File MASTER_LOG_POS154; -- 主库 SHOW MASTER STATUS 看到的 Position -- 启动从库复制线程 START SLAVE;5.4 检查从库复制状态这是验证配置是否成功的关键一步。在从库执行SHOW SLAVE STATUS\G重点关注以下字段Slave_IO_Running:必须为Yes。表示 I/O 线程负责从主库拉取日志运行正常。Slave_SQL_Running:必须为Yes。表示 SQL 线程负责重放日志运行正常。Last_IO_Error: 如果Slave_IO_Running为No这里会显示 I/O 线程的错误信息。Last_SQL_Error: 如果Slave_SQL_Running为No这里会显示 SQL 线程的错误信息。Seconds_Behind_Master: 从库落后于主库的秒数。0表示完全同步非0表示有延迟。如果Slave_IO_Running和Slave_SQL_Running都是Yes并且Seconds_Behind_Master逐渐变为0恭喜你一主一从同步已经搭建成功6. 功能测试与同步验证配置好了必须进行测试来验证数据同步是否真的在工作。6.1 基础同步测试在主库操作-- 在主库创建一个测试数据库和表 CREATE DATABASE IF NOT EXISTS test_sync; USE test_sync; CREATE TABLE user ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- 插入一条数据 INSERT INTO user (name) VALUES (Master_User_1);在从库验证-- 在从库查看数据库和表是否同步过来 SHOW DATABASES LIKE test_sync; USE test_sync; SELECT * FROM user;如果能在从库查询到test_sync数据库和user表中的数据说明结构和数据同步成功。6.2 持续增量同步测试在主库继续写入USE test_sync; INSERT INTO user (name) VALUES (Master_User_2), (Master_User_3); UPDATE user SET name CONCAT(name, _Updated) WHERE id 1; DELETE FROM user WHERE id 2;在从库观察USE test_sync; SELECT * FROM user ORDER BY id;观察从库的数据是否实时或有短暂延迟后与主库保持一致。UPDATE和DELETE操作也应该被正确同步。6.3 同步延迟观察在从库反复执行SHOW SLAVE STATUS\G观察Seconds_Behind_Master字段的变化。在低负载下它应该很快变为0。你可以故意在主库执行一个耗时操作如一个大表更新观察这个值的变化。7. 扩展至一主多从架构一主一从是基础一主多从才是应对高并发读场景的典型生产架构。配置逻辑与一主一从完全一致只是需要重复“从库配置”的步骤。架构示意图---------------- | 主库 (Master) | | 192.168.1.100 | --------------- | -------------------------------- | | --------v------- ---------v--------- | 从库1 (Slave1) | | 从库2 (Slave2) | | 192.168.1.101 | | 192.168.1.102 | ----------------- ------------------操作步骤主库配置与一主一从完全相同。主库的binlog会发送给所有连接的从库。从库1配置已完成即上一章的从库。从库2配置在从库2服务器上安装相同版本的 MySQL。修改其my.cnf设置server-id102确保与主库、从库1都不同。重启 MySQL。登录从库2的 MySQL使用CHANGE MASTER TO命令指向同一个主库192.168.1.100使用同一个复制账号repl。注意MASTER_LOG_FILE和MASTER_LOG_POS需要重新从主库的SHOW MASTER STATUS获取当前值。如果从库2是在主库已有数据后加入你需要先使用mysqldump或xtrabackup工具将主库现有数据导出并导入到从库2保证起点一致否则会报错。这是一个关键点。一主多从的优势读性能线性扩展应用可以将读请求随机或按规则分发到多个从库。更高可用性一个从库宕机不影响其他从库提供服务。专用化从库可以针对不同从库配置不同索引或存储引擎用于不同业务如一个用于报表一个用于线上查询。8. 资源占用与性能观察主从复制本身对资源的消耗是可控的但需要关注以下几点主库性能影响I/O 压力开启binlog会增加磁盘写入。建议将binlog放在高性能磁盘如 SSD上。网络压力每个从库都会与主库建立一个连接拉取binlog。从库越多主库的网络出口带宽消耗越大。观察命令在主库使用SHOW PROCESSLIST;可以看到每个从库的连接Command列为Binlog Dump。从库性能影响SQL 线程重放从库需要执行主库执行过的所有写操作。如果主库写负载极高从库的 SQL 线程可能成为瓶颈导致延迟增大。资源争用如果从库也承担大量读请求可能会与 SQL 重放线程竞争 CPU、内存和 I/O 资源。观察命令在从库使用SHOW SLAVE STATUS\G看Seconds_Behind_Master和Slave_SQL_Running_State。网络带宽确保主从库之间的网络带宽足够尤其是当主库产生大量binlog例如批量数据导入时。9. 常见问题与排查方法部署和运行过程中难免会遇到问题。下表列出了常见问题及排查思路。问题现象可能原因排查方式解决方案Slave_IO_Running: Connecting从库无法连接主库。1. 检查网络ping 主库IP2. 检查端口telnet 主库IP 33063. 检查主库防火墙/SELinux。4. 检查CHANGE MASTER TO中的 IP、端口、用户名、密码是否正确。解决网络问题修正配置信息。Slave_IO_Running: YesSlave_SQL_Running: NoSQL 线程执行binlog事件时出错例如从库上已存在同名的表或数据冲突。查看SHOW SLAVE STATUS\G中的Last_SQL_Error字段。根据错误信息处理。常见方法是跳过这个错误事件谨慎使用STOP SLAVE;SET GLOBAL SQL_SLAVE_SKIP_COUNTER 1;START SLAVE;Last_IO_Error: error reconnecting to master网络闪断或主库重启后从库重连失败。查看错误详情检查主库服务是否正常网络是否恢复。通常网络恢复后会自动重连。也可手动STOP SLAVE; START SLAVE;。Seconds_Behind_Master延迟很大且不减少从库 SQL 线程重放速度跟不上主库写入速度。1. 检查从库服务器负载CPU、IO、内存。2. 检查是否有慢查询在从库上运行。1. 优化从库硬件或减少其读负载。2. 优化主库的写SQL减少binlog量。3. 考虑使用多线程复制MySQL 5.6。从库数据与主库不一致可能在从库上进行了手动写操作。检查从库的read-only配置是否生效以及是否有其他客户端进行了写操作。1. 确保从库配置read-onlyON。2. 重建复制锁定主库用mysqldump全量导出导入从库重新配置CHANGE MASTER TO。主库binlog文件增长过快写操作频繁或未定期清理旧binlog。SHOW BINARY LOGS;查看日志文件列表。设置expire_logs_days参数自动清理过期日志如7天SET GLOBAL expire_logs_days 7;并写入配置文件。10. 最佳实践与使用建议为了让你的主从复制架构更稳定、高效请遵循以下建议监控常态化将SHOW SLAVE STATUS的关键指标IO/SQL线程状态、延迟秒数纳入监控系统如 Prometheus Grafana设置告警。定期备份不要认为有了从库就高枕无忧。依然需要定期对主库或从库进行物理或逻辑备份。版本一致性生产环境尽量保证主从 MySQL 版本完全一致避免因版本差异导致的复制异常。参数优化sync_binlog主库上设置为1保证每次事务提交都同步刷盘binlog数据更安全但性能略有下降。innodb_flush_log_at_trx_commit主库上设置为1保证 ACID。relay_log_recovery从库上设置为ON确保从库崩溃后能安全恢复中继日志。一主多从下的读负载均衡在应用层或使用中间件如 MyCat、ProxySQL、MySQL Router实现读请求的自动分发和故障转移。高可用方案一主多从解决了读的高可用但主库仍是单点。需要进一步考虑主库的高可用例如基于主从复制构建 MHAMaster High Availability或使用 MGRMySQL Group Replication等方案。变更管理任何涉及表结构变更DDL的操作在主库执行时需格外小心因为某些 DDL 可能导致复制延迟激增或中断。建议在业务低峰期进行并监控复制状态。MySQL 主从复制是一个经典且强大的功能理解其原理并能熟练部署是后端和 DBA 的必备技能。从一主一从开始逐步掌握状态监控、故障排查和性能调优你就能为构建更健壮的数据服务层打下坚实基础。建议你在测试环境中反复练习整个流程直到能独立、流畅地完成搭建和验证再应用到生产环境。