MySQL主从复制需监控延迟并自动切读主，故障切换后须校验数据一致性，PHP层应实现连接重试与异常兜底，备份恢复须定期实操演练。
主从复制是基础，但必须监控延迟
MySQL 主从复制是 PHP 应用实现数据库高可用最常用的架构。不过，单纯搭建好主从并不等于高可用——从库延迟（Seconds_Behind_Master）可能在业务高峰期飙升到数十秒甚至分钟级。PHP 应用若未做读写分离策略或强制读主，用户就可能看到过期数据。建议在应用层加轻量检测：比如定期查询 SHOW SLAVE STATUS，或通过心跳表（如 heartbeat 表每秒更新）比对时间戳。延迟超过 500ms 时，可自动将读请求切回主库，或返回降级响应。
故障切换不能只靠脚本，要验证一致性
当主库宕机，运维常依赖 MHA、Orchestrator 或自研脚本执行 failover。但切换后最易被忽略的是数据一致性校验。例如：GTID 模式下需确认新主的 Executed_Gtid_Set 包含所有原主已提交事务；传统 binlog 模式则要核对 Relay_Master_Log_File 和 Exec_Master_Log_Pos 是否追平。建议在切换完成后，用 pt-table-checksum 快速抽查核心表，或至少比对关键业务表的行数与最新更新时间。
连接池与重试逻辑得由 PHP 层兜底
数据库中间件（如 ProxySQL、MySQL Router）能分担路由压力，但网络抖动或短时主从切换仍会导致 PHP 连接失败。不能只依赖 PDO 的默认设置。需在代码中实现：
• 使用 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION 捕获异常
• 对 SELECT 请求增加最多 2 次重试（间隔 100ms），首次失败后刷新从库列表或强制走主库
• 写操作失败时，不盲目重试，而是记录日志并触发告警，避免重复提交
备份恢复流程必须定期实操演练
mysqldump + binlog 是主流方案，但“有备份”不等于“能恢复”。常见问题包括：备份时未加 --single-transaction --master-data=2 导致一致性缺失；binlog 清理策略过激造成断点不可用；恢复脚本权限或路径硬编码导致线上失效。建议每季度组织一次“无通知恢复演练”：随机选一个从库，停服、删除数据目录、用最近全备+增量 binlog 恢复，并验证 PHP 应用能正常读写。过程中暴露的权限、磁盘空间、脚本兼容性等问题，比任何文档都真实。
高可用不是架构图上的虚线箭头，而是每次故障后 3 分钟内服务回归、数据零丢失的确定性。它藏在延迟监控的阈值里，藏在重试逻辑的判断条件里，也藏在那场没人围观的恢复演练里。
