GBase 8a 连接与会话治理：别让空闲会话拖垮 Coordinator

MPP 集群里，业务侧常说「数据库连不上」「越来越慢」，排查时却发现 CPU 并不高、慢 SQL 也不多——最后落在 Coordinator（CN）上连接数打满 或 大量 Sleep 会话占着槽位。8a 的 CN 负责接入、解析、计划下发；连接是可消耗资源，和 DataNode 上的算力不是一回事。连接治理做不好，会出现新请求排队、已有会话被误杀、批任务与交互式查询互相拖累。

本文给 DBA 一套可落地的会话巡检与治理思路，侧重 gccli 现场能执行的命令与判断分支。

一、先分清：连接满、慢、锁，是三件事

接到告警时，建议先按下面分支，避免一上来 KILL 全库：

在 gccli 登录 CN 后，先确认自己连的是协调节点（发布、运维文档中的集群入口），再查全局会话。

二、用 PROCESSLIST 做「连接地图」

SHOW FULL PROCESSLIST;

阅读时建议按列做简单统计（可导入表格或脚本聚合）：

1. User / Host：哪个应用、哪台机器占连接最多；是否有「一台应用服务器开几千连接」的异常。
2. Command：Sleep 长期占比过高 → 连接池 maxActive 过大或应用未归还；Query 长时间不结束 → 慢 SQL 或锁。
3. Time：Sleep 且 Time>3600 的会话，通常是可治理的闲置连接。
4. State：Locked、等待元数据等状态，优先于大批量 Kill Sleep。

-- 示例：粗看 Sleep 超过 1 小时的会话数（语法以版本为准）
SELECT User, Host, COUNT(*) AS cnt
FROM information_schema.processlist
WHERE Command = 'Sleep' AND Time > 3600
GROUP BY User, Host
ORDER BY cnt DESC;

若 8a 环境提供集群级会话视图（名称以现场文档为准），可对比 各 CN 是否均衡；个别 CN 连接飙高可能是负载均衡或 DNS 配置不均。

三、连接池与应用侧：8a 上要守住的参数

应用普遍用 JDBC 连接池。对 8a 集群，URL 里常配多个 CN 地址做 failover，例如：

jdbc:gbase://cn1:5258,cn2:5258,cn3:5258/mydb?useUnicode=true&characterEncoding=utf-8

治理要点：

1. 池大小：单应用实例 maximumPoolSize 不宜过大；多实例部署时，「实例数 × 每池连接」必须小于 CN max_connections 留有批任务与运维余量。
2. 空闲回收：配置 idleTimeout / maxLifetime，避免业务低峰仍占上千 Sleep。
3. 超时：connectionTimeout、socketTimeout 与查询超时分开设；长报表任务单独池或只读账号，勿与在线交易共池。
4. 事务：务必在 finally 或框架事务里 commit/rollback 并关闭；未提交事务会占连接且可能挡 DDL。

在 CN 上可查最大连接（变量名以版本为准）：

SHOW VARIABLES LIKE 'max_connections';

若接近上限，优先减池、踢长期 Sleep，再考虑调高上限——单纯调大往往把内存与线程压力转嫁给 CN。

四、止血：如何安全 KILL 会话

确认要断开会话前：

1. 排除 系统/复制/备份 账号（以现场白名单为准）。
2. 对 Query 且 Time 极大的，先 KILL QUERY ，仍不释放再 KILL CONNECTION （或 KILL ，以文档为准）。
3. 批量清理 Sleep：按 Host 分批，每批间隔几秒，观察 CN 负载与业务错误率。

-- 仅示例：定位单个长查询会话
SHOW PROCESSLIST;
-- KILL QUERY 12345;

避免在业务高峰对核心库「一键 Kill 所有 Sleep」——连接池会立刻重建，反而造成连接风暴。

五、与慢 SQL、锁的联动

连接打满时，底层仍可能是 少数几条 SQL 占着 worker。建议联动：

-- 长事务（示例，表名以版本为准）
SELECT * FROM information_schema.innodb_trx
ORDER BY trx_started ASC
LIMIT 20;

若存在未提交大事务：

• 先与业务确认能否提交/回滚；
• 再处理连接池扩容。

慢 SQL 侧仍用 EXPLAIN 看 Motion、分布键；连接治理解决不了 REDISTRIBUTE 导致的慢，但能避免「CN 已饱和却查不了计划」的双重困境。

六、预防：容量规划与规范

建议在团队内固定几条规范：

1. 新系统上线前：估算峰值 QPS、平均响应时间，反推连接数上限；压测时看 CN Threads_connected 曲线。
2. 批任务：ETL、大导出使用独立账号与连接池，窗口期与在线业务错开。
3. 运维账号：gccli 人工会话用完即断，勿长期挂着导数据。
4. 监控告警：CN 连接数 >80% 持续 5 分钟、Sleep 占比 >60% 持续 15 分钟——两条可组合告警。
5. 定期巡检：每周导出 PROCESSLIST 聚合 Top Host，发现「僵尸应用」提前下线。

小结

GBase 8a 的连接问题，本质是 Coordinator 接入容量与连接池行为 的匹配。SHOW PROCESSLIST 做地图，按 User/Host 找大户；应用侧收池大小、空闲超时与事务边界；止血时先 Query 后 Connection、分批 Kill Sleep。把连接峰值、Sleep 占比与当时 Top SQL 记入案例，下次「连不上」可先排除连接满，再下钻 MPP 计划与锁——少走弯路。