ThinkPHP数据库配置实战：基于Keepalived的数据库高可用架构在ThinkPHP中的故障切换

在构建高可用架构时，不少开发者会遇到一个看似矛盾的问题：我们的应用框架——比如ThinkPHP——本身并不感知底层的Keepalived，也不参与VIP漂移或主库切换的逻辑。它只认一个数据库连接地址。所以，“ThinkPHP中实现故障切换”这个命题，本质上其实很简单：让它的database.php配置，始终指向当前那个“活着的”主库。而这个“活主库”，由Keepalived通过虚拟IP（VIP）统一对外暴露。

为了把这个逻辑讲明白，我们来拆解几个关键环节。

ThinkPHP 的数据库配置必须用 VIP，不能写具体节点 IP

这是整个架构的根基，也是最容易被忽视的陷阱。如果你在 config/database.php 里写了类似 'hostname' => '192.168.10.120' 这样的具体节点IP，那恭喜你，你直接绕过了VIP调度，Keepalived配置得再完美也等于白费——应用会直连某台物理机，故障时根本切不走。

正确的做法是：

• 在Keepalived配置中定义好VIP，比如 192.168.10.200
• 所有ThinkPHP实例的 'hostname' 必须设为该VIP，也就是 'hostname' => '192.168.10.200'
• 确保应用服务器能路由到这个VIP——同网段、无防火墙拦截、ARP缓存能及时刷新，这些都是基本功

MySQL 主主复制状态必须稳定，否则 VIP 切换后写入会失败

Keepalived只管网络层的漂移，它可不管数据层的一致性。想象一下，如果两台MySQL节点之间的复制已经中断，VIP漂到从节点后，应用发起写操作——此时新主库可能缺失最新数据，结果就是主键冲突、唯一索引报错，甚至数据覆盖。这才是真正的灾难现场。

关键的检查点有几个：

• 双主双方都必须开启 log_sla ve_updates = ON，否则互为主从的逻辑闭环无法完成
• 每个节点的 server-id 必须唯一，不能为0或重复
• 建表时强制使用 AUTO_INCREMENT 并错开步长——节点1设 auto_increment_offset = 1、auto_increment_increment = 2；节点2反过来
• 务必部署 check_mysql.sh 这类健康脚本，由Keepalived的 vrrp_script 调用。只有当 mysql -h127.0.0.1 -e "SELECT 1" 和 SHOW SLA VE STATUS 都返回正常时，才认为这个节点有资格接管VIP

这些细节缺一不可，任何一个环节出问题，整个高可用都是空中楼阁。

应用层无感知切换的前提：连接池与重试机制要配合

VIP漂移不是原子操作，中间存在几秒的窗口期：旧主断连 → Keepalived检测超时 → VIP绑定到新主 → ARP广播更新 → 应用TCP连接重建。这个期间，已有的连接会报错——常见的像 SQLSTATE[HY000] [2002] Connection refused 或 Lost connection to MySQL server during query。

ThinkPHP默认不会自动重试，你需要主动处理：

• 在 thinkdbConnection 异常捕获中，对网络类错误做有限次重试（建议不超过3次），避免雪崩效应
• 禁用长连接（设置 'break_reconnect' => true），防止复用已失效的socket
• 如果使用PDO，确认 PDO::ATTR_ERRMODE 设为 PDO::ERRMODE_EXCEPTION，否则错误会被悄无声息地吞掉
• 不要依赖那种“重连钩子”的幻想——ThinkPHP 6.x 的 onBreak 回调仅触发但不自动恢复，你仍然需要手动 $this->close() + $this->query()

最后还有一个最容易被忽略的细节：当原主库恢复上线时，必须人工确认复制状态并执行 START SLA VE。否则它会以“旧主”身份继续拒绝同步请求。Keepalived只管把流量导给“当前它认为健康的那个IP”，它不会、也不能替你修复MySQL的复制链路。

这就是整个架构的底层逻辑——看似简单，但每一环都不能掉链子。