PostgreSQL逻辑复制订阅端触发器为何不触发及如何启用

PostgreSQL 的逻辑复制本质上就是数据库自带的一套 publish/subscribe 体系发布端把变更解码成消息订阅端拉回去回放。很多同学第一次在订阅端接表时都会遇到一个奇怪现象——明明写好了触发器复制过来的数据却安安静静触发器一次都不触发。这篇文章就专门聊 PostgreSQL 原生 pub/sub 订阅端触发器的控制问题为什么默认不触发到底用哪条命令才能让触发器在订阅端生效以及我在实际项目里踩过的坑和验证方法。适合正在用逻辑复制做读写分离、数据汇聚或者接手了某个订阅端同步链路并且需要在同步之后继续做加工的人。1. 为什么订阅端的触发器静默失灵认识 apply worker 的角色开关1.1 订阅端回放不是简单的再执行一次 SQL在说触发器之前得先把订阅端的执行链路讲清楚。发布端由 publication 把表上的 INSERT、UPDATE、DELETE 解码成 WAL 中的逻辑变更订阅端通过 subscription 连接发布端拉取这些变更再由本地的 apply worker 进程逐一 apply 到目标表。这个 apply 过程看起来像把丢过来的数据重新插一次但它并不仅仅是重放一条 SQL而是一套独立的执行路径。为什么强调这一点因为很多人在订阅端创建触发器时脑子里的模型是数据进来就会走表上的 INSERT/UPDATE/DELETE那么触发器自然也该跑。实际上逻辑复制的 apply worker 为了保证订阅端是一份干净的副本会主动把当前会话的session_replication_role设置为replica。这个参数不是给用户看的摆设它直接决定了一批数据库对象在本次会话里到底执行不执行。默认情况下普通会话是origin此时表上默认的触发器状态为 origin都会触发。而一旦切到replicaPostgreSQL 的规则就变了只有被显式标记为replica或always的触发器才会被触发普通触发器直接跳过。所以你说触发器失灵其实它根本没坏而是被这套角色开关拦在了外面。顺带一提PostgreSQL 还有另一套轻量级的原生 pub/subLISTEN/NOTIFY。它是异步消息通知不会自动回放数据通常需要自己在触发器或者业务代码里接收通知。它和逻辑复制订阅端是两码事这套通知链路里不存在 apply worker触发器的控制其实就是收到通知后该干什么的问题。我在项目里经常两条链路一起用逻辑复制负责数据落地LISTEN/NOTIFY 负责知会应用层某张表又变了前提是你得先把逻辑复制订阅端的触发器控制明白否则很容易出现数据到了订阅端、应用层却毫不知情的局面。1.2 session_replication_role一个决定触发器生死的开关我是这么理解的session_replication_role 就像一个角色滤镜数据库在执行命令前先看一眼当前会话是什么角色再决定带哪些滤镜的触发器可以出场。取值主要有两个origin表示这是正常的业务会话replica表示当前是复制/回放会话。逻辑复制的 apply worker 启动后会把整条 apply 过程中的会话角色设成 replica所以订阅端的普通触发器全部被忽略。这里还有一层容易忽略的关系触发器本身也有一个 enabled 状态记录在系统表pg_trigger.tgenabled里常见的就是O、R、A、D四种字母。字母O表示该项触发器只在 origin 会话中触发R表示只在 replica 会话中触发A表示无论哪个角色都触发D表示彻底关闭。逻辑复制的订阅端恰恰处于 replica 会话里所以O状态被跳过是设计内行为要让订阅端的触发器真正执行你要做的就是把触发器状态改成R或A。理解了这层对应关系后面的一系列控制命令全部都顺理成章了。1.3 从系统表看懂触发器当前状态上手之前我建议你先学会查状态不然很容易改错对象或者改了没感觉。一条查询就能把某张表上所有用户触发器状态拉出来SELECT tgname, tgenabled FROM pg_trigger WHERE tgrelid orders::regclass AND NOT tgisinternal;看到tgenabled O就知道这个触发器目前只在普通业务会话里触发订阅端复制过来的数据不会碰它。看到R说明已经切换成复制专用看到A就是常驻状态。我在排查问题的时候会先用这条 SQL 确认状态再决定下一步改哪个避免在表很多、触发器也很多的环境里瞎改。2. 让触发器在复制链路生效的三种标记姿势与取舍2.1 最常见的做法ENABLE REPLICA TRIGGER如果你的需求很单纯——只希望复制过来的数据触发触发器本地手工写数据不触发那直接用ALTER TABLE ... ENABLE REPLICA TRIGGER即可。实际操作是在订阅端表上执行ALTER TABLE orders ENABLE REPLICA TRIGGER trg_orders_audit;执行后pg_trigger.tgenabled会从O变成R。此后普通业务连接写这条表照常跳过逻辑复制专属的触发器逻辑复制 apply worker 回放时则会执行这个触发器。这正贴合订阅端最典型的场景报表库、查询库、数仓贴源层的表本地一般不允许业务直接写数据所有的数据都来自发布端所以只对复制事件生效反而最安全。我在真正动手之前会反复确认一点订阅端这张表本地连写入权限到底开了没有。如果订阅端只是纯只读副本REPLICA 基本就是唯一正确选项因为本地没有合法写入路径ALWAYS 和 ORIGIN 都容易在未来被人手动改数据时误触发。如果订阅端本身也承担了一部分写入职责那么再往下看 ALWAYS 的适用场景。2.2 需要本地也触发时ENABLE ALWAYS TRIGGER有些场景是订阅端也要参与写业务而且无论数据来自复制还是来自本地写入都要统一走一段加工逻辑。例如有一列脱敏字段、一列缓存用的冗余字段所有写入路径都不能漏。这时就可以用ALTER TABLE orders ENABLE ALWAYS TRIGGER trg_orders_full;状态变为A后origin 会话和 replica 会话都会触发。但要小心一个副作用如果发布端那台机器上同一张表也有同名逻辑的触发器每当从发布端产生的业务变更在发布端上被触发一次、订阅端回放时又被 ALWAYS 往前推一次两边就会各自执行一遍同样的加工。所以 ALWAYS 不是万灵丹它适合订阅端本地写权限存在且希望行为完全一致的场景。如果只是想让复制过来的数据走加工建议优先走 REPLICA比 ALWAYS 更不容易制造重复动作。2.3 批量开关DISABLE TRIGGER ALL 与 ENABLE REPLICA TRIGGER ALL线上表往往不止一个触发器比如有审计触发器、同步哈希触发器、更新时间触发器。一个个改名字确实费劲我更常用的是批量形式ALTER TABLE orders DISABLE TRIGGER ALL; ALTER TABLE orders ENABLE REPLICA TRIGGER ALL;第一条相当于把表上所有用户触发器关掉第二条把当前所有触发器统一标记成replica。注意一点DISABLE TRIGGER ALL会连同内部约束触发器一起禁用如果订阅端表上还有外键约束复制过程中约束可能会被跳过这个副作用很大。所以我的建议是除非你明确知道这张表没有外键依赖否则尽量按名字精确操作或者先SELECT出触发器清单再决定怎么批量。另一个必须提醒的坑是ALTER TABLE ... ENABLE/DISABLE TRIGGER都会对表加锁在还在接收复制的订阅端上执行意味着从命令开始到结束apply worker 处理到这张表时会一直被阻塞。选择在复制空闲的窗口执行更稳妥。2.4 四种状态的取舍速查目标状态对应命令触发行为典型场景Oorigin 默认ENABLE TRIGGER只普通会话触发订阅端不关心复制事件纯业务触发器RreplicaENABLE REPLICA TRIGGER只复制回放触发订阅端只要同步后加工本地禁止写入AalwaysENABLE ALWAYS TRIGGER两种会话都触发订阅端本地与会话都要统一逻辑DdisabledDISABLE TRIGGER都不触发临时关停某个触发器这个表基本能覆盖日常 90% 的控制需求。真正的复杂度反而在表格之外你要先想清楚订阅端的定位是纯只读副本还是可写业务库这决定了用 R 还是 A再想想表上外键、约束、分区结构这决定了能不能放心用 ALL。3. 发布端 filter 和行级条件在数据源头控制触发范围3.1 发布端 WHERE 过滤从源头减少订阅端需要处理的行触发器控制不只发生在订阅端。发布端可以在创建 publication 时写 WHERE 条件来控制哪些行会被复制例如从 PG15 开始支持发布端行过滤CREATE PUBLICATION pub_orders FOR TABLE orders WHERE (biz_line core);这样订阅端只收到核心业务线的订单变更。从触发器角度看订阅端根本接收不到被过滤掉的行自然也不会触发后续逻辑。好处非常直观复制带宽下降、订阅端 apply 压力下降、触发器里需要判断的数据也少了。如果整个链路就是把某个业务线的数据汇聚到数据仓库这个方式比在订阅端触发器里写条件更干净因为无用数据压根不出门。这里有一个细节经常被忽略发布端 WHERE 过滤只对增量变更生效初始快照阶段同样会按条件筛选但已存在于订阅端、不满足条件的历史数据不会被反向删除。如果你期望以前同步过的旧数据也消失光靠这个过滤是不够的需要在订阅端再安排一次清理任务或者用触发器在符合条件的删除事件到达时做兜底。3.2 触发器函数内部加条件控制粒度更细链路更直观如果不想在生产库动 publication 的 WHERE 条件也可以把控制逻辑下沉到订阅端触发器函数里。比如只想对金额大于某阈值的订单做进一步审计IF NEW.amount 1000 THEN RETURN NEW; END IF;这种写法的好处是改动不用动复制链路完全在订阅端本地完成回滚也是本地回滚。缺点是只控制触发器内部业务要不要执行数据还是照常从发布端传过来了改不了带宽和 apply 压力。所以我的习惯是能把条件放到发布端时放发布端不需要同步的数据尽量不传必须同步但又不想每条都加工时再用触发器内部的 IF 条件做二次过滤。3.3 一个组合案例层级过滤让订阅端触发器负担降到最低某项目要做会员订单的多区域报表主库在中心机房报表库在灾备机房中间用逻辑复制同步订单表。发布端 publication 用WHERE (biz_line core)过滤掉非核心业务线的订单。订阅端在报表库的订单表上建了一个 AFTER INSERT OR UPDATE 触发器里面只关心 status 变成 paid 的记录其余直接 RETURN。这样一来非核心业务线的数据连进报表库的资格都没有核心业务线数据里也只有真正付费的记录才会触发后续的统计逻辑。这个案例想表达的是订阅端触发器不是孤立的控制它可以从发布端、订阅端表结构、触发器函数三个层级分别着手每层控制一部分链路性能才不会都堵在最后那一下。4. 一个从零到可用的实战记录订阅端审计触发器完整落地4.1 场景与表结构我用一套最经典的场景来讲完整落地过程某订单库是发布端某报表库是订阅端orders 表通过逻辑复制同步到报表库。业务方希望在报表库里对 orders 的每次变更留痕于是我在报表库准备了一张审计表 audit_orders_log字段包括操作类型、订单 ID、金额变化、变更时间。目标很明确只要 orders 表在订阅端被复制过来的 INSERT、UPDATE、DELETE 触发就往审计表写一条记录。这套结构很简单但它能覆盖订阅端需要基于同步数据做二次加工的典型需求。4.2 创建触发器并确认默认状态先写一个触发器函数CREATE OR REPLACE FUNCTION fn_orders_audit() RETURNS TRIGGER LANGUAGE plpgsql AS $$ BEGIN INSERT INTO audit_orders_log(tg_op, order_id, amount, changed_at) VALUES (TG_OP, COALESCE(NEW.order_id, OLD.order_id), COALESCE(NEW.amount, OLD.amount), now()); RETURN COALESCE(NEW, OLD); END; $$;然后创建普通触发器CREATE TRIGGER trg_orders_audit AFTER INSERT OR UPDATE OR DELETE ON orders FOR EACH ROW EXECUTE FUNCTION fn_orders_audit();这时去 pg_trigger 里查tgenabled 一定还是 O。此时我故意在发布端插入一条新订单过几秒看报表库 audit_orders_log 是空的这恰好证明了普通触发器在订阅端不生效。很多人在这一步就开始怀疑是不是复制坏了其实复制一切正常只是触发器状态没切。这里有一个经验要强调我一开始把审计触发器设计成 BEFORE因为业务方后来想在触发器里补充一些订阅端本地字段比如入库时间、机器标识。如果只做纯审计用 AFTER 更安全因为此时行已经真正落盘不会因为触发器逻辑把写入数据改坏。BEFORE 触发器适合修改 NEW 里的列再落库AFTER 适合读最终结果做旁路计算。两种都能在订阅端被 REPLICA 标记控制但使用位置要想清楚。4.3 切换 REPLICA 标记并验证关键命令就是ALTER TABLE orders ENABLE REPLICA TRIGGER trg_orders_audit;再次查询pg_trigger.tgenabled看到 R就说明这个触发器已经进入仅复制回放触发的状态。接着回到发布端插入一条 order_id10086、amount199 的订单等待几秒如果数据量大就多等一会再查报表库 audit_orders_logSELECT tg_op, order_id, amount, changed_at FROM audit_orders_log ORDER BY changed_at DESC;能查到一行INSERT 10086 199就说明订阅端触发器真的被触发成功了。整个过程不需要重启订阅、不需要重新创建订阅改动可以随时回滚回滚命令也简单ALTER TABLE orders ENABLE TRIGGER trg_orders_audit;状态从 R 变回 O订阅端复制回来的数据再次进入不触发状态。4.4 实战中的几个验证细节验证阶段最容易踩的坑是没等复制完成就查表。逻辑复制有天然的延迟尤其发布端有大事务或者订阅端有慢查询时几分钟甚至更久都正常。我的做法是先用pg_stat_subscription确认复制到的 LSN 已经超过发布端的最新 LSN或者干脆查询订阅端那行数据本身已经出现后再去看审计表。另一个细节是触发器函数里的now()取的是订阅端本地时间并不是发布端事务的发生时间。审计业务如果要求两边时间一致必须由发布端在业务字段里写一个 insert_time/update_time触发器直接引用业务字段即可。还有一点如果触发器逻辑要用RETURN NEW修改写入订阅端的数据即 BEFORE 触发器里改某列值再落库这个改动只影响订阅端本地表不会反传给发布端也不会再次触发发布端的发布逻辑。所以订阅端做数据补全、脱敏、默认值填充这类需求完全可以在 BEFORE 触发器里随心做但要清楚它不会回流到源头。5. 分区表、重复触发与复制延迟边界条件和避坑清单5.1 订阅端是分区表时触发器最容易装错地方逻辑复制订阅端建成分区表的情况越来越常见尤其是报表库想按时间分区存订单。问题在于分区表上直接建触发器子分区不一定继承。PostgreSQL 的父表触发器天然不会传播到子分区需要为每个分区单独建。你可以在父表上建一个普通触发器但复制事件实际落在哪个分区就可能落在那个分区自己的触发器逻辑上父表的触发器很多时候是空的。项目上也遇到过报表库 orders 是 range 分区表我在父表建好触发器并切了 replica 标记结果插入订单后审计表毫无反应最后挨个查子分区才发现在每个分区上补建触发器、逐个执行ENABLE REPLICA TRIGGER才真正跑起来。如果订阅端分区表还会自动增加新分区新分区创建之后也要同步补触发器这是最容易被忽略的维护点。5.2 本地写入与复制写入并行时如何避免重复加工有些订阅端并不是严格只读的比如报表库允许运维手工修正字段。如果用 ALWAYS 触发器手工 UPDATE 也会触发同一段逻辑可能把统计表重复刷新一遍。这时我习惯在触发器函数内部按会话角色分叉IF current_setting(session_replication_role) replica THEN -- 复制回放带来的变更走复制专属逻辑 ELSE -- 本地手工修改走本地逻辑 END IF;注意current_setting(session_replication_role)返回的是当前连接会话的角色值。apply worker 回放时是 replica普通业务连接是 origin分叉逻辑本身很容易实现。但要注意普通用户不能随意 SET 这个参数所以不用太担心有人临时改角色来绕过触发器。这么做之后ALWAYS 和 REPLICA 的边界就变得不那么重要了只要触发器状态能保证在被期望执行的会话里被触发具体的业务动作再用函数内部的分支去收敛。5.3 触发器开销如何拖慢复制延迟订阅端触发器不是一个免费的钩子。表里每来一条复制变更apply worker 都要额外执行一次函数体里的 SQL。如果这张表每天同步几百万行函数里写了复杂的INSERT、UPDATE、子查询复制延迟会肉眼可见地升高。我自己优化过的一个案例是审计触发器里用了两条 INSERT 写两张审计表还把一次历史汇总放在触发器里做结果复制延迟从秒级变成分钟级。后来把历史汇总改成独立任务只在触发器里写最小化的流水延迟立刻恢复。所以控制订阅端触发器不仅是状态开关也包括性能控制。如果你发现复制延迟异常先停下对触发器的排查是不是函数里做了太重的工作是不是触发器数量太多是不是每条变更都要跨表查询。临时方案是先DISABLE TRIGGER让复制追平再决定是否精简函数逻辑。但禁用期间数据变更不会留痕需要确认业务可以接受这段空窗。5.4 上线前要做的三项检查把订阅端触发器正式上线前我至少会确认三件事。一是触发器函数的健壮性函数内一旦抛异常apply worker 可能不断重试把订阅端复制卡在那里所以函数里要避免对外部不稳定对象的依赖尽量做成单表、无副作用的操作异常路径要么提前在外面兜住要么让异常结果明显可见并人工介入而不是让复制 worker 无限重试。二是权限是否到位触发器函数要访问的表、序列、扩展其权限必须覆盖订阅端连接用户的权限范围否则复制事件一到就报权限错误。三是用最小代价做回归验证不要直接在生产大表上折腾先进测试环境走一遍发布端写数——订阅端查看触发日志的闭环再切生产。5.5 我的最终建议把 PostgreSQL 原生 pub/sub 订阅端的触发器控制讲到底其实就一句话订阅端回放环境的 session_replication_role 是 replica所以默认情况下普通触发器不会执行真正要控制的核心是触发器自身的 enabled 状态。想只让复制事件触发就用 ENABLE REPLICA TRIGGER想全部路径都触发就用 ENABLE ALWAYS TRIGGER想临时关停就 DISABLE TRIGGER。实际项目中我最常用的仍然是 REPLICA因为它最符合订阅端数据由复制链路流入的定位也最不容易造成重复逻辑。每次改完状态我都会立刻查一遍pg_trigger再让发布端写一条测试数据看到审计日志真的出现才算这一单落地。希望这篇文章能把你的订阅端触发器从静默失灵变成指哪打哪。