关于Kafka JDBC Source Connector连接Redshift时活跃会话无法自动关闭的问题咨询

我之前处理过类似的问题，而且在社区里不少开发者都反馈过这个情况——Kafka JDBC Source Connector连接Redshift时，确实容易出现连接器删除后活跃会话仍残留的问题，本质是连接池的资源没有被正确回收。

有没有其他用户遇到过？ #

肯定有！在Confluent Community和Stack Overflow上都有不少相关提问，核心原因都是JDBC Connector依赖的HikariCP连接池默认配置和Redshift的会话机制不匹配，导致连接器销毁时连接池没有主动关闭所有空闲连接。

可用的配置项限制这个行为 #

你可以在连接器配置中添加以下连接池相关参数，强制控制连接的生命周期和数量：

• connection.max.idle.ms：设置空闲连接的最大存活时长，超过这个时间的空闲连接会被自动回收。建议设为300000（5分钟），避免空闲连接长期占用会话。
• connection.max.lifetime.ms：设置每个连接的最大生命周期，不管是否被使用，到时间就强制关闭。推荐设为1800000（30分钟），防止连接长期驻留。
• connection.pool.size：限制连接池的最大连接数，避免单个连接器创建过多会话。根据你的单表同步负载，设为5-10足够。

把这些参数添加到你的连接器配置里，修改后的配置示例：

{
  "name": "test-conn",
  "config": {
    "connector.class": "io.confluent.connect.jdbc.JdbcSourceConnector",
    "connection.url": "jdbc:redshift://ec2-32-93-33-143.us-east-2.compute.amazonaws.com:5444/testdb",
    "connection.user": "",
    "connection.password": "",
    "key.converter": "org.apache.kafka.connect.storage.StringConverter",
    "key.converter.schemas.enable": "false",
    "errors.retry.delay.max.ms": "60000",
    "errors.tolerance": "none",
    "errors.log.enable": "true",
    "errors.log.include.messages": "true",
    "validate.non.null": "false",
    "poll.interval.ms": "300000",
    "batch.max.rows": "10000",
    "table.whitelist": "input_table",
    "schema.pattern": "input_schema",
    "mode": "timestamp+incrementing",
    "incrementing.column.name": "id",
    "timestamp.column.name": "time",
    "value.converter":"org.apache.kafka.connect.json.JsonConverter",
    "value.converter.schemas.enable": "false",
    // 新增连接池配置
    "connection.max.idle.ms": "300000",
    "connection.max.lifetime.ms": "1800000",
    "connection.pool.size": "5"
  }
}

解决现有残留会话的方法 #

如果已经有未关闭的会话，你可以通过Redshift的SQL命令手动清理：

1. 先查询当前的活跃/空闲会话，确认哪些是连接器残留的：

SELECT pid, user_name, db_name, state, starttime 
FROM STV_SESSIONS 
WHERE user_name = 'your_connection_user' -- 替换成你的连接用户名
AND state = 'idle'; -- 筛选空闲会话

2. 确认后手动终止这些会话：

SELECT pg_terminate_backend(pid) 
FROM STV_SESSIONS 
WHERE user_name = 'your_connection_user' 
AND state = 'idle';

另外还要注意：删除连接器时，尽量通过Connect的REST API或者Confluent Control Center正常删除，避免直接杀死Connect进程——强制终止会导致连接池的关闭钩子无法触发，更易出现会话泄漏。

内容的提问来源于stack exchange，提问作者RandomUser