PostgreSQL13逻辑复制数据不同步：subsynccommit为off是否合理？

subsynccommit参数说明 #

subsynccommit = off是合理配置，无需开启。这个参数控制订阅端是否等待事务提交到同步副本（仅适用于同步复制架构），和逻辑复制的增量数据同步没有直接关联，不是导致新增数据不同步的原因。

排查及解决步骤 #

• 检查发布端复制流状态
  在发布端执行以下查询，确认复制槽的运行状态：

  SELECT slot_name, state, sent_lsn, write_lsn, flush_lsn, replay_lsn FROM pg_stat_replication;
  

  重点关注目标槽（lib1、core1）的state是否为streaming，以及各LSN值是否随发布端数据写入持续增长。如果状态异常或LSN停滞，说明发布端未正常发送wal日志。

• 检查订阅端复制进程状态
  在订阅端执行查询，验证订阅进程是否正常运行：

  SELECT subname, status, received_lsn, latest_end_lsn FROM pg_stat_subscription;
  

  若status不为streaming，或received_lsn长时间未更新，说明订阅端进程未正常接收数据。

• 验证发布对象范围
  确认发布rdwh_dev包含了新增数据的目标表：

  SELECT * FROM pg_publication_tables WHERE pubname = 'rdwh_dev';
  

  如果目标表不在列表中，需将其添加到发布中：

  ALTER PUBLICATION rdwh_dev ADD TABLE 目标表名;
  

• 检查复制槽活性
  在发布端查询复制槽的激活状态：

  SELECT slot_name, active, restart_lsn FROM pg_replication_slots WHERE slot_name IN ('lib1', 'core1');
  

  若active为f，说明订阅端未正常连接到发布端，需排查网络或订阅配置。

• 排查网络与连接
  在订阅端测试与发布端数据库的连通性：

  psql -h 发布端IP地址 -U 订阅用户 -d 发布端数据库名
  

  若连接失败，需检查防火墙规则、数据库pg_hba.conf配置，确保订阅端IP被允许访问发布端数据库。

• 重启订阅进程
  尝试禁用并重新启用订阅，触发连接重建：

  -- 针对lib1订阅
  ALTER SUBSCRIPTION lib1 DISABLE;
  ALTER SUBSCRIPTION lib1 ENABLE;
  
  -- 针对core1订阅
  ALTER SUBSCRIPTION core1 DISABLE;
  ALTER SUBSCRIPTION core1 ENABLE;
  

• 查看详细日志
  临时调整日志级别获取更多信息：

  • 发布端修改postgresql.conf：

    log_replication_commands = on
    log_min_messages = debug1
    

  • 订阅端修改postgresql.conf：

    log_statement = 'all'
    log_min_messages = debug1
    

  重启数据库后插入测试数据，查看日志中是否有复制相关的错误或异常信息。

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