ThinkPHP如何做数据库主从切换演练_ThinkPHP故障转移测试详解【详解】

ThinkPHP数据库主从切换演练与故障转移测试详解

主从配置写对了但不生效？检查 database.php 的 deploy 和 rw_separate

很多开发者踩过这个坑：在ThinkPHP 5.1+里配好了主从数据库，满心以为Db::table('user')->select()会自动路由到从库，结果一查日志，连接请求全都涌向了主库。问题出在哪儿？其实，ThinkPHP的主从读写分离并非“配置即生效”，它需要两个明确的开关同时打开。

关键就在于database.php配置文件里的这两个项：

• deploy => 1：这是启用分布式部署的总开关，没有它，主从架构的基础就不成立。
• rw_separate => true：这才是真正开启读写分离的钥匙。特别注意，这里要写布尔值true，写成数字1可能会导致功能静默失效，排查起来相当头疼。

至于master_num、sla ve_no这些参数，属于更精细的进阶控制，初期可以不配。但上面这两个基础开关，漏掉任何一个，ThinkPHP都会直接退化成单库模式，你的主从配置也就形同虚设了。

如何强制走从库？用 db('sla ve') 或 ->master(false)

默认的自动路由机制虽然方便，但在做演练和测试时却像个“黑盒”——你无法确定某次查询是否真的走到了从库。为了验证配置和进行确定性测试，你需要掌握手动指定连接的方法。

立即学习“PHP免费学习笔记（深入）”；

• db('sla ve')：这个方法直接、粗暴且有效。它要求你在配置文件中预先定义一个名为sla ve的独立数据库配置，然后直连它。
• Db::table('user')->master(false)->select()：这是更符合“读写分离”语义的方式。它强制本次查询禁用主库，转而去从库连接池（如果配置了多个从库，会进行轮询）中获取连接。
• Db::connect(['dsn' => 'mysql:host=192.168.10.22;dbname=test'])：当需要绕过所有配置，直接验证某个特定数据库实例的网络连通性和权限时，这个临时连接方法就派上用场了。

这里有个至关重要的细节：->master(false)在数据库事务内部是无效的。ThinkPHP的设计很合理，它认为事务内的所有操作必须在同一个数据库节点上执行以保证一致性。但这个限制容易被忽略，导致你在事务块里测试从库查询时，得到错误的验证结果。

故障转移怎么测？关主库后看 Connection refused 是否被拦截

一提到“故障转移”，不少人会幻想成“主库挂了，系统自动无缝切换到从库继续读写”。醒一醒，这在数据库主从架构里是危险且不现实的。真正的故障转移演练，目标是验证“当主库不可用时，系统的失败行为是否可控”。

正确的演练姿势是这样的：

• 主动停掉主库的MySQL服务（执行systemctl stop mysqld或结束进程），然后尝试执行一个写操作，比如Db::table('user')->insert([...])。
• 你预期看到的结果应该是：抛出一个PDOException异常，错误信息里明确包含Connection refused或Can't connect to MySQL server这类字眼。这说明框架正确地捕获到了底层连接失败。
• 此时，如果你希望读请求还能继续工作，就需要在应用层自己实现兜底逻辑。例如：

try {
    $data = Db::table('user')->select();
} catch (\PDOException $e) {
    // 判断是否是主库连接拒绝错误
    if (strpos($e->getMessage(), 'Connection refused') !== false) {
        // 手动降级，切换到从库进行读取
        $data = db('sla ve')->table('user')->select();
    }
}

必须明确一点：ThinkPHP本身不会自动将写操作（INSERT/UPDATE/DELETE）Fallback到从库。任何声称能自动这样做的“高可用”方案，你都需要对其数据一致性持高度怀疑态度。

从库延迟导致数据不一致？lastInsertId() 和 find() 必须走主库

这是主从架构下最经典的“坑”。演练时经常模拟这个场景：插入一条数据后，立刻查询它，却发现查不到或者查到的是旧数据。问题根源在于主从复制存在延迟。

• 你调用Db::table('user')->insertGetId()，返回的ID是基于主库生成的，绝对正确。
• 但紧接着，如果你不加任何指定地调用Db::table('user')->find($id)，这条查询默认会路由到从库。此时，从库可能还没来得及收到刚才那条插入的数据，结果就是“查无此记录”。
• 解决方案很直接：对于依赖于刚完成写操作结果的后续查询，必须显式指定走主库：Db::table('user')->master(true)->find($id)。

同理，在使用lastInsertId()获取自增ID后，或者执行完update、delete操作后需要立刻校验结果时，都应该加上->master(true)来确保读到最新的数据。这并非ThinkPHP的缺陷，而是所有使用数据库主从复制时都必须遵守的约束规则。如果你的演练方案里没有包含对这类“读写后立即读”场景的延迟测试，那整个演练的完整性就要打上问号了。