PostgreSQL数据同步冲突主要发生在主从或逻辑复制中，常见类型包括查询冲突、锁冲突、唯一性冲突及函数执行失败。物理复制可通过开启hot_standby_feedback、设置statement_timeout、监控冲突视图等手段缓解；逻辑复制需监控订阅状态、处理主键冲突、配置ON CONFLICT规则并确保模式一致。预防措施包括避免长查询、优化vacuum、保持主备结构一致及加强日志监控，关键是根据复制类型采取相应策略以保障数据一致性与复制稳定性。
PostgreSQL数据同步冲突通常出现在主从复制（Streaming Replication）或逻辑复制（Logical Replication）环境中，当备库在重放WAL日志或应用变更时遇到与当前数据状态不一致的情况，就会触发复制冲突。这类问题会影响复制延迟甚至导致复制中断。下面介绍常见的冲突类型及对应的处理方法。
1. 复制冲突的常见类型
理解冲突类型是解决问题的第一步：
- 查询冲突（Query Conflict）：长时间运行的查询阻止了恢复进程清理过期数据，导致WAL日志无法回收或应用。
- 锁冲突（Lock Conflict）：备库上的查询持有行级或表级锁，阻碍了主库变更的重放。
- 唯一性冲突（仅逻辑复制）：在逻辑复制中，主备两端插入了相同主键的数据，引发唯一约束冲突。
- 函数或触发器执行失败：逻辑复制中调用的函数在备库不存在或行为不同。
2. 物理复制中的冲突处理
物理复制基于WAL流，冲突主要源于查询阻塞。可通过以下方式缓解：
- 设置hot_standby_feedback = on：开启后，备库会向主库反馈其事务状态，防止主库过早回收仍被备库需要的元组信息，减少因vacuum清理导致的“快照过旧”错误。
- 限制长查询执行时间：通过statement_timeout参数控制查询最大运行时间，避免阻塞恢复进程。
- 调整wal_receiver_timeout和wal_retrieve_retry_interval：在网络不稳定时，适当增加超时时间，避免频繁断连。
- 监控pg_stat_database_conflicts视图：查看因缓冲区、锁、快照等引发的冲突次数，定位问题源头。
3. 逻辑复制中的冲突处理
逻辑复制更灵活但也更容易出现数据一致性问题：
- 监控复制状态：使用pg_stat_subscription查看订阅是否处于异常状态，如failed或高延迟。
- 处理唯一性冲突：当出现主键冲突时，PostgreSQL会暂停复制。可通过pg_replication_origin_advance()跳过冲突事务，或手动修复数据后继续。
- 使用冲突解决规则：在创建订阅时配置ON CONFLICT DO NOTHING等策略，自动处理部分冲突。
- 确保模式一致性：主备库的表结构、索引、约束应保持一致，避免因缺失对象导致应用失败。
4. 预防措施与最佳实践
减少冲突的关键在于合理配置和日常维护：
- 定期清理长期运行的只读事务，尤其是报表类查询。
- 避免在备库执行全表扫描或大范围锁定操作。
- 主库做好vacuum管理，防止膨胀影响复制性能。
- 对逻辑复制，启用日志输出详细错误信息（log_min_messages = warning），便于排查。
- 测试环境模拟故障场景，验证恢复流程。
基本上就这些。关键是要根据复制类型区分对待，物理复制重在资源调度和反馈机制，逻辑复制则需关注数据一致性和异常处理。只要配置得当，多数冲突都能有效避免或快速恢复。
