SubQuery项目中PostgreSQL空闲连接导致应用终止的解决方案

问题背景

在SubQuery项目的查询服务实现中，我们发现了一个与PostgreSQL数据库连接管理相关的重要问题。该问题在特定网络环境下会导致整个查询应用意外终止，特别是在使用服务网格(Service Mesh)架构并配置了Envoy代理的环境中。

问题本质

问题的核心在于SubQuery查询服务对PostgreSQL连接池的使用方式存在两个关键缺陷：

1. SSL配置验证连接未释放：在初始化阶段验证SSL配置时创建的数据库客户端连接，在验证完成后没有被正确释放回连接池。

2. 模式变更监听连接保持：用于监听数据库模式变更的持久连接在空闲状态下会被网络中间件终止，进而导致应用崩溃。

技术细节分析

连接池管理问题

SubQuery使用node-postgres库的Pool类来管理数据库连接。在当前的实现中，当应用启动时，它会创建一个客户端连接来验证SSL配置，但验证后没有调用release()方法将连接归还给连接池。这会导致：

• 连接泄漏，消耗数据库资源
• 在严格的环境中，这些闲置连接会被强制关闭
• 由于没有为独立客户端设置错误处理器，连接中断会导致未捕获的异常

长连接保持问题

为了实现热重载功能，SubQuery创建了一个专门监听模式变更通知的持久连接。这个连接在大多数时间处于空闲状态，仅在有模式变更时才会活跃。在服务网格环境中，这类空闲连接通常会被代理中间件(如Envoy)根据超时设置自动终止。

解决方案

针对SSL验证连接的修复

async function ensurePool(poolConfig: PoolConfig): Promise<Pool> {
  const pgPool = new Pool(poolConfig);
  let pgClient;
  try {
    pgClient = await pgPool.connect();
    // 验证逻辑...
  } catch (e) {
    // 错误处理...
  } finally {
    if (pgClient) {
      pgClient.release();
    }
  }
  return pgPool;
}

这个修改确保无论验证成功与否，客户端连接都会被正确释放。

针对模式监听连接的保持机制

if (!argv['disable-hot-schema']) {
  try {
    const pgClient = await this.pgPool.connect();
    await pgClient.query(`LISTEN "${hashName(dbSchema, 'schema_channel', '_metadata')}"`);

    // 设置心跳机制保持连接活跃
    const keepAliveInterval = setInterval(async () => {
      try {
        await pgClient.query('SELECT 1');
      } catch (err) {
        logger.error('心跳查询失败', err);
      }
    }, KEEP_ALIVE_INTERVAL);

    pgClient.on('notification', (msg) => {
      if (msg.payload === 'schema_updated') {
        void this.schemaListener(dbSchema, options);
      }
    });
  } catch (e) {
    logger.warn('热重载初始化失败', e);
  }
}

这个解决方案通过以下方式确保连接持久性：

1. 定期执行简单查询(SELECT 1)保持连接活跃
2. 心跳间隔可配置，适应不同环境需求
3. 添加了完善的错误处理逻辑

实施建议

1. 心跳间隔配置：建议将心跳间隔设置为略小于网络中间件空闲超时时间的1/2，例如对于1小时超时的Envoy，设置30分钟间隔。

2. 资源清理：在应用关闭时，确保清理所有定时器和释放所有数据库连接。

3. 监控增强：为这些关键连接添加监控指标，便于运维团队及时发现连接问题。

总结

数据库连接管理是分布式系统中的关键环节。SubQuery项目通过这次改进，不仅解决了特定环境下的应用稳定性问题，还提升了整体连接管理的健壮性。这些修改对于任何需要在严格网络环境下运行的PostgreSQL客户端应用都具有参考价值。