最新PostgreSQL版本下，单副本逻辑复制高可用的潜在弊端咨询

以下是针对你描述的场景，使用最新版PostgreSQL逻辑复制构建一主一副高可用架构时的核心潜在问题：

• 数据一致性与丢失风险
  逻辑复制默认是异步复制，即便启用同步逻辑复制（PostgreSQL 10+支持），也仅能保证事务提交前复制到订阅端，但主节点突发崩溃时，仍可能存在已提交但未完成同步的事务——这直接违反你“不允许任何数据丢失”的要求。切换前必须手动确认订阅端已追平所有变更，若原主彻底不可用，无法验证LSN位置的话，极易出现数据缺口。

• 切换与回切的操作复杂度极高
  故障切换时，你需要先检查pg_replication_slots中的restart_lsn，对比原主（若可访问）的pg_current_wal_lsn()确认同步状态；原主彻底挂掉时，只能依赖订阅端的日志判断是否追平，操作容错空间极小。回切过程更繁琐：需停掉原主的业务，删除旧的发布/订阅关系，再反向创建新主到原主的发布订阅，全程需人工干预，无自动化流程，极易因操作失误引发数据不一致。

• 逻辑复制槽的管理隐患
  如你所知，订阅端离线时，主节点的WAL会因复制槽被无限保留，可能撑爆磁盘。切换后若未及时清理原主的旧复制槽，原主恢复后会持续保留无用WAL；反向复制时若槽配置不当，也会引发同样的存储问题。此外，复制槽属于节点级资源，切换后原主的槽若未删除，后续重启可能干扰新的复制关系。

• 触发器与复制的兼容性问题
  虽然逻辑复制允许订阅端读写（满足你触发触发器的需求），但需注意：原主的DML变更复制到订阅端后，订阅端的触发器可能重复触发，导致数据重复或逻辑冲突。你需要手动配置ENABLE TRIGGER规则，或用pg_trigger_depth()函数避免递归触发，增加了配置复杂度和出错概率。同时，逻辑复制默认不复制DDL，若主节点执行了DDL，订阅端必须手动同步，否则复制会直接中断。

• 性能开销高于物理复制
  逻辑复制需要主节点将事务解析为逻辑变更（如INSERT/UPDATE语句），CPU和内存开销比物理复制的块级复制高很多；订阅端应用变更时也是逐行处理，同步效率远低于物理复制。高并发场景下，主节点的性能会明显下降，切换后新主（原订阅端）的业务处理能力也可能受限于复制延迟。

• 无原生自动故障切换能力
  PostgreSQL原生逻辑复制没有内置的故障检测和自动切换机制，你需要自行开发监控脚本或依赖开源扩展来实现节点状态检测和自动切换。纯手动操作的话，故障响应时间长，且人为失误概率高，无法满足高可用的快速恢复需求。

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