Ba phần trước đều là streaming replication: chép WAL byte-cho-byte sang một bản sao y hệt, cùng phiên bản, chỉ đọc. Nó không làm được những việc hay bị hỏi tới: chép một bảng sang cụm báo cáo đang chạy schema khác, nâng cấp phiên bản lớn với downtime vài giây, hay gom dữ liệu từ nhiều cụm về một chỗ. Logical replication làm được — bằng cách giải mã WAL thành INSERT/UPDATE/DELETE theo bảng và áp lên một cụm khác. Giá của sự linh hoạt đó là một danh sách những thứ không đi qua đường ống, và mỗi thứ trong danh sách là một cách làm subscription đứng im. Phần này dựng, đo lag so với vật lý, rồi cố tình gây ra từng kiểu đứng để xem lỗi gì và gỡ thế nào.

Chép dòng, không chép byte

Ảnh chụp đoạn mã nền tối logical replication chép dòng không chép byte với PostgreSQL 16 publisher pg-prim wal_level logical sang subscriber pg-sub cụm riêng bảng docs 1 triệu dòng, khác streaming replication ở gốc gồm vật lý chép WAL byte ra bản sao y hệt cả cụm cùng phiên bản chỉ đọc, logic giải mã WAL thành INSERT UPDATE DELETE theo bảng áp lên cụm khác đang chạy việc khác ghi được subscriber cần schema sẵn publisher giữ một replication slot kiểu logical cho mỗi subscription, dựng gồm publisher create publication pub_docs for table docs, subscriber pg_dump s t docs rồi psql DDL tự mang sang, create subscription sub_docs connection host pg-prim dbname lab user lab password publication pub_docs copy_data true chép 1M dòng ban đầu rồi mới stream, theo dõi pg_subscription_rel srsubstate i d s r pg_stat_subscription stats apply_error_count, ba thứ nó không chép và cách chúng làm subscription đứng gồm DDL ADD COLUMN ở publisher subscriber báo missing replicated column worker chết thử lại lag tăng, sequence serial ở publisher tới 1000 ở subscriber vẫn 1 đổi vai là duplicate key ngay dòng đầu, xung đột subscriber tự ghi một PK publisher ghi cùng PK duplicate key worker chết thử lại mãi gỡ bằng sửa dòng ở subscriber hoặc ALTER SUBSCRIPTION SKIP lsn bỏ qua đúng giao dịch đó, đo gì gồm A thời gian chép 1M dòng ban đầu tới trạng thái ready, B lag logic so với lag vật lý dưới cùng tải UPDATE, C một UPDATE 300k dòng một giao dịch subscriber áp mất bao lâu lag lên bao nhiêu, D ADD COLUMN sequence xung đột PK lỗi gì đứng bao lâu gỡ thế nào TRUNCATE có sang không

Hình 1: Publisher giải mã WAL thành thay đổi theo bảng, subscriber áp vào schema của chính nó. DDL, sequence và xung đột không đi qua đường ống này.

Streaming replication chép byte; logical replication chép dòng. Publisher dùng plugin pgoutput đọc WAL (phải có wal_level = logical) và dịch từng thay đổi thành "bảng X: chèn dòng này, sửa dòng kia", gửi qua một replication slot kiểu logical. Subscriber nhận và chạy lại như câu lệnh bình thường trên bảng của nó — bảng đó phải tồn tại trước, cột phải khớp tên và kiểu, và subscriber có thể là phiên bản khác, có index khác, có thêm bảng khác, và ghi được.

Dựng gồm ba lệnh: CREATE PUBLICATION ở publisher, mang schema sang bằng pg_dump -s, và CREATE SUBSCRIPTION ở subscriber. Mặc định copy_data = true: subscriber chép toàn bộ dữ liệu hiện có trước, rồi mới bắt đầu áp thay đổi. Trạng thái theo dõi ở pg_subscription_rel.srsubstate (i khởi tạo → d đang chép → s đồng bộ → r sẵn sàng), lỗi áp đếm ở pg_stat_subscription_stats.apply_error_count.

Danh sách không chép: DDL (không có ALTER TABLE nào đi qua), sequence (giá trị serial không được đồng bộ), và không có cơ chế giải quyết xung đột — subscriber tự ghi một dòng mà publisher cũng ghi là lỗi, và lỗi làm worker chết. Môi trường đo: pg-prim làm publisher (vẫn đang stream vật lý sang pg-rep để so sánh), pg-sub là cụm PostgreSQL 16 mới tinh, bảng docs một triệu dòng, 158 MB.

Đo thật: dựng, lag, giao dịch lớn, và ba cách đứng

Ảnh chụp output thật nền tối 1M dòng sẵn sàng sau 1,2 giây ba cách đứng máy với pg-prim sang pg-sub logical và pg-prim sang pg-rep vật lý đo cùng lúc docs 1 triệu dòng 158 MB, A dựng subscription gồm create subscription publication pub_docs NOTICE created replication slot sub_docs on publisher, srsubstate r ready sau 1185 ms subscriber docs 1000000 dòng 158 MB slot sub_docs plugin pgoutput active, B lag dưới UPDATE 500 dòng mỗi giao dịch nhân 200 trong 20 giây logic và vật lý song song gồm t 5 giây vật lý walreceiver sent trừ replay 0 B 0,001 giây logic sub_docs 0 B 0,002 giây, t 10 giây 0 B 0,002 và 0 B 0,002, t 20 giây 0 B 0,001 và 0 B 0,001 md5 100500 dòng đầu khớp hai bên, C một UPDATE 300000 dòng trong một giao dịch publisher chạy UPDATE 639 ms subscriber áp xong 1836 ms kể từ lúc bắt đầu giao dịch gửi lúc COMMIT một worker áp tuần tự, D ba thứ không sang gồm D1 DDL publisher alter table docs add column tag rồi update docs set tag y where id 1 subscriber ERROR logical replication target relation public.docs is missing replicated column tag apply_error_count 2 pg_stat_subscription không có worker alter table ở subscriber thì id 1 tag y sau 1314 ms, D2 sequence publisher tk 1000 dòng tk_id_seq last_value 1000 subscriber 1000 dòng last_value 1 is_called f ghi vào subscriber như primary mới ERROR duplicate key value violates unique constraint tk_pkey setval tk_id_seq max id bằng 1000 insert kế được id 1001, D3 xung đột PK subscriber có id 5000 trước publisher chèn 5000 rồi 5001 sau 6 giây apply_error_count 2 worker chết chờ restart wal_retrieve_retry_interval 5s 5001 kẹt phía sau 0 dòng CONTEXT for replication target relation public.tk in transaction finished at 6 E313D538 alter subscription sub_tk skip lsn 6 E313D538 thì 5001 sang sau 1862 ms 5000 giữ bản local v trừ 1, D4 TRUNCATE publisher truncate tk subscriber tk 0 dòng có sang, nói thẳng lag 0 B ở B là vì 5000 dòng mỗi giây là tải nhẹ cho một worker C cho thấy giới hạn thật một giao dịch 300k dòng áp mất khoảng 1,2 giây sau commit mỗi lần đứng D1 D3 là lag tăng tới khi có người sửa tay không có cơ chế tự gỡ

Hình 2: Một triệu dòng sẵn sàng sau 1,2 s; lag logic bằng vật lý dưới tải nhẹ; giao dịch 300k dòng áp mất 1,2 s; DDL, sequence và xung đột mỗi thứ một kiểu đứng.

phép đo kết quả
chép 1.000.000 dòng ban đầu tới srsubstate = r 1.185 ms
lag dưới 200 × UPDATE 500 dòng: vật lý / logic 0 B, 1–2 ms / 0 B, 1–2 ms; md5 khớp
UPDATE 300.000 dòng một giao dịch: publisher / subscriber áp xong 639 ms / 1.836 ms
ADD COLUMN ở publisher worker chết, missing replicated column; thêm cột ở subscriber → nối lại sau 1.314 ms
sequence sau 1.000 insert: publisher / subscriber last_value 1.000 / 1; insert đầu ở subscriber: duplicate key
xung đột PK worker chết, thử lại mỗi 5 s, mọi giao dịch sau kẹt; SKIP (lsn) → thông sau 1.862 ms
TRUNCATE có sang

Một triệu dòng sẵn sàng sau 1,2 giây — và từ đó là stream. CREATE SUBSCRIPTION tạo slot sub_docs trên publisher, chép 158 MB bằng COPY nội bộ, và srsubstate chuyển sang r sau 1.185 ms. So với dựng replica vật lý ở phần 5 (961 ms cho 700 MB cả cụm), đây là chép đúng một bảng sang một cụm đang có việc riêng — thứ streaming replication không có khái niệm.

Dưới tải cập nhật nhẹ, logic bám sát y như vật lý. 200 giao dịch, mỗi giao dịch UPDATE 500 dòng, trong 20 giây: cả walreceiver (vật lý) lẫn sub_docs (logic) đều báo sent − replay = 0 B, replay_lag 1–2 ms ở mọi mốc; md5 của 100.500 dòng đầu khớp hai bên. Ở tốc độ 5.000 dòng/giây, một apply worker đuổi kịp dễ dàng; giải mã và áp lại từng dòng không phải nút thắt ở đây.

Giao dịch lớn mới lộ ra khác biệt: 300.000 dòng áp mất 1,2 giây sau commit. Publisher chạy UPDATE 300.000 dòng trong 639 ms; subscriber có đủ dữ liệu ở 1.836 ms — nghĩa là ~1,2 giây lag trong lúc một worker áp 300.000 thay đổi tuần tự, bằng câu lệnh từng dòng. Vật lý trong cùng lúc đó chỉ chép vài chục MB trang. Đây là hình dạng chi phí của logical replication: tỉ lệ với số dòng đổi, không với số byte WAL, và với giao dịch lớn thì toàn bộ lag dồn vào sau commit (PostgreSQL 14+ có streaming = on để gửi giao dịch đang chạy theo từng đoạn, không bật ở đây).

DDL không sang: thêm một cột là worker chết. ALTER TABLE docs ADD COLUMN tag ở publisher, rồi một UPDATE chạm cột đó. Subscriber: logical replication target relation "public.docs" is missing replicated column: "tag", apply_error_count 2, pg_stat_subscription không còn worker — subscription đứng, và sẽ đứng cho tới khi có người làm gì đó. Thêm cột ở subscriber: worker tự khởi động lại, dòng id=1 có tag='y' sau 1.314 ms. Quy tắc vận hành: DDL ở subscriber trước, publisher sau với cột thêm; ngược lại với cột xoá. Không có công cụ nào làm thay — pg_dump -s chỉ là ảnh chụp lúc dựng.

Sequence không sang: đổi vai là duplicate key ở dòng đầu tiên. 1.000 dòng tk chép sang đủ, nhưng tk_id_seq ở subscriber vẫn last_value = 1, is_called = f trong khi publisher ở 1.000. Ngày subscriber lên làm primary (đó là kịch bản nâng cấp phiên bản lớn), INSERT đầu tiên là duplicate key value violates unique constraint "tk_pkey". Sửa bằng setval tới max(id) cho từng sequence — một bước trong runbook cutover mà không có cảnh báo nào nhắc.

Xung đột khoá chính: một dòng kẹt là mọi dòng sau kẹt. Subscriber tự có id = 5000; publisher chèn 5000 rồi 5001. Worker lỗi duplicate key, chết, và vì áp tuần tự theo thứ tự commit, dòng 5001 không bao giờ tới — sau 6 giây vẫn 0 dòng, worker chờ restart theo wal_retrieve_retry_interval = 5s, apply_error_count tăng mỗi vòng. Log CONTEXT cho đúng LSN của giao dịch lỗi (finished at 6/E313D538); ALTER SUBSCRIPTION … SKIP (lsn = …) bỏ qua đúng giao dịch đó và 5001 sang sau 1.862 ms; dòng 5000 giữ bản của subscriber. PostgreSQL 16 không có "ai thắng" tự động: xung đột là việc của người vận hành, và mỗi phút chưa gỡ là một phút lag cộng dồn.

TRUNCATE thì sang. Từ PostgreSQL 11, TRUNCATE được chép như một thay đổi: publisher truncate tk → subscriber 0 dòng. Tiện, và cũng là một lệnh không bị chặn bởi "subscriber ghi được" — bảng báo cáo ai đó đang dùng ở subscriber trống sau một TRUNCATE ở publisher.

Đánh đổi cần cân nhắc

Linh hoạt đổi lấy việc tự lo tính toàn vẹn. Streaming replication không thể sai lệch — nó chép byte. Logical replication có ba chỗ lệch được: schema (DDL), sequence, và dữ liệu ghi hai bên. Mỗi chỗ cần một quy ước vận hành: DDL theo thứ tự, setval khi cutover, và subscriber chỉ-ghi-vào-bảng-không-được-chép. Vi phạm không gây lỗi ồn ào; nó gây lag tăng dần cho tới khi ai đó mở pg_stat_subscription_stats.

Slot logic giữ WAL như slot vật lý. Subscription đứng (D1, D3) là slot trên publisher ngừng tiến — và pg_wal của publisher phình đúng như phần 5 đo, với cùng thuốc max_slot_wal_keep_size. Subscription chết lặng lẽ ở cụm báo cáo có thể làm đầy đĩa cụm sản xuất.

Phạm vi đo. Hai container cùng máy; 5.000 dòng/giây là tải nhẹ, nên lag 0 B là cận dưới; giao dịch lớn mới đại diện cho giới hạn một worker. Chưa chạm: streaming = on và parallel apply (PG16), publication theo cột hoặc WHERE (PG15), và dùng logical replication để nâng cấp 16 → 17.

Ba ý mang về

  1. Logical replication chép dòng của một bảng sang cụm khác: 1.000.000 dòng sẵn sàng sau 1,2 s, lag bằng vật lý dưới tải nhẹ, nhưng chi phí tỉ lệ với số dòng đổi — một giao dịch 300.000 dòng là 1,2 s lag dồn sau commit.
  2. Ba thứ không sang, ba kiểu đứng im: ADD COLUMN giết worker cho tới khi subscriber có cột; sequence đứng ở 1 cho tới setval; xung đột PK kẹt mọi giao dịch sau cho tới SKIP (lsn). Không cái nào tự gỡ, và đứng im nghĩa là slot giữ WAL trên publisher.
  3. Quy ước thay cho cơ chế: DDL ở subscriber trước, setval trong runbook cutover, subscriber không ghi vào bảng được chép — và vẽ apply_error_count lên bảng theo dõi, vì đó là chỗ duy nhất lỗi hiện ra.

Nguồn

Phần sau quay về bên trong một cụm: UPDATE nhiều lần làm bảng phình bao nhiêu, autovacuum có theo kịp không, đo bloat bằng pgstattuple, và wraparound trông như thế nào trước khi nó dừng máy chủ.