PostgreSQL的逻辑复制功能依赖发布端的walsender进程与订阅端的apply进程协同工作。apply进程负责把接收到的逻辑变更重放到目标数据库，当重放过程遭遇唯一约束冲突、数据类型不匹配或权限不足等问题时，该进程默认会记录错误并退出，导致复制中断。从PostgreSQL 13开始引入的logical_replication_restart_on_error参数改变了这一行为，它允许apply进程在出错后自动重启并尝试跳过问题事务，继续处理后续的复制流。
逻辑复制错误恢复机制
在逻辑复制架构中，发布端将事务性变更解析为逻辑日志，通过复制连接发送给订阅端。订阅端的apply进程负责接收这些变更，并将其转换为SQL语句在本地执行。如果执行过程中出现错误，例如插入的数据与已有主键冲突，apply进程会根据logical_replication_restart_on_error的取值决定后续动作。该参数在PostgreSQL 13引入，默认值为off，表示遇到错误后直接退出，订阅状态可能进入禁用或错误状态，需要管理员手动处理。
当参数设置为on时，apply进程在遇到可重试的错误后不会直接退出，而是记录错误信息并关闭当前复制连接。随后它会尝试重新连接发布端，从跳过出错事务之后的LSN位置继续应用后续变更。这种机制可以避免因为偶发的数据冲突导致整个复制链路长时间中断，尤其适合那些对复制延迟敏感、但可以容忍少量数据不一致的场景。需要注意的是，自动重启并不修复错误本身，被跳过的事务不会在订阅端执行，因此发布端和订阅端的数据会出现差异。
查看当前实例中该参数的设置，可以执行以下SQL语句。通过pg_settings视图可以同时确认参数来源，方便判断是配置文件、命令行还是默认值。
SHOW logical_replication_restart_on_error; SELECT name, setting, source FROM pg_settings WHERE name = 'logical_replication_restart_on_error';
配置方法与版本行为差异
最直接的配置方式是在postgresql.conf文件中添加logical_replication_restart_on_error = on，然后通过pg_reload_conf()重载配置文件。也可以使用ALTER SYSTEM命令动态修改，该命令会写入自动配置文件并立即生效。下面的示例展示了全局开启该参数的方法。
ALTER SYSTEM SET logical_replication_restart_on_error = on; SELECT pg_reload_conf();
从PostgreSQL 16开始，该参数可以在订阅级别进行覆盖。这意味着管理员可以为每个订阅单独设置错误重启行为，而不必影响整个实例。在创建订阅时使用WITH子句指定，或者在已有订阅上通过ALTER SUBSCRIPTION修改。订阅级别的设置优先级高于全局设置，当全局为on时，可以通过订阅级off来关闭某个订阅的自动重启。
CREATE SUBSCRIPTION my_sub CONNECTION 'host=192.168.1.100 port=5432 dbname=source user=repl' PUBLICATION my_pub WITH (logical_replication_restart_on_error = off); ALTER SUBSCRIPTION my_sub SET (logical_replication_restart_on_error = on);
版本差异方面，PostgreSQL 13至15中该参数默认关闭，需要管理员手动开启。从PostgreSQL 16开始默认值调整为on，这意味着新部署的逻辑复制环境在遇到数据冲突时会自动跳过错误事务继续运行。这一变化提升了复制链路的可用性，但也增加了数据不一致被忽视的风险。较新版本还引入了pg_subscription_error系统视图，用于记录逻辑复制apply进程遇到的错误历史，方便事后审计。建议在升级或新建环境时明确评估默认行为对业务的影响，并在变更前完成充分测试。
常见错误场景与日志解读
逻辑复制过程中最常见的错误包括唯一约束冲突、外键约束冲突、非空约束冲突、数据类型不匹配以及权限不足等。例如，当发布端插入了一条主键为100的记录，而订阅端已经存在相同主键的记录时，apply进程会收到类似duplicate key value violates unique constraint的错误。类似的还有foreign key constraint violation、null value in column violates not-null constraint等。这些错误通常与两端已有的数据不一致或应用写入顺序有关。
开启自动重启后，数据库日志中会出现明确的提示信息，表明apply进程因错误而重启。下面是一段典型的日志片段，其中包含了错误详情和重启提示。管理员可以通过分析这些日志快速定位问题来源，判断是否属于可接受的跳过场景。
LOG: logical replication apply worker for subscription "my_sub" will restart because of an error ERROR: duplicate key value violates unique constraint "users_pkey" DETAIL: Key (id)=(100) already exists.
借助pg_subscription_error视图可以查询更结构化的错误记录。该视图提供了错误时间、错误消息以及对应的错误LSN，帮助管理员追踪被跳过的事务。执行下面的查询可以获取某个订阅最近的错误信息。如果错误频繁出现，说明跳过事务只是临时掩盖了数据冲突，需要尽快处理根因。
SELECT subname, error_time, error_message, error_lsn FROM pg_subscription_error WHERE subname = 'my_sub' ORDER BY error_time DESC LIMIT 10;
监控与最佳实践
开启logical_replication_restart_on_error后，复制可用性会得到提升，但数据一致性风险也随之增加。管理员应当持续监控pg_stat_subscription视图中的关键字段，例如last_error、last_error_time以及apply进程的状态。当last_error频繁更新时，说明复制链路正在不断跳过错误事务，需要介入处理。
SELECT subname,
pid,
received_lsn,
latest_end_lsn,
last_error,
last_error_time
FROM pg_stat_subscription
WHERE subname = 'my_sub';
对于不同类型的错误，处理策略也应有所不同。约束冲突通常需要比较发布端和订阅端的数据差异，找到冲突记录后人工清理或修复。数据类型不匹配则往往源于表结构变更没有同步，需要在两端保持一致的DDL。权限不足则需要检查复制用户的权限配置。对于已经确认需要跳过的具体事务，可以使用ALTER SUBSCRIPTION ... SKIP命令手动跳过指定LSN，配合自动重启机制实现更精细的控制。
最佳实践建议包括：在测试环境验证参数开启后的表现；为逻辑复制任务配置错误率告警；定期审查pg_subscription_error中的记录；不要长期依赖自动重启来掩盖数据冲突；必要时在应用层增加幂等处理逻辑，降低冲突发生概率。只有将自动重启、监控告警和根因修复结合起来，才能在复制可用性与数据一致性之间取得平衡。
PostgreSQL逻辑复制logical_replication_restart_on_error自动重启修改时间：2026-08-28 08:38:10