Debezium PostgreSQL初始快照阶段Schema变更无法完成求助

问题现象 #

• Debezium 2.4对接PostgreSQL做CDC时，初始快照阶段：
  • update/delete等行级变更操作正常执行
  • 对table.include.list中的表执行Schema变更（如添加列）时，语句长时间无法完成，且该表无法被访问，直到关闭连接器或快照全部完成后才恢复
• 流式CDC阶段：truncate table、添加列等操作均无阻塞问题
• 官方文档标注PostgreSQL所有快照模式为无锁模式，但实际出现锁阻塞情况

连接器配置 #

{    
    "name": "main-connector-prod-1",    
    "config": {        
        "connector.class": "io.debezium.connector.postgresql.PostgresConnector",        
        "tasks.max": "1",        
        "topic.prefix": "sink-db-main-prod",        
        "metrics.prefix": "sink-db-main-prod",        
        "signal.kafka.topic": "sink-db-main-prod-signal",        
        "signal.data.collection": "public.debezium_signal",        
        "publication.name": "db_main_prod_publication",        
        "slot.name": "db_main_prod",        
        "snapshot.mode": "initial",        
        "database.server.name": "postgres",        
        "database.hostname": "10.148.0.6",        
        "database.port": "***",        
        "database.user": "***",        
        "database.password": "***",        
        "database.server.id": "1",        
        "database.dbname": "***",        
        "table.include.list": "public.***",        
        "heartbeat.interval.ms": "5000",        
        "schema.history.internal.kafka.bootstrap.servers": "kafka:9092",        
        "schema.history.internal.kafka.topic": "schema-changes.inventory",        
        "max.request.size": "104857600",        
        "key.converter": "org.apache.kafka.connect.json.JsonConverter",        
        "key.converter.schemas.enable": "true",        
        "value.converter": "org.apache.kafka.connect.json.JsonConverter",        
        "value.converter.schemas.enable": "true",        
        "plugin.name": "pgoutput",        
        "publication.autocreate.mode": "all_tables",        
        "time.precision.mode": "connect",        
        "max.batch.size": "40960",        
        "max.queue.size": "163840",        
        "offset.flush.timeout.ms": "60000",        
        "offset.flush.interval.ms": "10000",        
        "skipped.operations": "none",        
        "snapshot.fetch.size": "51200",        
        "snapshot.max.threads": "3"    
    }
}

问题根源 #

Debezium的"无锁快照"是指不会主动加排他锁，但实际存在隐性锁竞争：

1. 快照查询的共享锁与Schema变更的排他锁冲突
   pgoutput插件下，Debezium初始快照默认执行SELECT * FROM table FOR SHARE SKIP LOCKED，会获取表的共享锁（SHARE LOCK）。而PostgreSQL的Schema变更操作（如ALTER TABLE ADD COLUMN）需要获取ACCESS EXCLUSIVE锁——这是PostgreSQL最严格的锁级别，会阻塞所有其他锁请求，包括共享锁。当快照线程长时间持有共享锁时，Schema变更会陷入等待，且后续表访问请求也会被阻塞。
2. 并发快照放大锁竞争
   配置中snapshot.max.threads=3，意味着同时有3个线程并行快照不同表，增加了锁持有数量，提升了锁冲突概率。
3. 自动发布的Schema绑定
   publication.autocreate.mode=all_tables让Debezium自动将目标表加入发布对象，快照过程中发布与表Schema绑定，进一步增加了Schema变更时的锁等待概率。

解决方案 #

1. 自定义快照查询，降低锁级别 #

通过snapshot.select.statement.overrides配置移除共享锁，减少锁持有时间：

"snapshot.select.statement.overrides": "public.your_table:SELECT * FROM public.your_table"

注意：去掉FOR SHARE可能导致快照一致性风险（快照期间的变更可能无法被捕获），需结合业务场景评估，或选择在业务低峰期执行快照。

2. 降低快照并发线程数 #

减少同时持有锁的表数量，降低冲突概率：

"snapshot.max.threads": "1"

3. 规避快照期间的Schema变更 #

• 选择业务低峰期启动连接器完成初始快照；
• 先完成快照，再执行Schema变更操作。

4. 临时设置锁超时（应急方案） #

在执行Schema变更前设置锁超时，避免长时间阻塞：

SET lock_timeout = '30s';
ALTER TABLE your_table ADD COLUMN new_col VARCHAR(255);

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