PostgreSQL备库日志出现database system identifier differs between the primary and standby，WAL接收进程会拒绝继续复制。它说明主库与备库的数据目录来自不同集群身份。
不能通过修改连接重试次数或跳过检查解决。
系统标识为什么必须一致
PostgreSQL在初始化集群时生成系统标识。官方WAL接收代码会比较主库和备库标识，只有相同谱系才能继续接收WAL；标识不同意味着日志不能安全应用到当前数据目录。
这是一项防止跨集群写坏数据的完整性检查。
先排除连接到了错误主库
检查primary_conninfo中的主机、端口、DNS和负载均衡目标，确认没有指向测试库、旧主库或故障切换前的地址。多集群共用代理时，还应核对代理后端。
不要仅凭数据库名相同判断是同一集群。数据库名可以重复，系统标识才代表集群身份。
读取两端系统标识
在停机或只读检查条件下，可使用与版本匹配的pg_controldata读取数据目录控制信息；主库也可通过官方支持的工具与视图确认实例身份。记录两端版本、时间线和数据目录路径。
工具版本必须与数据目录主版本匹配。不要手工编辑pg_control或伪造标识。
何时需要重建备库
若备库来自错误基础备份，通常应保存诊断信息、确认主库健康后，清理或隔离旧备库目录，并用正确主库重新获取基础备份。若发生故障切换，还要先确认当前权威主库和时间线。
可在萤光云或LightNode的独立VPS演练重建。重建会替换备库数据目录，必须先确认没有未保存的独立数据。
恢复复制后的验收
启动备库后检查WAL接收状态、复制延迟和时间线，确认主库能看到对应复制连接。随后验证只读查询，并演练重启后的自动恢复。
验收标准是系统标识匹配、WAL持续接收、延迟可控且备库保持只读角色。
FAQ
问：把system identifier改成主库的值可以吗？答：不可以。标识背后还有完整WAL历史，手工伪造会破坏一致性。
问：复制槽能解决这个错误吗？答：复制槽负责保留WAL，不能让不同集群的数据目录变成同一谱系。
温馨提示
温馨提示：主备切换和重建前应明确权威主库，保存配置、时间线与备份记录，避免把旧主库误接回生产复制链路。
