逻辑复制过滤策略的核心价值不只是少传几行数据，而是把数据边界固定在复制链路入口。PostgreSQL的发布端可以按表、列和行条件裁剪变更，订阅端则负责应用、校验和审计。安全标签如果只存在于权限系统或元数据中，逻辑复制未必能直接理解，必须投影成可判断的列、视图或策略表达式。
过滤策略要落在发布端还是订阅端
发布端过滤的优势在于从源头减少变更进入复制流。只要表达式在发布端成立，不符合条件的行就不会被发送给订阅端，网络带宽、磁盘写入、订阅端触发器和目标库索引压力都会同步下降。对于租户隔离、数据密级、时间窗口这类相对稳定的规则，把条件写在发布端更直接。例如只发布公开订单，或者只发布某个租户的订单，都可以用 WHERE 条件表达。
CREATE TABLE orders ( id bigint PRIMARY KEY, tenant_id int NOT NULL, classification text NOT NULL DEFAULT 'internal', amount numeric(18,2), status text ); CREATE PUBLICATION pub_orders_filtered FOR TABLE orders WHERE (classification = 'public' AND tenant_id = 42);
订阅端过滤适合做二次兜底，但不能替代发布端过滤。订阅端校验能发现异常数据，比如发布端配置被误改、复制槽恢复后出现历史变更、或者订阅库本身需要额外清洗。问题是敏感数据已经经过网络到达订阅库，安全边界被削弱。对合规要求高的场景，真正敏感的数据不应该进入复制流，而应该在发布端就被截断。
更稳妥的做法是混合策略：发布端负责主过滤，订阅端负责校验和审计。发布端表达式应尽量简单、可解释、可测试，避免把复杂业务逻辑塞进复制过滤条件。订阅端可以检查 classification、tenant_id、status 等字段是否越界，发现异常时拒绝写入并记录告警。这样既能降低复制链路压力，也能保留最后一道防线。
安全标签如何变成可执行的复制条件
PostgreSQL中的安全标签更接近强制访问控制元数据，它描述对象属于哪个安全域、密级或策略上下文。典型用法是通过标签提供程序给表、列、角色等对象打标。但逻辑复制过滤并不是天然读取这些标签来决定是否发布某一行。换句话说，安全标签可以回答谁有权访问对象，却不自动回答某条变更是否允许进入复制流。
-- 需要加载安全标签提供程序后才能执行 SECURITY LABEL ON TABLE orders IS 'system:table:confidential';
要让安全标签参与复制过滤，常见做法是把标签信息投影到真实表的可过滤列上。比如新增 classification 表示公开、内部、机密，新增 replication_allowed 表示是否允许复制。发布端过滤条件直接引用这些列，而不是引用权限系统里的隐式标签。这样过滤逻辑更透明，也更容易用样本数据验证。
ALTER TABLE orders ADD COLUMN replication_allowed boolean GENERATED ALWAYS AS ( classification = 'public' AND tenant_id = 42 ) STORED; CREATE PUBLICATION pub_orders_filtered FOR TABLE orders WHERE (replication_allowed);
行级安全策略和逻辑复制过滤不是同一件事。行级安全主要控制普通查询能看到哪些行，逻辑复制发布端过滤控制哪些变更进入复制流。订阅端用户权限不能自动改变发布端已经决定的复制范围。如果把租户隔离完全交给行级安全，而不写发布端条件，复制链路仍可能把不该同步的数据发出去。正确做法是让行级安全负责查询边界，让复制过滤负责发布边界。
订阅端二次校验与审计闭环怎么设计
订阅端二次校验的重点是识别越界数据。即使发布端配置正确，也可能因为误操作、版本差异、复制槽异常恢复或人工补发数据，导致订阅库收到不满足条件的行。可以在订阅库上增加触发器，对插入和更新做敏感字段检查。发现 classification 不是公开值时，直接拒绝写入。
CREATE FUNCTION reject_sensitive_orders() RETURNS trigger
AS $$
BEGIN
IF NEW.classification <> 'public' THEN
RAISE EXCEPTION '非公开订单禁止写入订阅库';
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER trg_orders_sensitive_check
BEFORE INSERT OR UPDATE ON orders
FOR EACH ROW EXECUTE FUNCTION reject_sensitive_orders();审计日志要记录足够还原现场的信息。建议记录来源表、操作类型、变更载荷、安全标签、写入时间和是否被拦截。这样出现问题时，可以判断是发布端过滤失效、订阅端校验拦截，还是人工导入导致的数据越界。审计表本身也要注意权限控制，避免把敏感载荷明文暴露给普通应用账号。
CREATE TABLE replication_audit ( id bigserial PRIMARY KEY, source_table text, operation text, payload jsonb, classification text, created_at timestamptz DEFAULT now() ); CREATE SUBSCRIPTION sub_orders_filtered CONNECTION 'host=127.0.0.1 port=5432 dbname=orders user=replicator password=replicator_password' PUBLICATION pub_orders_filtered WITH (connect = true, enabled = true);
生产环境还建议把过滤策略配置成可回滚对象。发布、订阅、复制槽、权限和触发器都应纳入变更管理。任何过滤条件修改前，先用测试数据验证边界，尤其是空值、默认值、历史数据、批量更新和删除操作。逻辑复制对删除事件的处理同样需要关注，如果只过滤插入和更新，历史删除仍可能影响订阅端数据一致性。
常见误配与上线前检查清单
第一个常见误配是把列过滤当成安全过滤。只同步部分列确实能减少敏感字段暴露，但如果行级敏感数据仍然进入复制流，风险并没有消失。列过滤适合减少无关字段，行过滤适合控制数据范围。两者需要配合使用，而不是互相替代。对于包含个人身份信息、交易明细、合同条款的表，行级边界必须优先设计。
第二个常见误配是复制角色权限过大。发布端过滤表达式可能依赖某些表或函数，复制角色需要足够权限读取相关对象，但不应拥有任意修改业务数据的权限。订阅端触发器也可能因为权限不足而失败，导致复制延迟。上线前要检查复制角色、对象权限、schema搜索路径、函数执行权限和审计表写入权限。
- 发布列表是否只包含必要表，是否避免整库无边界发布。
- 行过滤条件是否能覆盖租户、密级、状态、时间窗口等关键边界。
- 安全标签是否投影为可执行列，而不是只停留在权限系统里。
- 订阅端是否有二次校验和异常拦截机制。
- 审计日志是否能记录被拦截数据和越界原因。
- 复制槽、延迟、错误日志是否纳入监控。
- 回滚方案是否能在过滤条件错误时快速停止订阅并清理异常数据。
逻辑复制过滤策略真正成熟时，团队应该能回答三个问题：哪些数据允许进入复制流，哪些数据必须在源头截断，哪些数据即使到达订阅端也必须被拦截。把这三个问题落到发布端条件、安全标签投影、订阅端校验和审计闭环上，PostgreSQL逻辑复制才能在效率、一致性和安全之间保持稳定。
PostgreSQL逻辑复制安全标签修改时间：2026-09-07 03:06:18