slave避坑：复制原理解析
slave避坑的关键，是理解复制链路如何工作，而不是照抄一段配置。旧称slave通常指从主库接收日志并重放的复制节点。本文按总-分-总讲清延迟、一致性、故障切换和权限边界，帮你避开线上常见事故。
总述：问题往往不在搭建，而在误用
很多团队搭建slave只需半小时，但真正出问题是在上线后：查询读到旧数据、从库延迟堆积、主库误删被同步、故障切换后数据不一致。slave避坑的底层逻辑是承认复制不是魔法，它只是把主节点变化按一定顺序传到副本节点，中间存在网络、IO、SQL重放和事务冲突成本。
避坑一：把复制延迟当成必然变量
复制延迟不是异常，而是分布式系统的常态。主库写入完成后，从库可能晚几毫秒到几分钟才可见。用户刚下单就查订单、刚改密码就登录，这类读写强相关链路不要默认走从库。更稳妥的做法是关键读走主库，非关键列表走从库，并设置延迟阈值，超过阈值自动降级。
避坑二：不要把slave当作备份
从库会忠实同步主库操作，包括误删表、错误更新和脏数据写入。若没有独立备份，一次误操作会同时污染主从。正确做法是保留全量备份、增量日志和定期恢复演练。slave适合提升读取能力和部分容灾能力，但不能替代可回滚的备份体系。
避坑三：故障切换要提前演练
主库宕机时，不是随便把slave提升为主库就结束。你要确认复制位点、是否有未同步事务、应用连接如何切换、旧主恢复后如何处理。没有演练的切换最容易造成双写或数据回退。建议使用自动化工具，但仍要人工理解流程，尤其是金融、库存、订单类系统。
总结：用边界感管理slave
slave避坑的结论很明确：它适合读扩展、冷热隔离和有限容灾，不适合承担强一致读、唯一备份和无准备的自动接管。把延迟、权限、备份、监控、演练写入上线清单，才是让复制节点长期稳定的关键。
常见问题
slave延迟多少算危险？
取决于业务。普通内容站延迟数秒可能可接受；订单、支付、权限系统通常应控制在毫秒级或关键读走主库。
slave避坑需要监控哪些项？
至少监控复制延迟、IO线程、SQL线程、磁盘空间、慢查询、连接数和主从数据校验结果。
为什么从库查询会影响复制？
大查询会占用CPU、内存和磁盘IO，导致复制日志重放变慢，延迟随之增加。