小xs凌晨两点半，我被值班电话叫醒，业务方说订单表的主库磁盘快满了，想清理binlog。我第一反应是拦住——那台机器上有三个从库正在通过binlog拉取数据，直接删文件等于给复制线程断粮。后来确认了一下，从库的IO线程确实已经因为找不到binlog报错了，业务侧倒是没感知，但主从链路已经挂了。这就是MySQL复制最典型的场景：它不复杂，但坑特别多，尤其是你没搞懂底层原理就上手操作的时候。
这篇文章围绕MySQL复制这个知识点，把binlog、复制线程、主从配置、延迟排查、故障切换这些核心内容系统过一遍。不管你是准备面试的开发者，还是已经在维护线上库的DBA，按这个思路走一遍，至少能在脑子里形成一张完整的地图。知道复制是怎么跑的、延迟是怎么来的、切换该怎么动手，比背一堆参数有用得多。
1. 复制到底在做什么：先搞懂binlog和复制架构
1.1 binlog是复制的源头，日志格式决定一切
MySQL复制的起点不是网络协议，也不是什么神秘的同步机制，就是binlog。主库把自己的数据变更写到binlog，从库拉走这些日志，在自己本地重放一遍，数据就"复制"过去了。所以理解复制，第一步就是理解binlog。
binlog有三种格式：STATEMENT、ROW、MIXED。这个选择直接影响复制的正确性。
STATEMENT格式记录的是SQL语句本身。比如主库执行了UPDATE t SET name='张三' WHERE id=1，binlog里就存这条SQL，从库拿到后原样执行一遍。优点很明显：日志量小，一条语句可能只改一行，但记录的字节数很少。缺点也很致命：如果SQL里带了NOW()、UUID()这种非确定性函数，主库执行结果和从库执行结果很可能不一样。比如INSERT INTO t VALUES(NOW())，主库写入的是执行时刻的时间，从库因为延迟，执行时时间已经变了，两边数据就对不上。类似的还有LIMIT不带ORDER BY的更新，语义不确定，主从执行顺序一乱，结果完全不同。
ROW格式则记录每一行的实际变化。还是刚才那条UPDATE，ROW格式会在binlog里记录"id=1的这行，name从什么变成了'张三'"。从库拿到的是确定性的变更结果，绝对不会因为函数或者执行顺序产生偏差。这也是为什么MySQL 8.0默认就是ROW格式，也是为什么我强烈建议生产环境用ROW——它对数据一致性最有保障。代价就是日志量变大，尤其大批量UPDATE时，binlog会明显膨胀。
MIXED格式是MySQL自己做判断：默认用STATEMENT，一旦发现语句中有非确定性因素，自动切成ROW记录。看上去很聪明，但实际运维中，你很难预测一条SQL到底会以哪种格式落盘，排查问题时日志格式不统一会增加工作量。
提示：如果你还在用STATEMENT格式，建议尽早评估切到ROW。我用ROW格式六年，主从不一致的问题几乎绝迹，代价只是多花点磁盘空间，完全值得。
1.2 从库的IO线程和SQL线程，各司其职
很多人以为复制是主库主动推数据到从库，其实方向正好相反。从库是主动拉数据的。这套拉取机制靠三个线程配合：
主库侧有Binlog Dump线程，每个从库连上来，主库就会为它开一个独立的Dump线程，负责把binlog推给从库。从库侧有两个线程：IO线程和SQL线程（在MySQL 8.0里称为Replica IO线程和Replica SQL线程）。
IO线程负责连上主库，接收binlog，然后写到从库本地的relay log（中继日志）。注意，这个阶段只是把日志"搬"过来，不执行任何SQL。SQL线程负责读取relay log，逐条执行里面的内容，让数据变化在从库生效。
为什么中间要隔一层relay log？这是很巧妙的设计。IO线程和SQL线程是异步解耦的，网络再快，也不如本地文件读得快。主库爆发出大量写入时，IO线程可以先把binlog全部搬到从库的relay log里，SQL线程慢慢追。这样即使SQL线程执行慢，只要relay log还在，数据就不会丢，IO线程也不至于被拖住。MySQL 8.0之后，还引入了多线程复制，SQL线程会变成协调线程加多个worker线程，并行执行日志内容，这个后面展开说。
1.3 复制拓扑：一主一从、级联、双主怎么选
复制拓扑决定了你的系统架构形态。最常见的是一主一从或一主多从，主库承担写入，从库分流读请求或者做备份。这种模式最简单，但主库单点风险依然存在，所以有了主从切换方案，后面会讲。
级联复制就是A主库复制到B从库，B同时作为C、D的主库。这种结构适合跨机房场景：A在机房1，B在机房2，C和D跟B同机房，这样C和D就不用穿越网络去机房1拉日志，延迟更低。代价是链路变长，任何一个中间环节出问题，下游全断。
双主复制则是两台库互相复制。A写入的数据同步到B，B写入的数据也同步到A。这种结构可以用来做快速切换，但最大的坑是自增主键冲突：如果两边同时对同一张表插入数据，id可能重复，复制就会报主键冲突然后中断。处理办法一般是通过设置不同的自增值偏移量，比如A的auto_increment_offset=1, auto_increment_increment=2，B设为offset=2, increment=2，让id奇偶分开。但这只解决了自增字段的问题，业务层面的更新冲突依然存在，所以双主架构一般还是会让写流量只走一边，另一边纯粹用于容灾。
拓扑没有绝对的好坏，只有适不适合你的业务。我的建议是：跨机房用级联，容灾用双主或一主一从，但任何复杂的拓扑都比不上一个清晰的切换流程和定期的演练。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从零搭一套能上生产的主从复制
2.1 环境规划与初始化，有些参数必须在启动前定好
搭建复制不是跑两条命令就完事，很多参数在初始化时就定好了，后面再改非常麻烦。
首先是server_id，这是节点在复制拓扑里的唯一标识，集群里绝对不能重复。我见过有人两台机器都配成1，结果从库的IO线程反复被踢掉，检查了半小时才发现是server_id冲突。
然后是log_bin，主库必须开启binlog，否则复制无从谈起。从库一般也建议开启，因为从库以后可能成为新主库，或者下面还挂着别的从库。8.0默认log_bin=ON，但如果是从老版本升级过来的，要确认一下。
还有一些跟数据安全相关的参数：sync_binlog=1表示每次事务提交都把binlog刷到磁盘，innodb_flush_log_at_trx_commit=1表示每次提交都把redo log刷盘。这两个参数就是大家常说的"双1"，配合起来能最大程度保证主库宕机时binlog和InnoDB数据不丢。代价是性能下降，尤其在高并发写场景，但复制场景下这个代价值得付。
binlog_format=ROW、binlog_expire_logs_seconds（binlog保留时间，建议14400秒以上，具体看磁盘容量和从库延迟情况）、gtid_mode=ON和enforce_gtid_consistency=ON也要在初始化时配置好。GTID相关参数后面单独讲。
从库还有个关键参数read_only=ON。从库必须只读，业务写入全走主库，否则双向写导致的数据冲突会让你怀疑人生。注意read_only对超级管理员账号不生效，所以super_read_only=ON也建议一起开，防止有人用超级账号偷偷写从库。
2.2 主库备份和change master实操
搭建复制最正统的流程是：先对主库做一次全量备份，恢复到从库，然后指定从哪个binlog位点开始追。手动操作大致是：
在主库上执行SHOW MASTER STATUS\G记下当前的File和Position。然后用mysqldump或xtrabackup做全量备份，恢复到从库。接下来在从库上执行：
sql复制CHANGE MASTER TO
MASTER_HOST='10.0.0.1',
MASTER_USER='repl',
MASTER_PASSWORD='yourpass',
MASTER_LOG_FILE='mysql-bin.000321',
MASTER_LOG_POS=15487321;
START SLAVE;
注意，这里填的binlog文件和位置，必须是在备份起点那一刻的主库状态。如果你用mysqldump备份，可以用--master-data=2参数，它会把备份时刻的主库binlog文件名和位置自动写入dump文件头部，你打开备份文件看前几行就能找到，不用自己卡时间点，也不容易错。
xtrabackup则更简单，恢复完成后它会生成xtrabackup_binlog_info文件，内容就是备份时刻的binlog位置。用xtrabackup做物理备份还有个好处：恢复速度比mysqldump快得多，大库场景下几乎是唯一选择。
备份恢复完成后，检查一下SHOW SLAVE STATUS\G里的关键字段：
Slave_IO_Running: Yes：IO线程正常Slave_SQL_Running: Yes：SQL线程正常Seconds_Behind_Master: 0：从库和主库延迟为0
这三个字段都正常，才算搭好了。我的实际操作经验是，Seconds_Behind_Master偶尔是NULL，多半是SQL线程正在执行一个比较大的事务，或者刚刚启动还没开始追，不用太紧张，观察一会。
2.3 用GTID复制还是传统位点复制：我推荐GTID
传统位点复制在搭建和故障恢复时都需要手工指定binlog文件名和位置，两个数字一错，复制就断，排查还麻烦。GTID（Global Transaction Identifier）从根本上解决了这个问题。
GTID就是每个事务在主库提交时分配的一个全局唯一ID，格式是server_uuid:transaction_id。它跟binlog文件位置无关，跟具体执行了哪个事务有关。从库连接主库后，主库一算就知道该从哪个事务开始推，完全不用手工定位。
开启GTID需要这几个参数：
ini复制gtid_mode=ON
enforce_gtid_consistency=ON
MySQL 8.0里GTID默认就是开启的。搭建GTID复制的change master语句也简化了：
sql复制CHANGE MASTER TO
MASTER_HOST='10.0.0.1',
MASTER_USER='repl',
MASTER_PASSWORD='yourpass',
MASTER_AUTO_POSITION=1;
START SLAVE;
区别就在MASTER_AUTO_POSITION=1，它告诉从库：别管什么binlog文件和位置，咱们靠GTID自动对齐。主库会把从库缺的事务全部发过来，多一个少一个都能自动检测到。
GTID还有一个好处：事务不会重复执行。如果一个GTID事务已经在从库执行过，从库会自动跳过，这在做级联复制或者从库恢复时能避免很多坑。
提示：从传统复制切到GTID复制，官方是支持的，但需要按顺序来：先把主从都设为
GTID_MODE=ON_PERMISSIVE，再设为GTID_MODE=ON，并且建议先在测试环境演练一次。大库切GTID时，注意观察binlog是否出现ANONYMOUS事务，处理不好会阻塞切换。
3. 半同步复制与并行复制：延迟问题怎么破
3.1 复制延迟的根因拆解
复制延迟是MySQL复制里最让人头疼的问题。从库延迟几秒钟，业务读从库可能读到旧数据；延迟几分钟，主库宕机时数据丢失量就很大。要解决延迟，先得知道延迟是怎么来的。
延迟的本质是主库写入速度超过了从库SQL线程的回放速度。在MySQL 5.6之前，从库只有一个SQL线程，主库上多线程并发提交的事务，到了从库只能排队串行执行，这中间的吞吐量差距就是延迟的来源。主库写入并发越高，差距越大。
具体原因可以归类成几类：
第一，大事务。一个事务在主库执行5秒，它产生的binlog传输到从库、再在从库执行，可能也要5秒。在这个事务执行期间，从库SQL线程完全卡住，后面排队的几千个事务全部等待，延迟瞬间飙升。最常见的大事务就是大量DELETE、大量UPDATE、大批量INSERT，以及没有分批处理的ALTER TABLE。
第二，DDL操作。ALTER TABLE在线执行期间会持有表锁或MDL锁，从库S QL线程执行DDL的时候，同一张表的其他事务全部被阻塞。
第三，从库自身的查询压力。从库不是只干复制这一件事，它还承担着业务读流量。如果从库上有慢查询或者大查询占用了IO和CPU，SQL线程的执行速度也会被拖慢。
第四，主从硬件配置差异。这是很多人忽略的。从库磁盘性能、CPU配置比主库差，主库用了NVMe SSD，从库还在用SATA HDD，那延迟几乎是必然的。
3.2 并行复制：从单线程SQL应用到多线程应用
从MySQL 5.6开始支持并行复制，但那个版本只能按不同数据库并行，也就是DATABASE模式。如果你的业务是典型的大库集中模型，所有表都在同一个库里，并行就形同虚设。
真正实用的是5.7开始引入的LOGICAL_CLOCK模式，它基于组提交的机制实现并行。原理是：主库上同一组提交的事务，它们之间没有任何锁冲突，可以安全地在从库并行执行。binlog里通过last_committed和sequence_number标识出事务的组关系，从库SQL协调线程根据这些信息，把同一组的事务分发给多个worker线程同时回放。
配置参数如下：
ini复制replica_parallel_type=LOGICAL_CLOCK
replica_parallel_workers=8
replica_parallel_workers设为多少合适？看CPU核心数和从库实例配置。一般建议从4开始压测，观察延迟有没有改善、有没有报锁等待错误。我见过有人直接设32，结果从库的锁竞争反而比单线程还严重。并行复制不是越大越好，过大的并发会让worker线程之间锁冲突加剧，事务回放的总耗时反而上升。
还有两个小参数值得关注：replica_parallel_workers和binlog_transaction_dependency_tracking。后者控制主库写binlog时如何生成依赖关系，默认是COMMIT_ORDER（按提交顺序），如果你有比较多的跨库事务或者单库集中写入，可以考虑改成WRITESET，它对同一行无冲突的事务判定更准确，能提升从库并行度。但注意，改了之后binlog格式必须用ROW，否则不生效。
3.3 半同步复制：客户端提交时不再裸奔
标准的异步复制下，主库提交事务后直接返回客户端"成功"，binlog同步到从库是后台异步进行的。主库一旦宕机并且binlog还没有传到从库，这些事务就彻底丢了。这在金融、订单场景下不可接受。半同步复制就是为了解决这个问题而生的。
半同步复制在MySQL 5.5就出现了，但一直作为插件存在。核心逻辑是：主库在提交事务后，必须等至少一个从库确认收到了binlog，才向客户端返回成功。这样即使主库宕机，事务也已经存在于从库的relay log里了，数据不会丢。
MySQL 8.0.26之后，半同步插件的命名从rpl_semi_sync_master改成了rpl_semi_sync_source，从库对应是rpl_semi_sync_replica。开启方式：
sql复制INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET GLOBAL rpl_semi_sync_source_enabled = 1;
主从两边都要装插件，主库还要设置rpl_semi_sync_source_wait_for_point参数，它有两个值：AFTER_COMMIT和AFTER_SYNC。
AFTER_COMMIT是旧默认值：主库先把事务提交到存储引擎，然后等待从库ACK，再返回客户端。这个模式下，如果主库在等待ACK时宕机，且从库还没收到binlog，那么主库已提交但未确认的事务会全局丢失，并且从库接管后可能看到主库没有的事务，一致性有风险。
AFTER_SYNC更安全，它是5.7之后的推荐配置：主库先把事务写到binlog，然后等待从库ACK，最后才提交存储引擎。这样主库在等待期间如果宕了，从库一定收到过binlog，切换后数据一致，只不过主库上这个事务不一定会显示提交成功。我强烈建议用AFTER_SYNC。
有一个参数必须提：rpl_semi_sync_source_timeout，它控制主库等待从库ACK的超时时间。默认值是10000毫秒，也就是10秒。如果从库一直不响应，超过这个时间，半同步会降级为异步复制，主库照常提交返回。这样设计的目的是防止从库故障拖死主库。但降级后数据安全等级就悄悄变了，DBA要注意监控这个状态。
提示：半同步复制不是多了一个"必须等从库"的环节，读写性能必然受影响。高并发写场景下，从库网络延迟每多1毫秒，主库的写延迟就可能多1毫秒以上。所以半同步复制的从库最好和主库在同一个内网，别跨机房。
4. 主从切换和日常维护：故障时要能出手
4.1 查看复制状态的“体检三板斧”
日常维护中，你不需要天天盯着复制看，但至少要掌握几个快速体检的命令。
第一板斧是SHOW REPLICA STATUS\G（MySQL 8.0.22之后，旧版本是SHOW SLAVE STATUS）。它输出的字段非常多，关键看这几个：
Replica_IO_Running: Yes：IO线程活着Replica_SQL_Running: Yes：SQL线程活着Seconds_Behind_Source: 0：延迟秒数Last_IO_Error和Last_SQL_Error：如果复制断了，这里会显示具体报错
第二板斧是SHOW PROCESSLIST。在从库上执行，你能看到IO线程和SQL线程的当前状态。IO线程的状态一般是Waiting for source to send event，SQL线程是Replica has read all relay log; waiting for more updates。如果SQL线程卡在一个大事务上，你能在这里看到它正在执行的SQL语句，对定位延迟原因很有用。
第三板斧是看主库的Binlog Dump线程。在主库上执行SHOW PROCESSLIST，能看到每个从库对应的Dump线程，以及它正在发送哪个binlog文件、什么位置。如果从库的IO线程断了，主库这边对应的Dump线程也会消失。这个角度能帮你确认问题到底出在网络、从库还是主库。
4.2 主从切换演练：避免丢数据的手动流程
主库宕机或者要维护时，需要把读流量从从库提升为新主库，这个过程就是failover。手动切换最怕的就是数据不一致，所以步骤必须清晰。
第一种场景是计划内切换，主库还活着。流程大概是：
先在主库上确认没有写入流量，或者把应用停掉，然后执行FLUSH TABLES WITH READ LOCK把主库锁成只读。接着在从库上等Seconds_Behind_Source降到0，确认从库已经追上主库的最后一个事务。这时在从库上执行STOP REPLICA，然后记录当前的GTID集合或者binlog位置，确认没有任何未回放的事务。最后在从库上执行RESET REPLICA ALL，把从库复制关系清掉，关闭read_only和super_read_only，新主库就上线了。应用再切流量到新主库。
第二种场景是计划外切换，主库已经宕了。这种情况下，主库最后几个事务是否传到从库是不确定的。如果是异步复制，从库可能缺一部分数据；如果是半同步复制且没降级，至少有一个从库包含了主库全部已确认事务。所以，半同步复制加AFTER_SYNC配合良好的监控告警，是主从切换数据不丢的最基本保障。
切换后还有个必须处理的细节：旧主库恢复后，不能再让它以旧主库身份继续接收写入，否则会出现脑裂——两个主库同时写入，数据就乱了。通常的做法是把旧主库降级为新主库的从库，重新建立复制关系。如果旧主库有未同步的脏数据，要先想办法补齐或清理。
提示：手动切换一定要写剧本，并且定期演练。我见过太多人在真正的故障发生时，因为紧张把
CHANGE MASTER的地址写反了、把主库的binlog清掉了、甚至把新主库的read_only忘了关，导致生产事故二次爆发。流程写成文档，每一步都打勾，比临场发挥可靠得多。
4.3 复制中断的常见错误码和修复
复制中断是DBA最常处理的故障，我罗列几个最常见的错误码，遇到时可以快速定位。
1236错误特别典型：从库请求的binlog文件或位置在主库上不存在了。原因通常是主库的binlog已被purge清理，或者从库断连时间太长，主库的binlog已经过了保留期。这个错误的修复是调整从库连接到实际存在的binlog位置，或者重新做一次全量备份恢复。GTID模式下，用AUTO_POSITION=1能减少这类问题，但如果主库确实purge掉了从库需要的GTID，一样会报错。
1062错误是主键冲突。从库上已经有相同的记录，主库再插入一条就会报这个错。常见原因是从库被偷偷写入过数据，或者双主架构下的自增值冲突。修复要看情况：如果只是个别误操作，可以跳过这个事务然后补数据；如果冲突很多，说明架构或数据本身就有问题，要停下来排查。
1032错误是从库找不到要更新的行。比如主库把一行数据删了，但对应的binlog在从库执行时，发现这行不存在。这通常意味着主从数据已经不一致了，可能是之前复制中断期间的漏执行，也可能是从库被hand写。修复前一定要用pt-table-checksum这类工具做一次一致性校验，评估数据差异范围，再决定是重建从库还是针对性修复。
修复复制错误时，最粗暴但也常见的办法是手动跳过错误事务。比如SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE;，意思是跳过下一个事务继续执行。但这个操作只适合确认错误事务是无害的误操作。如果错误会引发大面积不一致，跳过只会让数据越差越远，后面治理成本更高。
5. 我踩过的复制坑，能帮你们省不少时间
5.1 大事务导致的延迟，和它引发的连锁反应
我在前面讲了延迟理论，这里说一次真实的事故。有一次线上订单表要清理过期数据，开发同事在主库执行了一条DELETE FROM orders WHERE create_time < '2020-01-01'，这行语句看上去很温和，但没加LIMIT。这条DELETE实际删了800多万行，事务运行了整整15分钟才提交。
后果很快显现：所有从库的SQL线程全部卡住，延迟从0秒涨到2000多秒。业务读从库的接口大批量超时，因为从库数据太旧，甚至出现了订单状态"倒退"的诡异现象。更麻烦的是，因为这个事务特别大，binlog文件膨胀迅速，从库IO线程拉取数据占满了内网带宽，其他正常业务也受到了影响。
这事的教训有三个：第一，线上大批量数据清理必须在低峰期分批进行，每批控制在2000到5000行，小事务提交。第二，大表删除前评估一下binlog膨胀量和从库回放耗时，别只看主库执行快就完了。第三，核心链路监控里必须有从库延迟告警，阈值建议5秒甚至更低，延迟超过阈值立即报警，不要等业务报障。
5.2 DDL操作不评估，从库直接被拖垮
还有一次，主库要对一张千万级用户表加索引。ALTER TABLE ADD INDEX在InnoDB里属于在线DDL，主库执行期间业务读写不受影响，于是开发就在白天直接执行了。主库这边一切正常，几分钟就完事了。但binlog传到从库之后，SQL线程执行同一个DDL时，却需要重新构建整个二级索引，期间持有了表的MDL锁。结果就是：从库SQL线程被这个DDL卡了二十多分钟，所有后续事务全部排队，延迟飙到一千多秒。
那次我学到的总结是：在线DDL在从库的执行代价不一定和主库一样，特别是大表加索引、改字段类型这类操作，从库回放时可能需要重建整个表或索引。所以对大表的DDL，无论主库执行多快，都要预留出从库的追赶时间，最好在低峰期操作。如果项目允许，可以考虑用pt-osc或gh-ost这类在线变更工具，它们对主从的影响都能更平滑。后来我再遇到核心表的加索引需求，都会先让开发把执行时间安排在凌晨两点到四点，然后通知值班DBA观察从库延迟，确认追平后再合上工单。
5.3 从库秒级延迟检查不一定是真延迟
关于Seconds_Behind_Source这个字段，很多新人会误判。它的计算逻辑是"当前时间减去SQL线程正在执行的事务在relay log里的写入时间"，如果SQL线程空闲（relay log已经消费完），这个值是0；如果正在执行大事务，它会显示一个很大的值。
但有一种特殊情况：SQL线程在等待时，Seconds_Behind_Source可能显示为0，但relay log里其实还有一堆没执行完的事务。为什么会这样？因为这个指标统计的是"正在执行"的事务与主库写入时间的时间差，如果SQL线程刚好在某个事务间隙等待，而relay log已经到了末尾，那这个字段自然就是0。另一个坑是，从库时钟跟主库不一致，这个值也会失真。
所以判断从库有没有追上主库，不能只看Seconds_Behind_Source。更可靠的方法是看GTID：对比主库的gtid_executed和从库的gtid_executed，两者一致才说明从库真正追平。或者看主库Binlog Dump线程的发送位置，和主库当前binlog写入位置是否一致，如果一直发送到最新位置，说明没有积压。
提示：在8.0里，你可以用
SHOW REPLICA STATUS\G里的Retrieved_Gtid_Set和Executed_Gtid_Set两个字段做对比，前者是IO线程拉取到的GTID集合，后者是SQL线程执行完的GTID集合，两者相等且与主库一致时，才能确认复制完全追平。
5.4 把复制当备胎，不如把复制当核心组件
最后聊聊心态。早期我接手一些老项目时，主从复制是"加分项"不是"必选项"，很多系统连复制都没配，或者配了从库之后从来没检查过，等主库挂了才发现从库早就断了，数据落后了一个星期。
后来我定了个规矩：任何有主从复制的环境，从库延迟超过10秒就要告警，复制断开的告警是最高优先级，必须有人处理。从库不只是负担，它是你最后的安全网。平时状态良好的复制链路，真到主库宕机那一刻，你的切换才会从容。
MySQL复制的底层原理，说到底就是binlog加三个线程，但要把这套机制跑得稳，需要的是对细节的敬畏。从binlog格式选择，到GTID开启，从半同步配置，到延迟监控，每一个决定都在影响数据安全和业务可用性。我在一次次半夜爬起来处理主从问题后，最大的体会就是：复制不是配完就完事的东西，它是需要持续维护和演练的基础设施。希望你读完这篇，不只是会背几个参数，而是能理解每个配置背后的取舍，遇到问题时知道从哪里入手排查。