接近无线透明的灰前六十六篇，咱们从 Linux 装系统一路打到用户权限、进程、网络、Shell、服务管理，MySQL 也已经写了三篇。按系列惯例，这第 4 篇 MySQL 应该进入“让数据库真正干活”的阶段，可点开标题规划时看到，依然有不少人卡在这一步：单机 MySQL 装好了，建库建表没问题，SELECT 也会写，但产品一上线、用户一多，数据库单点扛不住，半夜扩容还要停机，这时候最常见的第一反应就是买更贵的服务器。
我的建议是先别急着上云、别急着换硬件，你要做的事是在两台 Linux 服务器上把 MySQL 主从复制完整跑通。这是从“会 MySQL 的单机操作”走向“会数据库运维”的一道分水岭。它不像索引调优那么依赖业务理解，也不像分库分表那样高不可攀，需要的只是一个干净的实验环境、两台互相能 ping 通的机器，以及你愿意把前面学过的 Linux 命令真正串起来用一次。这篇内容就适合那些已经装好 MySQL 但还没碰过主从复制的人，也适合准备面试、想理解 binlog 到底干吗用的人。我会把配置过程和踩坑记录都放出来。
1. 数据库第 4 篇为什么选“主从复制”作为主题
这套系列已经很庞大了，每一篇其实都在承担不同的技术纵深。MySQL 第 1 篇通常是安装、初始化、基本连接，第 2 篇开始讲库表操作与权限模型，第 3 篇大概率是常用的 SQL 与索引基础。到了第 4 篇，如果继续讲存储过程或者 EXPLAIN 调优，当然也有价值，但对一个“入门攻坚”系列来说，读者跟着走到这里，最缺的其实是把前面零散知识点凝聚起来的一次综合演练。
单机 MySQL 的问题，相信很多人已经能感受到：备份时只能先锁表或者用 mysqldump 停机备份，安全性存疑；写入和读取没有分离空间，连报表查询都会拖慢业务库；一旦机器故障，数据恢复依赖磁盘快照，恢复时间不可控。主从复制解决的正是这三件事里的第一层：让一份数据在另一台机器上实时存在副本。
很多人在这一步会纠结，为什么要学主从复制而不是立刻上 MGR、PXC 或者分布式数据库？我的看法是：主从复制机制是整个 MySQL 高可用体系的底座。理解 binlog，理解了 dump 线程与 IO/SQL 线程的协作，后面再看半同步复制、MGR、容器化数据库、数据同步中间件时，你会非常轻松。反过来说，如果主从复制的日志坐标和线程状态都说不清楚，直接上手那些高可用方案大概率只会变成“配完不知道发生了什么”。
实验环境上，我是用两台虚拟机做的：主库和从库都是 CentOS 7.9，MySQL 8.0.36，用二进制安装包装在没有外网的机房环境里。为了避免后面出现奇怪的 hostname 解析问题，我提前把两台机器的主机名分别改成了 mysql-master 和 mysql-slave，并在 /etc/hosts 里加了对应条目。如果你手头只有一台服务器，也可以用 Docker 起两个 MySQL 容器测试，但如果你是 Linux 新手，我更推荐老老实实准备两台虚拟机，这样你还能顺带练习网卡配置和防火墙管理，比容器方案更接近真实运维场景。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 复制链路整体认知：从主库 binlog 到从库中继日志
主从复制的完整链路，你可以把它类比成一份报纸从编辑部传到印刷厂的过程：主库是编辑部，所有新闻（写操作）都是这里定稿并记录在案（binlog）；从库的 IO 线程相当于一个勤奋的发行员，不断去编辑部取新报纸（binlog）拿回来放在自己门口的收发室（relay log）；从库的 SQL 线程则是印刷机操作员，把收发室里的报纸一份份重新印刷到自己的本地版面（从库数据）上。整个过程不是主库主动“推”给从库的，而是从库主动过来请求的。
主库要做三件事：开启 binlog 日志，这是复制的源头；设置一个全局唯一的 server-id，让每个节点都能被识别；创建一个专门用于复制的账号，给这个账号最小的 REPLICATION SLAVE 权限，而不是一上来就 GRANT ALL。这里很多新手会图省事直接给 ALL PRIVILEGES，确实也能跑通，但这是一个非常危险的习惯，复制账号理论上只需要读取主库二进制日志的权限就够了，权限给得越宽，以后被人拿去执行任意 SQL 的风险就越大。
从库其实要做的事更多。它首先要保存一个 master.info 文件（在 MySQL 8.0 里对应的是 mysql.slave_master_info 表），记录主库的 IP、端口、账号、日志文件名和偏移量；IO 线程连上主库后，主库会专门为这个连接启动一个 dump 线程，负责把 binlog 从指定位置开始一段段发给从库；从库 IO 线程收到内容后会写入 relay log（中继日志），而中继日志的落盘位置由 relay-log.info 文件记录；最后，SQL 线程负责读取 relay log 里的日志事件，并把它们逐个在从库上重放执行。
这里有一个关键点，主库的 dump 线程不是每次推完日志就断开，它会一直保持连接并等待新的 binlog 事件产生。所以当你在从库执行 START SLAVE 并看到两个线程都显示 YES 之后，哪怕主库暂时没有写入，这条 TCP 连接也一直是持续的。如果网络断掉，IO 线程会按 master_info 里记录的坐标重新连接并继续拉取，这也是主从复制能够断点续传的基础。理解这个基本模型之后，再去看配置参数就不会云里雾里了。
3. 主库配置实操：三个参数、一个账号、一份带坐标的基线数据
3.1 修改 my.cnf，把 binlog 和 server-id 打开
主库的配置文件路径一般是 /etc/my.cnf。我习惯在 [mysqld] 段下面单独加几行配置，而不是直接改原有行，方便以后一眼看出改动了什么。
ini复制[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
expire_logs_days = 7
max_binlog_size = 256M
参数含义这里要说透。server-id 是整个复制拓扑中区分节点的唯一标识，主从必须不同，取值范围 1 到 4294967295，默认是 1，如果你只在一台机器上搭复制，很容易忽略主从两台机器 server-id 撞车的问题。log-bin 不是必须写成 mysql-bin 这个固定前缀，我之所以用它，是因为日志文件的默认前缀就是 mysql-bin，产生的文件看起来像 mysql-bin.000001、mysql-bin.000002 这样，定位和排查比较直观。binlog_format 在 MySQL 8.0 里默认就是 ROW，但 5.7 及更早版本默认是 STATEMENT，我会显式再加上它，因为在复制场景中 ROW 格式最不容易出错。
为什么要强调 ROW 格式？STATEMENT 格式记录的是执行过的 SQL 原文，比如一条 UPDATE 语句在主库执行时影响了 1000 行，传到从库重放时如果表里的数据顺序或者索引状态有细微差别，可能只更新 500 行，静默丢数据。而 ROW 格式记录的是每一行实际变更前后的值，重放时按主键定位行，逐行更新，复制一致性最强。缺点就是日志体积会比 STATEMENT 大不少，但现代服务器磁盘并不缺这点空间，拿空间换一致性我觉得非常划算。
修改完配置后要重启 MySQL 服务。重启完成以后，登录 MySQL 执行下面这条命令验证 binlog 是否已经开启。
sql复制SHOW MASTER STATUS;
如果返回里有 File 和 Position 字段，说明 binlog 已经在正常工作了。这是我非常喜欢用的一条命令，它同时还会在你做基线导出时派上大用场，因为 File 和 Position 正是从库开始复制的起点坐标。
3.2 创建复制专用账号，权限宁小勿大
账号的创建逻辑看起来不复杂，但密码插件和主机范围这两处容易踩坑。MySQL 8.0 默认的认证插件是 caching_sha2_password，如果你的从库是 MySQL 5.7 或者更早版本，用老版本客户端连接时可能报认证失败，所以很多教程会顺手让你把账号改成 mysql_native_password。我的练习环境主从都是 8.0，就直接用默认插件，如果你的从库版本更低，这里就要注意版本兼容问题。
sql复制CREATE USER 'repl'@'192.168.56.%' IDENTIFIED BY 'repl_pass_2024';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.56.%';
FLUSH PRIVILEGES;
复制账号实际上只需要 REPLICATION SLAVE 权限。这个权限允许账号请求主库发送 binlog，但它不能读取普通业务表数据，也不能执行写操作。如果你用了 GRANT ALL，一旦密码泄露，攻击者可以直接在从库上 TRUNCATE 掉整张表，这个风险没有任何收益可以弥补。主机范围我写成 192.168.56.% 而不是 %，是为了限制只有内网网段的机器可以使用这个账号，减少暴露面。
3.3 锁表导出基线数据并记录 binlog 坐标
现在主库上假如已经有一份业务库 testdb，里面有一张 user 表，存了几条用户数据。主从复制要求从库起步时和主库处于同一数据状态，所以我们需要把主库当前的数据导出来，同时记录这时的 binlog 坐标，把这个坐标作为从库复制的起点。
最简单安全的做法是使用 mysqldump，并且在导出时加上 --master-data=2 参数。这个参数会在 dump 文件头部自动生成一条 CHANGE MASTER TO 语句，自动帮你标注 MASTER_LOG_FILE 和 MASTER_LOG_POS。这也是我强烈推荐的方式，比自己手动记坐标再填到从库配置里可靠得多，因为手记容易抄错数字，坐标一旦错了，从库要么重复执行旧事务，要么跳过新事务，都会引起数据不一致。
bash复制mysqldump -uroot -p --single-transaction --master-data=2 --databases testdb > /tmp/testdb_full.sql
如果你想要理解坐标到底在哪，可以打开 dump 文件看看头部，里面有这样一行：
code复制-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=157;
这就是主库当前 binlog 的文件名和偏移量。--single-transaction 是 InnoDB 表导出时保证一致性的核心选项，它利用事务的快照功能让导出期间其他会话的写入不影响备份数据，而不需要长时间锁表。很多人会好奇为什么我不加 --lock-all-tables，因为 InnoDB 引擎下 --single-transaction 已经够用了，加锁反而会让业务写入阻塞几分钟。
导出完这份基线数据之后，主库这边的操作就基本结束了。把 /tmp/testdb_full.sql 拷贝到从库机器上，接下来主力战场转移到从库。
4. 从库配置与启动复制的完整步骤
4.1 导入基线数据，重置从库自身的历史状态
从库这边首先要确保 MySQL 服务已经启动。先把从库上原有的一些无用二进制日志或者之前实验遗留的 relay log 清理干净，不然可能在启动复制时读取到旧的中继日志事件，产生无法预期的重复操作。
在执行 CHANGE MASTER TO 之前，我建议先执行一次 RESET SLAVE（MySQL 8.0 里也可以叫 RESET REPLICA）。这个命令会清掉之前残留的复制坐标和 relay log 信息。清除完再导入 dump 文件。
bash复制mysql -uroot -p < /tmp/testdb_full.sql
导入完成之后，在从库上执行 SHOW DATABASES，能看到 testdb 已经出现，user 表里的数据也都在。这时候从库数据量已经和主库当时的状态一致了，不过它还是一份静态副本：主库后续如果有什么新写入，从库现在还不会知道。
4.2 CHANGE MASTER TO 语句参数拆解
CHANGE MASTER TO 语句是启动复制前最重要的一步，很多人的配置问题都出在这一句上。我给一个可以直接用的版本：
sql复制CHANGE MASTER TO
MASTER_HOST='192.168.56.10',
MASTER_PORT=3306,
MASTER_USER='repl',
MASTER_PASSWORD='repl_pass_2024',
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=157;
MASTER_HOST 写主库 IP 我还是建议用 IP，不要用主机名。因为在有些网络环境里，主库机器上的 /etc/hosts 映射可能没同步到从库这边，会导致 IO 线程连接主库时解析不了主机名，白白多踩一个坑。MASTER_LOG_FILE 和 MASTER_LOG_POS，就是刚才 mysqldump 文件头部 CHANGE MASTER TO 注释里记录的值，必须精确抄写。如果这两个值不对，复制可以从当前位置继续，但会发生两种情况：位置填大了，主库上的部分 binlog 事件永远不会被拉取；位置填小了，从库会重放已经应用过的旧事务，在主键冲突中报错并卡住。
MySQL 8.0 里执行这句命令之后，系统会把主库连接信息和坐标写入 mysql.slave_master_info 表，而不是像 5.5 时代那样生成一个 master.info 纯文本文件。这是一个很值得知道的差异，有些老教程会让你在从库的数据目录里找 master.info 文件排查，在 8.0 里这个思路就不适用了。
4.3 启动复制并看懂状态输出
执行 START SLAVE（8.0 里也可以 START REPLICA），然后过两三秒，用 SHOW SLAVE STATUS 查看状态。这条命令输出的行非常多，初次看会有点慌，但其实你只需要盯住几个核心字段。
sql复制SHOW SLAVE STATUS\G
重点看的字段是：
- Slave_IO_Running：IO 线程是否正在连接主库并拉取 binlog。正常情况下是 Yes。如果显示 Connecting，说明从库还没连上主库，可能是网络不通、账号错误或主库没开 binlog。
- Slave_SQL_Running：SQL 线程是否正在正常执行 relay log 里的日志事件。正常情况下也是 Yes。如果显示 No，说明重放过程中有 SQL 报错，错误信息会写在 Last_SQL_Error 字段里。
- Seconds_Behind_Master：从库和主库的数据延迟秒数。刚启动时如果主库有很多未同步的写入，这个数字可能比较大，随后会降到 0，说明已经追平。
除了这三个关键指标，我还会顺手看 Last_IO_Errno 和 Last_SQL_Errno 两个字段，它们记录线程最近的错误码。很多教程不会提醒你的是：即使 Slave_IO_Running 和 Slave_SQL_Running 都显示 Yes，也不代表复制永远没问题。只要 Last_SQL_Error 里曾经出现过错误码 1062（主键冲突）之类的记录，哪怕 SQL 线程之后又通过 STOP SLAVE 和 START SLAVE 恢复起来，错误现场也已经发生了。所以初始化复制的最后一步，不要只是看一眼两个 Yes，更加稳妥的做法是去主库执行一条测试写入，然后回从库看看数据有没有同步过去。
我实测的完整验证流程是这样的：在主库执行
sql复制USE testdb;
INSERT INTO user(name) VALUES('replica_test');
然后回从库执行 SELECT * FROM user，能看到刚才插入的那行数据，说明复制链路已经通了。接下来把主库刚才插入的那条测试数据 DELETE 掉或者留着都行，对于入门实验来说留着也不影响。
5. 主从复制常见的三个“失败现场”与排查思路
5.1 认证、UUID、端口三类初级问题
第一个现场是 IO 线程报认证失败。错误信息通常类似 Authentication plugin 'caching_sha2_password' cannot be loaded，或者 Access denied for user 'repl'@'从库IP'。前者一般是从库版本过低，不支持主库账号默认的认证插件；后者要先检查账号密码是否真的正确，以及主库上授权的主机范围是否包含了从库的实际来源 IP。简单验证方法，从从库机器上直接使用 MySQL 客户端连主库：
bash复制mysql -urepl -p -h192.168.56.10 -P3306
如果这一步能登录，说明账号、密码、主机范围都没问题，接下来再排查其他方向。
第二个现场非常隐蔽，也是我自己第一次搭复制时踩过的：两台虚拟机克隆自同一个模板，导致 MySQL 数据目录里的 auto.cnf 文件产生相同内容，server-uuid 完全相同。这种复制启动失败，错误信息通常会在从库日志里出现 Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs。解决办法是删除从库数据目录下的 auto.cnf 文件，重启 MySQL 让它自动生成新的 UUID。顺便说一句，如果你是从模板克隆的虚拟机，几乎百分之百会遇到这个坑，强烈建议做完克隆之后顺手把 /var/lib/mysql/auto.cnf 删掉再启动 MySQL。
第三个现场是防火墙忘关。很多新手在虚拟机上配好主库，从库那边 IO 线程一直显示 Connecting，测了一下从库 ping 主库能通就以为网络没问题。实际上 TCP 3306 端口被 firewalld 拦住了，复制连不上去。排查命令很简单：
bash复制telnet 192.168.56.10 3306
如果通不了，先在主库上放行端口：
bash复制firewall-cmd --permanent --add-port=3306/tcp
firewall-cmd --reload
如果只是实验环境，也可以直接把两台机器的 firewalld 停掉，但真实工作中不建议这么干。
5.2 数据不一致导致的复制中断：主键冲突
第二个更常发生在“半路加入主从复制”的现场。比如主库的 testdb 里已经累积了大量数据，但你从库导入基线 dump 时导出的表少了几张，或者导出后主库还有业务写入持续进行，而你没有等 dump 完成就匆忙记录坐标，这会导致从库重放 binlog 时尝试插入的主键在主库已经存在，于是 SQL 线程报错中断，错误码通常是 1062 Duplicate entry。
排查思路是：先看 Last_SQL_Error 里的具体表名和主键值，然后去主库确认这条记录是否真实存在。确认之后，有几种处理方式。如果这个错误属于正常业务重复，且你确认主从数据可以跳过这条不一致记录，可以在从库上执行：
sql复制STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;
这样就可以跳过错的那一条 SQL，让复制继续跑。但必须说清楚，这是修复手段，不是常规操作。如果你遇到大量重复错误，每一次都跳过会掩盖主从数据不一致的本质问题，这时候不如停下复制，重新做一次完整基线导出，然后重建从库。用一句实操中的总结来概括就是：遇到 1062 不要无脑跳，先搞清不一致范围，范围小才跳过，范围大就重建。
5.3 复制链路健康检查与日常维护
主从复制搭好之后不是一劳永逸的，需要养成定期检查的习惯。我最常用的一个检查命令是：
sql复制SHOW SLAVE STATUS\G
但实际工作中不可能每天手动登录每台从库看一次。更高效的做法是用脚本或者监控工具定时采集关键字段。以下是我在一个简单脚本里用的核心逻辑：
bash复制mysql -uroot -p'密码' -e "SHOW SLAVE STATUS\G" | grep -E "Slave_IO_Running:|Slave_SQL_Running:|Seconds_Behind_Master:"
如果脚本返回的结果不是 Yes、Yes、0，就触发告警。真实生产环境的告警阈值一般会把 Seconds_Behind_Master 设置成超过 30 秒甚至 60 秒才告警，因为有时候主库瞬时大事务执行导致的延迟属于正常现象，几秒内会追平，太敏感反而容易被误报轰炸。
还有一个必须养成的习惯是关注主从库的 MySQL 版本。主库和从库的大版本最好保持一致，比如都是 8.0 系列。否则可能遇到低版本从库无法解析高版本主库新增 binlog 事件格式的情况，比如老版本从库不支持新的权限序列化格式，这会让 SQL 线程直接罢工。
6. 从主库故障到从库提升，再到复制延迟思考
6.1 主库宕机场景：从库如何临时接管业务
主从复制搭好之后，很多人会马上问一个问题：如果主库挂了，从库能自动顶上去吗？标准答案是：传统异步复制默认不能自动切换，MHA 这类工具或者 Orchestrator 才能实现自动选主和故障转移。但作为入门者，值得先手动演练一次“从库提升”，因为只有手动跑通，以后用自动化工具才不心虚。
手动提升的粗略流程是：在从库上检查 SHOW SLAVE STATUS，确认没有未执行完的中继日志（也就是 SQL 线程已经消化完 relay log），然后执行 STOP SLAVE；接着 RESET SLAVE 清掉复制元数据；再关闭只读模式（从库通常会配置 read_only=1 防止业务误写），把业务连接切换到从库上。关键是切换前要确保从库数据已经追平，否则会丢数据。检查延迟的命令还是看 Seconds_Behind_Master 是否为 0，以及 Master_Log_File 和 Relay_Master_Log_File 是否一致。
这种手动切换虽然不复杂，但它非常适合作为一次演练。它会让你对“数据零丢失”这件事产生正确的敬畏：异步复制下主库宕机那一瞬间，主库上可能还有一小部分 binlog 没有来得及发给从库，这部分数据无论怎么切换都是丢的。想要做到不丢或少丢，就得引入半同步复制或者 MySQL 8.0 的 Group Replication，这可以成为你后续深入的方向。
6.2 binlog 落盘策略与复制延迟之间的关系
复制延迟是主从架构绕不开的话题，它不像连接失败那样容易立刻感知，但会影响报表实时性和大量读请求的准确性。要理解延迟，就要看从库重放 binlog 过程中的两个瓶颈：一是单线程的 SQL 线程在 MySQL 5.6 之前只能串行执行日志事件，主库并发写入一高，从库很容易积压；二是从库刷盘参数如果设置得太保守，每次事务都要等磁盘 fsync，也会放大延迟。
MySQL 8.0 的并行复制已经可以按数据库、按事务、按写入表粒度并行执行中继日志事务，所以延迟问题比老版本好很多。但在入门环境里，我的建议是先不调那些并行复制参数，而是先确认网络和磁盘没有隐性故障，再考虑配置。有个常见误区是：把从库的 sync_binlog 从 0 改成 1 可以减少故障时的数据丢失，但代价是从库每个事务都要等待 binlog 刷盘，写入速度明显下降。实际在中小业务场景下，让从库保留默认的 sync_binlog=0，配合定期检查延迟，往往比一味追求极端一致性更务实。
6.3 从这篇实验延伸出去的下一步方向
当你在两台机器上成功跑通主从复制之后，我建议不要急着做大而全的高可用架构，而是先做一次破坏性实验：故意在主库上执行 DROP DATABASE，观察从库会不会也同步执行，答案往往是会。这说明主从复制只保证数据库内部操作的一致性，完全拦不住“人肉误操作”。如果想让这种误删可恢复，下一步要研究的就是延时复制（在从库上设置固定的 SQL 线程延迟，比如 MASTER_DELAY=3600，误操作后一小时内还能抢救）和 binlog 闪回工具。这个进阶方向比直接上复杂中间件要实用得多。
动手搭完这套复制之后，我的实际感受是，它比单纯背命令要值得多。你会真正意识到 Linux 系统知识在数据库运维里的分量：防火墙、网络、进程、日志、权限，这些“单薄的命令”在主从复制这个真实场景中第一次以组合拳的方式出现。之前学的每个知识点都变成了排查链路的一环。
最后再分享一个非常小的执行习惯，每次修改完 my.cnf，不管改的是主库还是从库，先用 mysqld --validate-config 检查一遍配置再重启。很多复制中断其实不是复制参数写错，而是配置里混入了笔误，比如少写了一个下划线，MySQL 启动时直接拒绝加载，而报错信息又藏在日志深处，找起来特费劲。先把配置验证这一步做好，能省掉后面一大堆排查时间。