ThinkPHP配置国产万里数据库GreatDB：金融级数据库在ThinkPHP中的高可用接入方案-ThinkPHP-PHP中文网

thinkphp 连 greatdb 必须显式配置 type='mysql'、hostname=vip、port=实际端口、charset='utf8mb4'，禁用 strict，启用 attr_emulate_prepares 和 break_reconnect，并预定义连接名复用连接池。

thinkphp配置国产万里数据库greatdb：金融级数据库在thinkphp中的高可用接入方案

ThinkPHP 能直接连 GreatDB，但默认配置会失败 —— 因为 GreatDB 兼容 MySQL 协议，却不完全等同于 MySQL，尤其在高可用集群模式下，host、port、failover 等行为必须显式适配，否则连接池会反复重试、VIP 切换不生效、Paxos 集群节点间事务不一致。

ThinkPHP database.php 中 type 和 hostname 必须显式设为 mysql，但不能依赖自动识别

GreatDB 官方明确声明 100% 兼容 MySQL 协议，所以 ThinkPHP 的 type 只能填 'mysql'，填 'greatdb' 或留空会导致驱动加载失败。但问题在于：MySQL 驱动默认不处理 Paxos 集群的多节点故障转移逻辑，所以仅靠 hostname 指向单个计算节点是脆弱的。

必须把 hostname 设为 VIP 地址（如 '192.168.5.100'），而非某个具体 SQL 节点 IP；否则 VIP 切换后连接持续超时
hostport 值需与 GreatDB 计算节点实际监听端口一致（默认 3306，但某些信创环境会改为 53306，务必确认）
禁用 'strict'=>true（ThinkPHP 默认开启），GreatDB 在强一致写入路径下对部分 SQL_MODE 不兼容，启用后 INSERT/UPDATE 可能报错
字符集必须显式设为 'charset'=>'utf8mb4'，GreatDB 对 utf8（即 utf8mb3）支持有限，中文字段易截断

Db::connect() 传参必须用预定义连接名，不能传 DSN 或数组绕过配置

很多开发者想用 Db::connect('jdbc:mysql://...') 或临时数组快速测试，这在 GreatDB 场景下极危险：它跳过连接池管理，每次调用都新建 PDO 实例，而 GreatDB Paxos 集群对短连接有更严格的握手和状态同步开销，高并发时直接触发 Too many connections 或 Connection refused。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

所有 GreatDB 连接必须在 database.php 的 connections 下预定义，例如键名为 'greatdb_prod'
Db::connect('greatdb_prod') 才能复用连接池、走 VIP 故障转移逻辑
绝对不要传数组：Db::connect(['type'=>'mysql','hostname'=>'...']) —— 此方式无法感知 GreatDB 的 Paxos 节点状态，主节点宕机后仍持续发请求到失效地址
若需读写分离（如报表查备份库），必须另配一个独立连接（如 'greatdb_report'），并确保其 hostname 指向只读 VIP 或从节点集群入口

金融级高可用必须开启 PDO::ATTR_EMULATE_PREPARES 和重连机制

GreatDB Paxos 集群在主节点切换瞬间（秒级）会出现短暂连接中断，MySQL 原生驱动默认不重连，ThinkPHP 会直接抛出 PDOException: Lost connection to MySQL server during query。这不是代码 bug，而是协议层需主动兜底。

在连接配置中加入：'params'=>[PDO::ATTR_EMULATE_PREPARES => true]，避免预编译语句在节点切换后因 statement handle 失效而卡死
添加重试参数：'break_reconnect'=>true（ThinkPHP 6.1+ 支持），配合 'wait_timeout'=>30 使用，让框架在连接异常时自动重建连接
禁用长事务：GreatDB 强一致模式下，跨 Paxos 节点的长事务（>30s）可能被集群自动 kill，业务层应拆分为幂等短事务
务必关闭 'debug'=>true 上线环境，开启后每条 SQL 都会记录完整执行栈，GreatDB 集群日志量激增，影响审计追踪效率

多库同步场景下，GreatDB 与 MySQL 混合部署的字符集与时间精度陷阱

运营商 O 域三中心替换案例中，常出现 ThinkPHP 同时连 GreatDB（新核心库）和遗留 MySQL（外围系统），此时即使两个库都设了 utf8mb4，仍有乱码或 Incorrect string value 报错 —— 根本原因是 GreatDB 默认使用 utf8mb4_0900_as_cs 排序规则，而老 MySQL 多为 utf8mb4_general_ci，collation 不匹配导致隐式转换失败。

统一在各库连接配置中加 'suffix'=>'?charset=utf8mb4&collation=utf8mb4_0900_as_cs'（GreatDB）或 utf8mb4_unicode_ci（MySQL），强制客户端协商
时间字段必须用 datetime(6)，GreatDB 默认微秒精度，MySQL 5.7 默认秒级，混用时 created_at 字段插入会丢失微秒或报错
分页同步时禁用 limit + offset，GreatDB 分布式环境下该组合性能陡降；改用基于主键/时间戳的游标分片，例如 WHERE id > ? ORDER BY id LIMIT 1000
checkpoint 表必须建在 GreatDB 本地，不能跨库写入；否则 Paxos 一致性协议会将该表写操作同步到所有节点，引发不必要的复制延迟

GreatDB 的 Paxos 集群不是“换个数据库就行”的黑盒，它的高可用能力必须由应用层主动对齐：VIP 地址、连接池复用、PDO 层参数、字符集协商，缺一不可。最容易被忽略的是 break_reconnect 和 ATTR_EMULATE_PREPARES 这两个开关 —— 它们不解决功能问题，但决定系统在真实故障下的存活时间。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！