Navicat 16 不能直连 PostgreSQL 高可用集群，仅支持连接单个 PostgreSQL 实例（如当前 primary 的 VIP 或 DNS），不识别 Patroni/repmgr/Pgpool-II 等集群拓扑逻辑；硬编码节点 IP 或填多个 host 会导致连接失败。
Navicat 16 能否直连 PostgreSQL 高可用集群？
不能直接“连集群”，Navicat 本身不理解 Patroni、repmgr 或 Pgpool-II 的拓扑逻辑，它只认单个 PostgreSQL 实例的 host + port。所谓“连集群”，本质是连一个可读写的入口节点（通常是当前 primary），或连一个能做负载转发的中间件。盲目填多个 host 或用逗号分隔，Connection refused 或 no pg_hba.conf entry 是必然结果。
连接 Patroni / repmgr 管理的 HA 集群时，host 应该填什么？
填 Patroni API 地址或 VIP（推荐），而不是某个固定节点 IP：
- 如果部署了
patroni并启用了 REST API（默认http://<node-ip>:8008</node-ip>），Navicat 无法直连该端口——它不是 PostgreSQL 协议。你得用patroni提供的postgresql服务地址，即当前 primary 的真实 IP 和端口（如192.168.1.10:5432） - 更可靠的做法是配置一个浮动 IP（VIP）或 DNS 名（如
pg-primary.example.com），并确保它始终指向当前 primary。Patroni/repmgr 切换时会自动迁移 VIP 或更新 DNS。Navicat 的Host就填这个 VIP 或 DNS 名 - 切忌在 Navicat 连接中硬编码某台机器的 IP（比如
pg-node-1），一旦它降为 standby，连接立即失效
pg_hba.conf 和 SSL 配置必须匹配集群角色
HA 集群里，primary 和 standby 的 pg_hba.conf 通常一致，但要注意两点：
-
pg_hba.conf中针对 Navicat 所用 IP 段的规则，method 字段不能是md5（PostgreSQL 15+ 默认已弃用），必须为scram-sha-256；否则即使 SSL 开了，也会报password authentication failed - 若启用 SSL，且集群要求
verify-full（如云厂商 RDS 强制要求），则 Navicat 的 SSL 设置里必须填对sslrootcert路径，且 Host 值（即你填的 VIP 或 DNS）必须和证书里的Subject Alternative Name完全一致——填pg-cluster而证书里是pg-primary.example.com，就会失败 - standby 节点默认拒绝写操作，但 Navicat 连上去后执行
INSERT会直接报错cannot execute INSERT in a read-only transaction，这不是连接问题，是预期行为
为什么连接测试成功，但执行 DDL 就超时或报错？
常见于使用 Pgpool-II 或类似代理层时：
- Pgpool-II 默认关闭
enable_pool_hba，或pool_hba.conf里没加 Navicat 源 IP 的允许规则，导致连接能建，但权限检查被拦在代理层 - Pgpool 的
load_balance_mode = on时，某些 DDL（如CREATE TABLE）可能被错误路由到 standby，触发只读错误；应临时关掉负载均衡，或确认 Pgpool 版本支持 DDL 自动重定向到 master - Navicat 的“自动提交”开关（Auto-commit）若关闭，而你手动开事务后执行 DDL，某些代理会因事务上下文混乱而卡住——建议保持 Auto-commit on，或明确用
BEGIN; ... COMMIT;包裹
HA 场景下最易被忽略的是：Navicat 连接池设置里的 Max Connections 和 Connection Lifetime 若设得过大或过长，故障切换后旧连接残留，可能持续往已下线节点发请求，表现为偶发性超时而非立刻失败。
