PricingLoginStart free
PostgreSQL Performance & Query Optimization · 课时

发布、订阅与副本标识

配置选择性复制，以及正确进行 UPDATE 和 DELETE 流式复制所需的副本标识。

第 1 / 4 课13 个步骤

发布、订阅与副本标识 是 CoddyKit 上的免费 PostgreSQL Performance & Query Optimization 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 PostgreSQL Performance & Query Optimization 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 PostgreSQL Performance & Query Optimization 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Why Logical Replication for Performance

Physical (streaming) replication ships the entire WAL byte-for-byte to identical replicas. Logical replication instead decodes the WAL into row-level change events (INSERT/UPDATE/DELETE) and streams only the tables you choose.

  • Selective: replicate a hot subset of tables, not the whole cluster.
  • Cross-version & cross-schema: publisher and subscriber can differ in major version and have extra columns or indexes.
  • Performance use cases: offload reporting queries to a read replica, build a slimmer OLAP copy, or shard write traffic.

The two building blocks are a PUBLICATION on the source and a SUBSCRIPTION on the target.

Enabling Logical Decoding

Logical replication requires the WAL to carry enough information to reconstruct rows. Set wal_level = logical on the publisher (a server restart is required).

  • max_wal_senders must allow one slot per subscription plus headroom.
  • max_replication_slots bounds the number of logical slots.

Each subscription consumes one replication slot, which pins WAL on the publisher until the subscriber confirms it. An inactive subscriber can therefore cause unbounded WAL growth.

SHOW wal_level;

ALTER SYSTEM SET wal_level = 'logical';
ALTER SYSTEM SET max_wal_senders = 10;
ALTER SYSTEM SET max_replication_slots = 10;

-- Restart PostgreSQL, then verify
SHOW wal_level;

Creating a Publication

A publication is a named set of changes from one or more tables. You decide which tables and which operations are published.

  • FOR TABLE lists specific tables.
  • FOR ALL TABLES publishes every current and future table (superuser only).
  • publish controls which DML types stream: insert, update, delete, truncate.

Publishing only the operations you need reduces WAL decoding work and network traffic.

CREATE PUBLICATION orders_pub
  FOR TABLE orders, order_items
  WITH (publish = 'insert, update, delete');

-- A reporting feed that ignores deletes entirely
CREATE PUBLICATION analytics_pub
  FOR TABLE orders
  WITH (publish = 'insert, update');

Row and Column Filtering (PG 15+)

PostgreSQL 15 added row filters and column lists to publications, letting you replicate only the slice of data the subscriber needs. This shrinks the replicated dataset and the decoding cost.

  • A WHERE clause filters rows; it may only reference replicated columns.
  • A column list replicates a subset of columns and must include the replica identity columns.

This is ideal for building a lean reporting copy that excludes archived rows or sensitive columns.

-- Only stream active, recent orders, and only chosen columns
CREATE PUBLICATION active_orders_pub
  FOR TABLE orders (id, customer_id, total, status)
    WHERE (status = 'active' AND created_at > '2025-01-01');

Creating a Subscription

On the target server, a SUBSCRIPTION connects to the publisher, creates a replication slot, and starts applying changes. The target tables must already exist with compatible columns.

  • copy_data = true (default) snapshots existing rows first, then streams live changes.
  • Each subscription spawns an apply worker on the subscriber.

The connection string points back to the publisher with a role that has REPLICATION (or is superuser) and can read the published tables.

CREATE SUBSCRIPTION orders_sub
  CONNECTION 'host=pub.db port=5432 dbname=shop user=repl password=secret'
  PUBLICATION orders_pub
  WITH (copy_data = true, create_slot = true, enabled = true);

The Core Problem: Identifying Rows

An INSERT carries the full new row, so the subscriber can simply insert it. But an UPDATE or DELETE must tell the subscriber which existing row to change. That requires the WAL to contain an identifying "old" image of the row.

This identifying image is the replica identity. Without it, the publisher cannot encode the old key values, and the change either fails to apply or is silently dropped.

  • INSERT: needs no replica identity.
  • UPDATE / DELETE: requires a usable replica identity on the published table.

Replica Identity Modes

Every table has a REPLICA IDENTITY setting that controls what old-row data is written to the WAL for UPDATE and DELETE:

  • DEFAULT: logs the columns of the primary key. The usual, efficient choice.
  • USING INDEX: logs the columns of a chosen unique, non-partial, NOT NULL index.
  • FULL: logs the entire old row; the subscriber matches on all columns. Correct but expensive.
  • NOTHING: logs no old image; UPDATE/DELETE on the table then fail to replicate.
ALTER TABLE orders REPLICA IDENTITY DEFAULT;
ALTER TABLE orders REPLICA IDENTITY USING INDEX orders_uniq_idx;
ALTER TABLE orders REPLICA IDENTITY FULL;
ALTER TABLE orders REPLICA IDENTITY NOTHING;

Tables Without a Primary Key

With the DEFAULT replica identity but no primary key, a table effectively behaves like NOTHING: UPDATE and DELETE cannot be replicated. PostgreSQL raises an error such as "cannot update table because it does not have a replica identity and publishes updates".

You have three fixes, in order of preference:

  • Add a primary key (best for performance).
  • Add a unique, NOT NULL index and set REPLICA IDENTITY USING INDEX.
  • Set REPLICA IDENTITY FULL as a last resort.
-- Preferred: give the table a stable key
ALTER TABLE events ADD COLUMN id bigint GENERATED ALWAYS AS IDENTITY;
ALTER TABLE events ADD PRIMARY KEY (id);

-- Or pin an existing unique index as the identity
CREATE UNIQUE INDEX events_key ON events (tenant_id, occurred_at);
ALTER TABLE events REPLICA IDENTITY USING INDEX events_key;

The Cost of REPLICA IDENTITY FULL

REPLICA IDENTITY FULL writes every column of the old row into the WAL on each UPDATE and DELETE. On wide or high-churn tables this inflates WAL volume and slows the publisher.

It also hurts the subscriber: to find the matching row it must compare all columns. Before PostgreSQL 16 this meant a sequential scan per change; PG 16+ can use a usable index on the subscriber, but full-row matching is still costlier than a key lookup.

Use FULL only when no unique key exists and you cannot add one.

Inspecting Replica Identity

The replica identity is stored in pg_class.relreplident: d = default (primary key), i = using index, f = full, n = nothing. Audit your published tables before going live so no UPDATE/DELETE silently fails to replicate.

  • Tables published with update or delete must not have relreplident = 'n' unless they also lack a usable key.
  • psql's \d+ tablename also prints the replica identity.
SELECT n.nspname AS schema,
       c.relname AS table,
       c.relreplident AS replica_identity
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
  AND n.nspname = 'public'
ORDER BY c.relname;

Monitoring Lag and Slot Health

For a performance architecture you must watch replication health. The publisher exposes apply progress via pg_stat_replication, and slot retention via pg_replication_slots.

  • pg_replication_slots.active false plus growing restart_lsn distance means WAL is piling up because a subscriber is stuck.
  • On the subscriber, pg_stat_subscription.latest_end_lsn versus the publisher's current LSN shows apply lag.

Set max_slot_wal_keep_size so a dead subscriber cannot fill the publisher's disk.

SELECT slot_name,
       active,
       wal_status,
       pg_size_pretty(
         pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
       ) AS retained_wal
FROM pg_replication_slots
WHERE slot_type = 'logical';

Quick Check: Replica Identity

A published table needs the right replica identity for UPDATE/DELETE streaming. Test your understanding.

在交互式课程中回答

Recap

You configured selective logical replication and the replica identity that makes UPDATE/DELETE streaming correct.

  • Publisher: wal_level = logical, then CREATE PUBLICATION with chosen tables, operations, and (PG 15+) row/column filters.
  • Subscriber: CREATE SUBSCRIPTION spawns an apply worker and a replication slot; copy_data seeds existing rows.
  • Replica identity: INSERT needs none; UPDATE/DELETE need DEFAULT (primary key), USING INDEX (unique NOT NULL index), or FULL. NOTHING and PK-less DEFAULT break UPDATE/DELETE.
  • Performance: prefer a key-based identity over FULL; monitor slots and lag, and cap retained WAL with max_slot_wal_keep_size.
免费开始

用 AI 导师学习 SQL — 免费

在浏览器中编写并运行真实代码，获得全天候 AI 导师的即时帮助，并在网页或应用中继续学习。

课程
22
课程
88
免费开始学习查看完整课程

常见问题解答

「发布、订阅与副本标识」课时是免费的吗？

是的 — 「发布、订阅与副本标识」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 PostgreSQL Performance & Query Optimization 课程的其余内容，请升级到 CoddyKit PRO。 PostgreSQL Performance & Query Optimization 课程共包含 4 节课。

「发布、订阅与副本标识」这节课中我会学到什么？

配置选择性复制，以及正确进行 UPDATE 和 DELETE 流式复制所需的副本标识。 你通过在浏览器中直接运行的动手代码来练习 PostgreSQL Performance & Query Optimization，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 PostgreSQL Performance & Query Optimization 需要有经验吗？

无需任何先前经验。CoddyKit 上的 PostgreSQL Performance & Query Optimization 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。

「发布、订阅与副本标识」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 PostgreSQL Performance & Query Optimization 课中编写并运行代码吗？

能。每节 PostgreSQL Performance & Query Optimization 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 发布、订阅与副本标识
  2. 卸载读取与分析工作负载
  3. 近乎零停机的主版本升级
  4. 监控复制延迟与复制槽膨胀
← 返回 PostgreSQL Performance & Query Optimization