PHP实现数据库主备切换方法

PHP原生数据库扩展（mysqli和PDO）完全不支持自动主备切换或故障转移，连接失败即抛错，必须由开发者手动实现健壮的重试逻辑——包括端口预探测、轻量SQL健康检查、主备连接参数轮询、连接活性维护及读写分离策略，同时需规避持久连接干扰、事务跨库风险与备库数据延迟陷阱；真正的高可用不能只靠代码“换host”，而要结合中间件选型、复制状态监控和运维协同，否则看似在线的备库可能在关键时刻无法真正接管流量。

PHP 连接 MySQL 时主库挂了，mysqli 和 PDO 都不会自动切备库

这是最常被误解的一点：PHP 原生数据库扩展（mysqli、PDO_MYSQL）不支持连接层的故障转移。它们只负责连上一个地址，连不上就报错，不会尝试下一个 IP 或端口。

所以你看到 mysqli_connect(): (HY000/2002): Connection refused 或 PDOException: SQLSTATE[HY000] [2002] Connection refused，说明连接已失败，程序必须自己处理重试逻辑。

• 不要指望 mysqli_connect($host, $user, $pass) 传多个主机就能自动 failover
• PDO 的 mysql:host=... 也不支持逗号分隔的 host 列表（那是 PostgreSQL 的写法）
• MySQL 官方推荐的高可用方案（如 MGR、InnoDB Cluster）依赖客户端路由插件或中间件，PHP 默认不集成

手动实现主备切换：用数组存多个 DSN，逐个尝试连接

最轻量、最可控的做法是把主库和备库的连接参数写成数组，按顺序尝试，直到成功或耗尽列表。

注意：不是“连上就用”，而是每次操作前都得确保连接有效；更稳妥的做法是封装一个带重试的连接工厂函数。

• 连接前先用 fsockopen() 或 stream_socket_client() 快速探测端口是否可达，避免 mysqli 耗时超时（默认 60s）阻塞
• 对 PDO，记得设置 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，否则连接失败不会抛异常
• 连接成功后，立即执行一条轻量查询（如 SELECT 1）确认服务可响应，防止 TCP 握手成功但 MySQL 进程僵死
• 缓存当前生效的连接索引，后续请求优先用它，而不是每次都从头试

$hosts = [
    ['host' => '192.168.1.10', 'port' => 3306, 'role' => 'master'],
    ['host' => '192.168.1.11', 'port' => 3306, 'role' => 'slave'],
];
$pdo = null;
foreach ($hosts as $i => $h) {
    try {
        $dsn = "mysql:host={$h['host']};port={$h['port']};dbname=test";
        $pdo = new PDO($dsn, $user, $pass, [
            PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
            PDO::ATTR_TIMEOUT => 3,
        ]);
        $pdo->query("SELECT 1");
        $current_role = $h['role'];
        break;
    } catch (PDOException $e) {
        continue;
    }
}

读写分离 + 故障转移：区分 SELECT 和其他语句，但别在运行时动态换库

很多人想“写走主库，读走备库，主库挂了就读备库”，这想法合理，但实现上容易翻车——不能在事务中中途切换连接，也不能让一个 PDOStatement 跨连接执行。

真正可行的是：每个请求开始时确定本次使用的连接（主 or 备），并全程复用；写操作强制走主库，读操作优先备库、主库兜底。

• 不要在同一个请求里混用两个 PDO 实例做事务（会出错：无法跨连接提交）
• 如果主库不可用，所有写操作必须拒绝（返回 503），不能降级到备库写——MySQL 备库默认 read_only=ON，强行关会导致数据不一致
• 用 mysqli::ping() 或 PDO::getAttribute(PDO::ATTR_CONNECTION_STATUS) 定期检查连接活性，别等 query 时才暴露断连
• DNS 轮询或负载均衡器（如 HAProxy）可以分担一部分探测压力，但 PHP 层仍需有兜底逻辑

为什么不用现成的库？比如 robmorgan/phinx 或 laravel/framework 的 DB 封装

这些库确实封装了多节点配置，但底层仍是调用原生扩展，并未突破连接模型限制。Laravel 的 DB::connection('cluster') 本质也是循环尝试配置里的 hosts，且默认不开启自动重试。

真正影响决策的是你的部署结构：如果用了 ProxySQL、MySQL Router 或 Vitess，那 PHP 只需连本地代理，故障转移由中间件完成——这时 PHP 层反而要禁用任何重试逻辑，避免干扰代理的健康检查。

• Laravel 配置里 'sticky' => true 是为了事务连续性，不是故障转移
• phinx 的 environments 是静态环境切换，不是运行时 failover
• 任何“自动”切换都需配套的健康上报机制（比如备库同步延迟超过 5 秒就不参与读流量）
• 最易忽略的一点：连接池、长连接（PDO::ATTR_PERSISTENT）会让故障感知变慢，建议关闭持久连接用于 failover 场景

主备切换不是“换个 host 字符串”就能跑通的事。连接状态、事务边界、复制延迟、权限一致性——每层都可能卡住。动手前先确认你的备库是不是真能随时接管读流量，而不是只在监控图上看起来在线。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~