Durability (P2/3): Lab majority và phía đọc

Ở phần trước: w: 1 chỉ đợi primary, nên acknowledged: true chưa đủ để coi dữ liệu là an toàn. Lệnh majority bị timeout vẫn có thể nằm trên primary: lab 2 đọc được đơn hàng ngay sau lỗi đó.

• Cần đọc trước: Write concern và ba lab đầu
• Dẫn tới: Retryable, chọn mức theo dữ liệu

Lab 3: majority bảo vệ điều gì

Câu hỏi: w: 1 nhận acknowledged: true, rồi primary mất. Lệnh ghi đi đâu? Kịch bản (e3-rollback.sh, chạy 3 lần):

1. ghi T-M với w:"majority" khi cả ba node khoẻ                    → có trên ít nhất 2 node
2. "cắt dây": chuyển primary a sang một Docker network khác        → a không còn thấy b và c
3. ghi T-W1 với w:1 vào a                                          → acknowledged
4. ghi T-WM với w:"majority", wtimeout 1500 vào a                  → timeout, chưa có đa số
5. docker kill a
6. b và c bầu primary mới, ghi T-AFTER với w:"majority"
7. khởi động lại a, nối lại network: a trở về làm secondary

Lần thử đầu tôi dùng docker pause cho hai secondary thay vì cắt mạng, và kết quả sai bài toán: primary mới vẫn có T-W1 và T-WM (e3-pause-attempt.out). [suy luận] docker pause đóng băng tiến trình chứ không đóng băng mạng của kernel; nhiều khả năng dữ liệu đã nằm sẵn trong bộ đệm mạng của hai secondary, nên chúng đọc được sau khi tỉnh dậy, kể cả khi primary đã bị kill. Lab không kiểm tra riêng điều này. Muốn mô phỏng "chưa kịp chép" phải cắt đường mạng thật; mô phỏng sai là cách nhanh nhất để tin w: 1 an toàn hơn thực tế.

[quan sát] Trial 1 (e3-rollback.out; trial 2 và 3 trong e3-rollback-t2.out, e3-rollback-t3.out cho cùng kết quả):

3. w:1 insert  acknowledged: true after 5 ms
4. w:majority insert -> WriteConcernTimeout after 1515 ms (not acknowledged)
   old primary a, read local   : ["T1-M","T1-W1","T1-WM"]
   old primary a, read majority: ["T1-M"]
5. docker kill a
6. new primary elected among b,c after ~1 s: mongo-rs18-c:27017
   new primary read (local): ["T1-M"]
8. final read (majority): ["T1-AFTER","T1-M"]
   node a (direct, local read): ["T1-AFTER","T1-M"]

w: 1 trả acknowledged: true sau 5 ms (4–5 ms ở cả ba trial), nhưng node mới lên không có T1-W1; khi a quay lại, nó cũng không giữ: dữ liệu của nó bị kéo về cho khớp với lịch sử của đa số. Lệnh majority đã xác nhận lúc cả cụm khoẻ (T1-M) sống sót. Ngay cả lệnh w: "majority" bị timeout cũng mất.

Đây là rollback, và nó không xoá âm thầm. [quan sát] bsondump cho thấy mỗi trial để lại một file /data/db/rollback/<collectionUUID>/removed.<timestamp>.bson chứa đúng hai document bị cuốn đi (e3-bsondump.out); log của a ghi Operations reverted by rollback với insert: 2, rollback của trial 1 kéo dài 152 ms.

== .../removed.2026-10-09T07-25-13.1.bson
{"_id":"T1-W1","note":"w:1"}
{"_id":"T1-WM","note":"w:majority wtimeout"}

[tài liệu] File rollback mặc định được tạo (createRollbackDataFiles), nhưng không chứa thao tác xoá document hay drop collection. Tài liệu cũng khuyên dùng w: "majority" để tránh rollback dữ liệu đã xác nhận, và nói rõ dữ liệu của transaction commit bằng w: 1 cũng có thể bị rollback: lý do bài Transactions commit bằng majority.

w:1          acknowledged ✓ → mất ✗   (lab: 3/3 trial)
w:majority   timeout       → mất ✗   (chưa có đa số: vẫn có thể bị rollback)
w:majority   acknowledged ✓ → còn ✓   (lab: T-M, 3/3 trial)

Không phải "primary sập là mất dữ liệu": mất xảy ra với lệnh ghi chưa tới đa số lúc primary biến mất, và lab cố tình dựng khoảng hở đó. [tài liệu] Rollback không xảy ra nếu lệnh ghi đã kịp tới một member khác và member đó vẫn liên lạc được với đa số; một lệnh w: 1 thường được chép đi rất nhanh, nhưng w: 1 không hứa điều đó. Còn timeout vừa không phải thất bại (lab 2) vừa không phải an toàn. Thứ tự sự kiện bên trong cụm (ai bầu ai, điểm chung của rollback tìm ra sao, majority commit point nhích thế nào) là chuyện của bài Elections, Failover & Majority.

Phía đọc: đọc lại lệnh ghi của chính mình

Write concern nói về độ bền của lệnh ghi. Nhưng ứng dụng còn một câu hỏi khác: ghi xong, đọc lại có thấy không? Câu trả lời phụ thuộc vào hai thứ ghép lại: đọc ở đâu và đọc với mức nào.

readPreference    = đọc TỪ ĐÂU      (primary, secondary, nearest...)
read concern      = đọc ở MỨC AN TOÀN nào  (local, majority, snapshot...)
causal consistency = đọc theo THỨ TỰ nào    (sau lệnh ghi của tôi, sau lần đọc trước của tôi)

Lab 4a: read concern majority không đi một mình

[tài liệu] "majority" bảo đảm dữ liệu đọc ra đã được đa số xác nhận và không bị rollback, và hiệu năng ngang các mức khác (lab của bài Isolation cũng đo vậy). Trang tài liệu nói thêm: "dù ở mức nào, dữ liệu mới nhất trên một node không nhất thiết là phiên bản mới nhất của hệ thống". Trong transaction, majority chỉ có hiệu lực nếu commit bằng w: "majority".

Câu hỏi cho ứng dụng: nếu ghi bằng w: 1 rồi đọc majority ngay trên primary, có thấy lệnh ghi của mình không? [quan sát] e4b-majority-primary.out, 500 lần mỗi cách, đọc ngay sau khi nhận acknowledged:

primary: insertOne w:1        then find(readConcern majority) at once: not visible 498 / 500
primary: insertOne w:majority then find(readConcern majority) at once: not visible   0 / 500

Với w: 1, 498 trên 500 lần đọc majority ngay sau đó không thấy document vừa ghi, dù cùng một client, cùng một node. Với w: "majority" thì 0 trên 500. [suy luận] w: 1 trả lời trước khi majority commit point kịp nhích qua lệnh ghi (nhanh 0,2 ms so với 0,6 ms ở lab 1), còn w: "majority" chỉ trả lời khi nó đã nhích. Quy tắc dễ nhớ: muốn đọc majority thấy lệnh ghi của mình thì ghi cũng phải majority.

Lab 4b: đọc từ một secondary đã lệch

Replication bất đồng bộ, nên secondary luôn chậm hơn primary một chút. [tài liệu] Có một chi tiết theo phiên bản làm khe hở này tồn tại cả khi không có lag bất thường: từ MongoDB 8.0, w: "majority" trả lời khi đa số node đã ghi bền oplog entry, còn việc áp dụng vào collection diễn ra bất đồng bộ sau đó. Tài liệu viết thẳng: truy vấn trên secondary ngay sau một lệnh ghi majority có thể đọc trước khi secondary áp dụng, và nếu cần thấy ngay thì chạy trong session nhất quán nhân quả.

Để nhìn rõ khe hở đó, tôi phóng đại nó có chủ đích: đặt priority: 0 và secondaryDelaySecs: 1 cho c (e4-setup.js), tức c áp dụng mọi lệnh ghi trễ 1 giây. w: "majority" vẫn được a và b xác nhận ngay. Độ trễ này là tham số của lab, chọn để khe hở đủ lớn mà đo, không phải độ lệch điển hình của một secondary khoẻ.

Một phát hiện phụ quyết định cách dựng lab (e4a-hello.out):

hello on primary: hosts = ["mongo-rs18-a:27017","mongo-rs18-b:27017"] passives =
20 reads with readPreference secondary landed on 1 distinct host(s): ed9963a7df5d
hostname of b: ed9963a7df5d | hostname of c: eda8e0ee60d4

[quan sát] Primary không liệt kê c cho client, và 20 lần đọc readPreference: secondary chỉ rơi vào b. [suy luận] Driver không thấy member delayed nên không route tới nó. Vì vậy lab nối thẳng vào c (directConnection=true) để đọc, còn ghi đi qua replica set. Đó là điều kiện lab, không phải khuyến nghị.

Mỗi lần ghi một document với w: "majority" rồi ngay sau đó đọc đúng document ấy từ c, 30 lần mỗi cách (e4-causal.js, e4-causal.out):

Ba hàng đầu trả kết quả trống trong tối đa 1 ms: nhanh và sai. Ở D và E mỗi lần đọc chờ đúng khoảng c còn thiếu rồi trả kết quả đúng. Read concern majority không giúp (hàng B): nó hứa dữ liệu an toàn, không hứa dữ liệu mới tới mức bạn vừa ghi. Thứ giúp là causal consistency, và nó giúp bằng cách chờ.

Causal consistency

Causal consistency hứa: nếu thao tác B xảy ra sau thao tác A trong cùng một chuỗi nhân quả (cùng session), B không bao giờ thấy trạng thái cũ hơn A. Tài liệu liệt kê bốn lời hứa: read your writes, monotonic reads (lần đọc sau không cũ hơn lần đọc trước), monotonic writes và writes follow reads.

Cơ chế, hình dung bằng một "phiếu hẹn giờ": mỗi lệnh ghi trả về mốc operationTime; session nhớ nó; lần đọc sau mang mốc đó trong read concern dưới tên afterClusterTime, nghĩa là "chỉ trả lời khi dữ liệu đã tới mốc này". Node chưa tới thì chờ.

ghi (w: "majority")           đọc
   │ operationTime = T          │ readConcern: { level: "majority", afterClusterTime: T }
   ▼                            ▼
 primary ──────────────────► secondary c
                               ├── đã áp dụng tới T?  có   → trả ngay
                               └──                     chưa  → CHỜ tới khi tới T (hoặc hết maxTimeMS)

[quan sát] Làm thủ công, không qua session (e4-causal.out, e4c-maxtime.out):

find on c without afterClusterTime       : 0 docs in 4 ms
find on c with afterClusterTime = opTime : 1 docs in 999 ms
find on c, afterClusterTime, maxTimeMS 300: MaxTimeMSExpired code 50 after 304 ms

Không có afterClusterTime: 0 document sau 4 ms (nhanh và sai). Có: 1 document sau 999 ms (xấp xỉ khoảng lệch 1 giây). Cho ít thời gian hơn khoảng lệch thì MaxTimeMSExpired. Nên một lần đọc nhân quả ở secondary đang lag là một lần đọc chờ, và ứng dụng nên đặt maxTimeMS.

Lab dùng hai client nên phải báo mốc cho session người đọc bằng tay (advanceOperationTime, advanceClusterTime). Trong ứng dụng thường, một session trên một client lo việc đó: ghi và đọc qua cùng session có causalConsistency: true, driver tự đính afterClusterTime.

[tài liệu] Chỉ tổ hợp majority + majority bảo đảm cả bốn lời hứa, kể cả khi mạng chia và hai node cùng tưởng mình là primary; w: 1 cho tính nhân quả không có độ bền. Lab chỉ chạy khi không có sự cố, nên mọi hàng có session nhân quả, cả hai hàng w: 1 trong output (F, G), đều 30/30: đừng đọc đó là bảo đảm. Trường hợp failover xen giữa chuỗi đọc ghi lab không kiểm tra; nó dựa vào tài liệu và bài Elections, Failover & Majority.

Cái giá và giới hạn

• Đọc phải chờ. Chi phí bằng độ lệch của secondary lúc đọc: lab ép 1 giây nên mỗi lần đọc chờ khoảng 1 giây; ở cụm thật, lag tăng thì latency đọc tăng theo.
• Mốc phải đi cùng người dùng. Ứng dụng nhiều instance, mỗi request tới một instance: operationTime phải đi theo request (cookie, header), nếu không instance thứ hai không biết phải chờ tới đâu. Session cũng không dùng song song từ nhiều luồng.
• Đọc từ primary thì ít cần hơn. Khi không có failover, đọc local trên primary đã thấy lệnh ghi của mình. [tài liệu] Qua một cuộc bầu, lần đọc rơi vào primary cũ có thể không thấy lệnh ghi majority mà primary mới đã nhận, nên tài liệu khuyên ghi majority và đọc majority. Causal consistency đáng giá nhất khi bạn chủ động đọc từ secondary để giảm tải primary.
• readPreference là bài khác. Chọn secondary nào, nearest, tag set và hành vi khi failover thuộc bài Elections, Failover & Majority. Ở đây chỉ cần nhớ ba núm: từ đâu, mức nào, thứ tự nào.

Cột mốc: Bạn đã có thể giải thích vì sao w: 1 có thể mất dữ liệu khi primary mất, và vì sao đọc lại lệnh ghi của mình cần majority ở cả hai phía. Tiếp theo: Retryable, chọn mức theo dữ liệu.

Hỏi & đáp