MySQL从库缩容是数据库集群运维中的常见操作，主要目的是在业务流量下降、资源冗余或架构调整时，减少从库节点数量，降低资源成本，同时保障主从复制环境的稳定性和数据一致性。合理的缩容策略需要覆盖评估、操作、验证全流程，避免数据丢失或服务中断。
缩容前的评估与准备
在执行从库缩容前，需要先完成全面的评估工作，确认缩容的可行性，避免影响线上业务。
业务负载评估
首先统计当前所有从库的负载情况，包括QPS、连接数、CPU和内存使用率，确认待缩容的从库是否承载了业务读请求。如果该从库正在提供服务，需要先将读流量切换到其他存活的从库，避免缩容后业务请求失败。
主从复制状态检查
检查待缩容从库的主从复制状态，确保复制无延迟、无错误。可以通过如下命令查看从库复制状态：
-- 在从库执行，查看复制状态 SHOW SLAVE STATUSG;
重点关注Slave_IO_Running和Slave_SQL_Running是否都为Yes，Seconds_Behind_Master是否为0，确认复制完全同步后再进行后续操作。
数据备份
缩容前对待缩容从库进行全量数据备份，防止操作过程中出现意外导致数据丢失。可以使用mysqldump工具完成备份：
# 备份待缩容从库的所有数据 mysqldump -u root -p --all-databases > /backup/slave_backup_$(date +%Y%m%d).sql
从库缩容的具体操作步骤
步骤1：停止从库复制线程
在待缩容的从库上执行命令，停止主从复制的IO线程和SQL线程：
-- 停止从库复制 STOP SLAVE;
执行后再次通过SHOW SLAVE STATUSG;确认复制线程已经停止。
步骤2：移除从库的主从关联配置
清除从库上保存的主库连接信息和复制位点，避免后续重启后自动尝试连接主库：
-- 重置从库复制配置 RESET SLAVE ALL;
该命令会清除master.info和relay-log.info文件中的配置信息，彻底断开与主库的复制关联。
步骤3：停止从库服务并下线
完成上述操作后，停止从库的MySQL服务，如果是容器化部署可以直接停止容器，如果是物理机或虚拟机部署可以执行系统命令停止服务：
# 系统层面停止MySQL服务（CentOS系统示例） systemctl stop mysqld
之后可以根据实际需求释放对应的服务器资源，完成从库的下线操作。
步骤4：主库和其他从库配置调整
如果原集群中主库或其他从库配置了指向该待缩容从库的相关参数，需要同步调整。例如如果主库开启了半同步复制，且待缩容从库是半同步节点，需要修改主库的半同步配置，移除该从库的对应设置：
-- 主库上查看半同步从库列表 SHOW STATUS LIKE 'Rpl_semi_sync_master_clients'; -- 如果待缩容从库在列表中，等待其下线后，半同步客户端数量会自动减少，无需额外操作
缩容后的验证与风险应对
集群状态验证
缩容完成后，需要验证剩余从库的主从复制状态是否正常，业务读请求是否都能正常路由到存活的从库。可以随机执行几条读请求，确认返回结果正确，同时监控剩余从库的负载情况，避免出现负载过高的问题。
常见问题应对
- 如果从库复制延迟较高，不要直接执行缩容，先优化复制性能，等待延迟消失后再操作。
- 如果缩容后发现业务读请求失败，检查读流量路由配置，确认是否还有请求指向已下线的从库，及时调整路由规则。
- 如果误删除了从库数据，可以通过之前备份的文件快速恢复，重新搭建从库节点。
不同场景下的缩容策略差异
如果是临时缩容，后续可能重新上线该从库，可以只停止复制线程和MySQL服务，保留数据和配置，后续需要重新上线时，重新配置主从复制即可。如果是永久缩容，建议执行RESET SLAVE ALL并清理相关数据文件，释放磁盘空间。
对于使用 orchestrator 等集群管理工具的MySQL集群，缩容操作可以通过管理工具的可视化界面或API完成，工具会自动处理主从关系调整和流量切换，降低人工操作的风险。