数据库高可用需主从分离与读写分离，主库专注强一致性写操作，从库分担查询压力；中间件须识别事务上下文确保事务内读走主库；故障切换需综合复制延迟、relay log应用状态及xa事务残留；连接层应具备熔断降级能力；备份恢复须定期演练并校验逻辑状态。
主从分离与读写分离是基础
数据库高可用不是单纯堆机器，而是让不同角色的节点各司其职。主库专注处理事务性写操作，确保数据强一致性；从库承担查询类请求，通过异步或半同步复制分担压力。需注意：读写分离中间件（如 MyCat、ShardingSphere 或自研 Proxy）必须识别事务上下文——事务中的读也应路由到主库，否则可能读到过期数据。
故障自动切换需兼顾数据一致性与业务连续性
主库宕机时，不能只看“谁最先响应”，而要综合判断：复制延迟是否在容忍范围内、候选从库是否已应用完所有 relay log、是否有未提交的 XA 事务残留。推荐使用 MHA、Orchestrator 或基于 GTID + 健康检查脚本的轻量方案。切换后务必验证新主库的 binlog position 或 GTID set 是否连续，避免脑裂导致数据覆盖。
连接层必须具备熔断与降级能力
PHP 应用不直连数据库 IP，而是通过连接池或代理层（如 ProxySQL、HAProxy + keepalived）。当检测到主库异常或从库延迟超阈值（如 > 3 秒），应自动：暂停向该从库转发读请求；对非核心查询返回缓存或默认值；写失败时记录结构化日志并触发告警，而非直接抛出致命错误。PDO 的 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION 需配合 try-catch 和重试策略（带退避机制），避免雪崩。
备份与恢复流程必须定期验证
全量备份（如 xtrabackup）+ 增量 binlog 是标配，但关键在“可恢复”。每月至少执行一次真实恢复演练：拉起临时实例 → 应用备份 + 后续 binlog → 校验关键表行数与 checksum。特别注意 PHP 应用中可能存在的逻辑删除、软状态（如订单 status=‘pending’ 持续 2 小时未更新），这些需在恢复后人工或脚本核验，不能只依赖数据一致性比对。
立即学习“PHP免费学习笔记（深入）”；
