Bài 7: Replication & Scale Tầng Đọc

Năm bài trước đều là các lớp đứng trước database. Bài này bước vào chính nó, và câu hỏi đầu tiên là câu rẻ nhất trong toàn bộ series: nếu tỉ lệ đọc trên ghi là 100:1 — con số rất thường gặp — thì chỉ cần thêm bản sao để đọc là đã giải quyết được 99% khối lượng công việc.

Lab của bài này dựng PostgreSQL primary và một read replica thật, có streaming replication. Và phép đo đầu tiên đã cho một con số mình không lường trước: replication lag của lab chỉ 0,557 ms — nhỏ hơn nửa phần nghìn giây — mà tỉ lệ người dùng "ghi rồi đọc lại thấy dữ liệu cũ" vẫn là 87,21%. Lag không cần phải lớn để phá vỡ hệ thống; nó chỉ cần lớn hơn khoảng thời gian giữa lệnh ghi và lệnh đọc của chính người dùng đó.

7.1 Ba mục đích khác nhau, thường bị gộp làm một

"Thêm replica" nghe như một việc, nhưng nó phục vụ ba mục tiêu khác nhau — và ba mục tiêu đó cần ba cấu hình khác nhau. Gộp chúng lại là nguồn gốc của phần lớn thất vọng về replica.

7.2 Cơ chế sao chép, và cái giá của từng mức an toàn

PostgreSQL không sao chép "dữ liệu" mà sao chép WAL (write-ahead log) — dòng nhật ký ghi lại từng thay đổi trước khi nó được áp dụng. Replica nhận dòng đó rồi chạy lại. MySQL gọi là binlog, ý tưởng như nhau.

Điều quan trọng nằm ở một câu hỏi duy nhất: primary trả lời "ghi xong" ở thời điểm nào? Trả lời sớm thì ghi nhanh nhưng có thể mất dữ liệu khi primary chết; trả lời muộn thì an toàn hơn nhưng mỗi lệnh ghi phải chờ replica.

Số liệu trong hình lấy từ pgbench — công cụ đo tải đi kèm sẵn trong mọi bản cài PostgreSQL, không phải cài thêm gì. Nó mở N kết nối, chạy lặp một script SQL trong T giây, rồi báo lại số giao dịch mỗi giây (tps) và độ trễ trung bình của một giao dịch. Ở đây chạy ngay trong container primary với 8 kết nối, 10 giây, và script chỉ gồm một lệnh INSERT — càng ít việc trong giao dịch thì phần còn lại càng gần với chi phí thuần của bước commit, tức đúng thứ mà bốn chế độ đồng bộ làm thay đổi:

cd blog/sysdesign/sysdesign-lab
docker compose --profile replica up -d

# The smallest possible write script
docker compose exec -T postgres sh -c 'echo "INSERT INTO write_load (filler)
  VALUES (repeat(md5(random()::text), 8));" > /tmp/w.sql'

# Switch mode, then measure again. `walreceiver` is the replica's application_name
# in this lab — read it from: SELECT application_name FROM pg_stat_replication;
for cfg in "'':local" "walreceiver:remote_write" \
           "walreceiver:on" "walreceiver:remote_apply"; do
  names="${cfg%%:*}"; mode="${cfg##*:}"
  docker compose exec -T postgres psql -U lab -d lab -q \
    -c "ALTER SYSTEM SET synchronous_standby_names = $names;" \
    -c "ALTER SYSTEM SET synchronous_commit = '$mode';" \
    -c "SELECT pg_reload_conf();"
  echo "== $mode"
  docker compose exec -T postgres pgbench -U lab -d lab -n -f /tmp/w.sql -c 8 -j 2 -T 10
done

7.3 Replication lag và bug mà mọi hệ thống có replica đều gặp

Đây là mục trung tâm của bài. Kịch bản quen thuộc: người dùng đổi ảnh đại diện — lệnh ghi đi vào primary. Trang tải lại — lệnh đọc đi vào replica. Nếu replica chưa kịp áp dụng, họ thấy ảnh cũ và kết luận hệ thống hỏng. Đó là vi phạm read-your-writes: bạn phải luôn đọc được thứ chính bạn vừa ghi.

Hình dưới đặt tên cho hai khoảng thời gian quyết định chuyện này, và hai ký hiệu đó được dùng lại suốt phần còn lại của mục: Δ (delta) là replication lag — replica cần bao lâu để áp dụng xong một thay đổi vừa xảy ra trên primary. ε (epsilon) là khoảng cách giữa lệnh ghi và lệnh đọc kế tiếp của chính người dùng đó. Nếu ε lớn hơn Δ thì replica đã kịp và người dùng thấy dữ liệu mới; nếu ε nhỏ hơn Δ thì họ thấy dữ liệu cũ. Chỉ có vậy — và chú ý rằng cả hai đều là khoảng thời gian, nên cái quyết định là tỉ lệ giữa chúng chứ không phải Δ lớn hay nhỏ.

Lab có endpoint /rww làm đúng hai việc: ghi vào primary (dùng RETURNING version để biết chính xác đã ghi version nào), rồi đọc ngay từ replica. Nếu version đọc ra nhỏ hơn version vừa ghi thì đó là dữ liệu cũ — một điều đo được, không phải cảm nhận. Đây là ε nhỏ nhất có thể: hai lệnh nằm sát nhau trong cùng một request, không có gì xen vào giữa. Ba biến đếm rwwPinned, rwwTotal, rwwStale chính là nguồn của các tỉ lệ trong bảng ngay dưới:

// 1) WRITE to the primary. RETURNING tells us exactly which version we just wrote.
const wrote = await pgPrimary.query(
  `UPDATE profiles SET avatar = 'avatar-v' || (version + 1) || '.png',
                       version = version + 1, updated_at = now()
   WHERE id = ${id} RETURNING version`
);
const wroteVersion = Number(wrote[0] && wrote[0].version);
if (usePin && READ_PIN_MS > 0) readPin.set(id, Date.now() + READ_PIN_MS);

// 2) READ IMMEDIATELY. This is the decisive moment: the replica may not have caught up.
const pinned = usePin && shouldReadPrimary(id, Date.now());
if (pinned) rwwPinned++;
const target = pinned ? pgPrimary : pgReplica;
const read = await target.query(`SELECT version, avatar FROM profiles WHERE id = ${id}`);
const readVersion = Number(read[0] && read[0].version);

rwwTotal++;
// "Stale" is MEASURABLE, not a feeling: reading a version LOWER than the one we
// just wrote is not open to argument.
const stale = readVersion < wroteVersion;
if (stale) rwwStale++;

Bốn cấu hình, mỗi cấu hình 16 kết nối, 12 giây, khoảng 100.000 lượt ghi-rồi-đọc:

Dòng A là dòng đáng dừng lại. Lag 0,557 ms — một con số mà không dashboard nào báo động, và nhiều người sẽ gọi là "gần như không có lag" — vẫn làm 87% lệnh đọc trả về dữ liệu cũ. Vì app ghi rồi đọc ngay trong cùng một request, khoảng cách ε giữa hai lệnh chỉ vài chục microsecond. So với ε đó thì nửa millisecond là rất dài.

Dòng C cho thấy bản vá hoạt động tuyệt đối: 0 trên 98.358 lượt. Và cái giá rẻ đến mức đáng ngạc nhiên — throughput giảm từ 7.547 xuống 7.200, tức 4,6%. Dòng D là đối chứng: cùng cấu hình đó nhưng tắt ghim theo từng request thì tỉ lệ quay lại 100%, chứng minh chính cơ chế ghim là thứ tạo ra khác biệt chứ không phải một thay đổi ngẫu nhiên nào khác.

Bản vá thứ hai: để chính database lo

Có một cách khác, không cần sửa dòng code nào ở tầng app: đặt synchronous_commit = remote_apply. Lúc đó primary chỉ trả lời "ghi xong" sau khi replica đã áp dụng xong, nên mọi lệnh đọc sau đó trên replica đều thấy dữ liệu mới. Đo thật, lag tự nhiên, không ghim gì cả:

Hai bản vá cùng cho 0%, nhưng chúng trả giá ở hai chỗ khác nhau. Ghim ở tầng app chỉ làm chậm đúng những lệnh đọc của người vừa ghi — một phần rất nhỏ lưu lượng. remote_apply làm chậm mọi lệnh ghi trong hệ thống, kể cả của người không bao giờ đọc lại. Đó là lý do bản vá tầng app phổ biến hơn, dù nó cần viết code.

Đo lag cho đúng

PostgreSQL phơi ba loại lag khác nhau, và chỉ một trong ba là con số người đọc thật sự cảm nhận. Script tools/pg-lag.sh trong lab hỏi thẳng primary; dưới đây là phần truy vấn của nó, trích nguyên văn:

# write_lag   time until the replica has WRITTEN the WAL to disk
# flush_lag   time until the replica has FLUSHED it (durable)
# replay_lag  time until the replica has APPLIED it ← THIS is what a reader sees
docker compose exec -T postgres psql -U lab -d lab -x -c "
  SELECT application_name,
         state,
         sync_state,
         pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn))   AS unsent,
         pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)) AS unreplayed,
         COALESCE(write_lag::text,  '-') AS write_lag,
         COALESCE(flush_lag::text,  '-') AS flush_lag,
         COALESCE(replay_lag::text, '-') AS replay_lag
  FROM pg_stat_replication;" 2>/dev/null

Hai cột đầu đáng chú ý: unsent là lượng WAL primary còn chưa gửi đi, còn unreplayed là lượng WAL replica đã nhận nhưng chưa áp dụng. Ba cột lag phía sau bọc trong COALESCE vì PostgreSQL trả về NULL khi chưa có giao dịch nào để đo — và NULL ở đây nghĩa là "chưa biết", không phải "bằng 0".

7.4 Failover và split-brain — tự tay tạo ra thảm hoạ

Khi primary chết, một replica phải được promote lên làm primary mới. Nghe đơn giản, và PostgreSQL làm việc đó bằng đúng một câu lệnh. Vấn đề không nằm ở việc promote, mà ở câu hỏi: làm sao chắc chắn primary cũ đã thật sự chết?

Lab cho phép tái tạo đúng trường hợp tệ nhất. Ta tách mạng replica khỏi primary — mô phỏng một partition, chứ primary vẫn sống và vẫn nhận ghi — rồi promote replica mà không có cơ chế nào đảm bảo primary cũ đã dừng:

cd blog/sysdesign/sysdesign-lab

# Before: the replica is a standby and REFUSES every write
docker compose exec -T postgres-replica \
  psql -U lab -d lab -tAc "SELECT pg_is_in_recovery();"
# t

# 1) CUT THE NETWORK between replica and primary (primary is STILL ALIVE, still writing)
docker network disconnect sysdesign-lab_default sysdesign-lab-postgres-replica-1

# 2) PROMOTE the replica — no fencing, nobody confirmed the old primary is dead
docker compose exec -T postgres-replica \
  psql -U lab -d lab -tAc "SELECT pg_promote(wait => true);"
docker compose exec -T postgres-replica \
  psql -U lab -d lab -tAc "SELECT pg_is_in_recovery();"
# f        ← it is a primary now

# 3) BOTH now accept writes for the SAME row
docker compose exec -T postgres psql -U lab -d lab -tAc \
  "UPDATE profiles SET avatar='tu-PRIMARY-CU.png', version=version+100
   WHERE id=500 RETURNING version, avatar;"
# 762|tu-PRIMARY-CU.png
docker compose exec -T postgres-replica psql -U lab -d lab -tAc \
  "UPDATE profiles SET avatar='tu-PRIMARY-MOI.png', version=version+200
   WHERE id=500 RETURNING version, avatar;"
# 862|tu-PRIMARY-MOI.png

# 4) Reconnect the network. Can it reconcile itself?
docker network connect sysdesign-lab_default sysdesign-lab-postgres-replica-1
docker compose logs postgres-replica | tail -4
# LOG:  selected new timeline ID: 2
# LOG:  archive recovery complete
# LOG:  database system is ready to accept connections

Kết quả: cùng một dòng id=500, primary cũ có 762 | tu-PRIMARY-CU.png, primary mới có 862 | tu-PRIMARY-MOI.png (hai chuỗi đó chỉ là nhãn do chính lệnh ghi đặt, để nhìn ra ngay dòng nào đến từ node nào). Dữ liệu đã phân kỳ. Và nối lại mạng không hoà giải gì cả — dòng log selected new timeline ID: 2 là chính PostgreSQL nói với bạn rằng lịch sử đã phân nhánh thành hai.

7.5 Vận hành: theo dõi cái gì, và mâu thuẫn kinh điển

Replica là thành phần dễ bị bỏ quên nhất trong hệ thống, vì khi nó hoạt động thì không ai thấy nó, và khi nó chậm thì triệu chứng xuất hiện ở nơi khác hoàn toàn — người dùng báo "dữ liệu sai" chứ không ai báo "replica chậm".

Tự làm lại các phép đo

cd blog/sysdesign/sysdesign-lab
docker compose --profile replica up -d   # real primary + replica, streaming replication

# Check that replication is actually running
./tools/pg-lag.sh
docker compose exec -T postgres-replica \
  psql -U lab -d lab -tAc "SELECT count(*) FROM profiles;"                    # 1000
docker compose exec -T postgres-replica \
  psql -U lab -d lab -tAc "UPDATE profiles SET version=99 WHERE id=1;"
# ERROR: cannot execute UPDATE in a read-only transaction  ← correct, replica is read-only

# --- A: stale-read rate at the NATURAL lag ---
./tools/cache-stats.sh reset
docker compose run --rm loadgen loadgen.js \
  --url "http://lb:8080/rww" -c 16 -d 12 -w 2 --json
./tools/cache-stats.sh          # look at the READ-YOUR-WRITES line

# --- B: force a CONTROLLED 200ms lag, simulating a replica in another region ---
docker compose exec -T postgres-replica psql -U lab -d lab \
  -c "ALTER SYSTEM SET recovery_min_apply_delay = '200ms';" -c "SELECT pg_reload_conf();"
./tools/cache-stats.sh reset
docker compose run --rm loadgen loadgen.js \
  --url "http://lb:8080/rww" -c 16 -d 12 -w 2 --json
./tools/cache-stats.sh          # 100%

# --- C: turn the pin-to-primary mechanism on ---
# set READ_PIN_MS to '500' for app1/app2/app3 in docker-compose.yml, then:
docker compose --profile replica up -d --force-recreate app1 app2 app3
./tools/cache-stats.sh reset
docker compose run --rm loadgen loadgen.js \
  --url "http://lb:8080/rww" -c 16 -d 12 -w 2 --json
./tools/cache-stats.sh          # 0%

# --- D: control run. Same pinned setup, but ?pin=0 disables the pin per request,
#        which proves the pin is what made the difference and not something else.
./tools/cache-stats.sh reset
docker compose run --rm loadgen loadgen.js \
  --url "http://lb:8080/rww?pin=0" -c 16 -d 12 -w 2 --json
./tools/cache-stats.sh          # back to 100%

# Restore the default
docker compose exec -T postgres-replica psql -U lab -d lab \
  -c "ALTER SYSTEM SET recovery_min_apply_delay = '0';" -c "SELECT pg_reload_conf();"

Tóm lại

Replica phục vụ ba mục đích khác nhau cần ba cấu hình khác nhau, và replica không phải backup — trong lab, bạn có 0,557 ms để hối hận về một lệnh xoá sai. Chọn mức đồng bộ là chọn một điểm trên trục durability ↔ độ trễ ghi: từ async lên sync, độ trễ ghi tăng 79% và throughput ghi giảm 44%.

Bài học lớn nhất là dòng A của bảng ở mục 7.3. Replication lag 0,557 ms — con số mà mọi dashboard sẽ hiển thị màu xanh — vẫn phá vỡ read-your-writes trong 87% lệnh đọc. Vì điều quyết định không phải lag lớn hay nhỏ, mà là lag có lớn hơn khoảng cách giữa lệnh ghi và lệnh đọc của chính người dùng đó hay không. Trong một request web, khoảng cách đó tính bằng microsecond.

Hai bản vá đều cho đúng 0%: ghim đọc về primary (tầng app, −4,6% throughput) và synchronous_commit = remote_apply (tầng database, −12,6%). Chúng khác nhau ở chỗ trả giá: bản vá tầng app chỉ làm chậm người vừa ghi, còn bản vá tầng database làm chậm mọi lệnh ghi trong hệ thống.

Bài 8 đặt câu hỏi mà replica không trả lời được: khi chính lệnh ghi vượt quá sức một máy, hoặc khi dữ liệu không còn vừa một ổ đĩa. Đó là lúc phải sharding — bước đắt nhất về độ phức tạp trong toàn bộ series, và cũng là bước dễ làm quá sớm nhất.