Kafka JDBC Source Connector不遵循PostgreSQL搜索路径问题求助

我们的PostgreSQL库有两个结构完全一致的schema（如schema1、schema2），部署/迁移时会替换其中一个（删schema1建schema3），始终保留一个备份schema用于回滚。通过全局搜索路径，多数客户端能自动匹配活跃schema，但Kafka JDBC Source Connector无法处理同表名存在于两个schema的情况，用查询模式又丢失了连接器的便捷性，现寻求不改数据库核心操作方式的解决方案。

可行解决方案 #

1. 动态指定带Schema的表白名单 #

• 核心思路：利用连接器的table.whitelist配置支持带Schema前缀的表名，直接限定只同步目标Schema下的表，避免扫描到备份Schema的同名表。
• 操作步骤：
  1. 部署时先确定当前的活跃Schema（比如新创建的schema3）；
  2. 通过Kafka Connect的REST API更新连接器配置：

     curl -X PUT http://<connect-host>:<port>/connectors/<your-connector-name>/config \
       -H "Content-Type: application/json" \
       -d '{
         "table.whitelist": "schema3.table_a,schema3.table_b",
         "connection.url": "jdbc:postgresql://db-host:5432/db-name",
         "mode": "timestamp",
         "timestamp.column.name": "updated_at"
         # 保留其他原有配置
       }'
     

  3. 重启连接器（部分场景下配置更新后自动生效，按需操作）。
• 优势：完全保留连接器的自动同步（全量/增量）能力，无需自定义查询，复杂度低，适配自动化部署流程。

2. 固定Schema+视图层隔离 #

• 核心思路：创建一个固定的中间Schema（比如active_schema），里面只存放指向当前活跃Schema表的视图，让连接器只同步这个固定Schema下的视图，避开多Schema同名表的冲突。
• 操作步骤：
  1. 创建固定Schema和初始视图：

     CREATE SCHEMA IF NOT EXISTS active_schema;
     CREATE VIEW active_schema.table_a AS SELECT * FROM schema1.table_a;
     CREATE VIEW active_schema.table_b AS SELECT * FROM schema1.table_b;
     

  2. 部署替换Schema后，更新视图指向新的活跃Schema：

     DROP VIEW IF EXISTS active_schema.table_a;
     CREATE VIEW active_schema.table_a AS SELECT * FROM schema3.table_a;
     

  3. 连接器配置固定为同步固定Schema的视图：

     "table.whitelist": "active_schema.*"
     

• 优势：连接器配置无需频繁修改，只需在部署时更新视图定义，适合不想改动连接器配置的场景；注意要确保视图结构和底层表完全一致，且支持增量同步所需的字段（如时间戳）。

3. 强制连接器JDBC会话的搜索路径 #

• 核心思路：在连接器的JDBC连接URL中指定仅包含目标活跃Schema的搜索路径，覆盖数据库全局的搜索路径设置，让连接器的JDBC会话只能看到目标Schema的表。
• 操作步骤：
  1. 修改连接器的connection.url，添加search_path参数：

     "connection.url": "jdbc:postgresql://db-host:5432/db-name?options=search_path=schema1"
     

  2. 部署替换Schema后，同样通过REST API更新connection.url中的search_path值为新的活跃Schema（如schema3）。
• 优势：无需修改数据库结构或表白名单，仅调整连接参数即可实现隔离，操作简单直接；官方PostgreSQL JDBC驱动完全支持该参数。

方案选择建议 #

• 如果有成熟的自动化部署流程，优先选方案1或3，只需动态更新连接器配置即可，无需改动数据库；
• 如果希望连接器配置长期固定，优先选方案2，通过视图层做隔离，降低连接器配置变更的风险。

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