WAL Replay: Cơ chế khôi phục TSDB và bảo vệ dữ liệu sau sự cố Mimir ingester grafana

Một trong những câu hỏi phổ biến khi triển khai Grafana Mimir là: Nếu Ingester bị OOMKilled, Pod bị xóa hoặc Node gặp sự cố thì các metric vừa ghi có bị mất không?

Trong bài viết này, chúng ta sẽ theo dõi hành trình của một metric từ lúc được ghi vào Mimir cho đến khi Ingester gặp sự cố và phục hồi, qua đó hiểu rõ cách Grafana Mimir sử dụng cơ chế WAL (Write-Ahead Log), Replication, Quorum Write và WAL Replay có thể đảm bảo tính bền vững và an toàn của dữ liệu hay không?

Để hiểu cơ chế bảo vệ dữ liệu trong mimir grafana, chúng ta cần xem mô hình kiến trúc của thành phần này.

Luồng ghi dữ liệu trong Grafana Mimir

Trong điều kiện hoạt động bình thường, Distributor không ghi metric vào một Ingester duy nhất. Thay vào đó, Distributor sử dụng Hash Ring để shard mỗi time series đến nhóm Ingester chịu trách nhiệm lưu trữ series đó.

Để hiểu hơn chúng ta quan sát mô hình cách mà mimir ghi dữ liệu qua sơ đồ sau:

Mỗi Ingester lưu dữ liệu trong:

• TSDB Head (Memory) để phục vụ ingest và truy vấn dữ liệu mới.
• Write-Ahead Log (WAL) trên đĩa để đảm bảo khả năng khôi phục sau sự cố.

Định kỳ (mặc định khoảng 2h), dữ liệu trong TSDB Head được nén (compact) thành TSDB Block và tải lên Object Storage để lưu trữ lâu dài theo cơ chế sau:

Append Sample  -> Update TSDB Head -> Append WAL -> ACK Distributor

Điểm quan trọng là Distributor chỉ nhận ACK sau khi dữ liệu đã được ghi thành công vào WAL, điều này có nghĩa là:

• Nếu Ingester bị OOMKilled hoặc Pod bị xóa sau khi ACK được trả về, dữ liệu vẫn có thể được khôi phục từ WAL khi Ingester khởi động lại.
• Nếu một Ingester gặp sự cố hoàn toàn, Distributor vẫn có thể dựa vào các replica còn lại để đảm bảo tính toàn vẹn của dữ liệu, miễn là đáp ứng điều kiện Quorum Write.

Vậy cơ chế Quorum Write là gì? 

Quorum Write là cơ chế chỉ xác nhận một yêu cầu ghi thành công khi đa số (majority) các replica đã ghi dữ liệu thành công. 

Ví dụ, với Replication Factor = 3:

Distributor
      │
      ├──► Ingester A   ✓
      ├──► Ingester B   ✓
      └──► Ingester C   ✗

Distributor vẫn trả về ACK vì đã có 2/3 replica ghi thành công (quorum = 2). Dữ liệu vẫn tồn tại trên các Ingester còn lại và replica bị lỗi có thể đồng bộ lại sau khi phục hồi.

Ngược lại:

Distributor
      │
      ├──► Ingester A   ✓
      ├──► Ingester B   ✗
      └──► Ingester C   ✗

Chỉ có 1/3 replica ghi thành công nên không đạt quorum. Distributor sẽ trả lỗi để client (ví dụ Prometheus) thực hiện retry (re-push các sample chưa được ghi thành công ), tránh xác nhận một bản ghi chưa được lưu an toàn.

Điều gì xảy ra khi Pod Crash?

Khi Ingester gặp sự cố (ví dụ OOMKilled, Node down hoặc Pod bị xóa), toàn bộ dữ liệu trong Memory và TSDB Head sẽ biến mất ngay lập tức.

Tuy nhiên, các sample đã được ghi vào WAL vẫn được lưu trên đĩa và sẽ được sử dụng để khôi phục trạng thái của Ingester sau khi khởi động lại.

WAL là gì?

Write-Ahead Log (WAL) là nhật ký ghi tuần tự (append-only log) được sử dụng để đảm bảo durability của dữ liệu trước khi Ingester xác nhận yêu cầu ghi thành công.

Mỗi sample được append vào WAL theo đúng thứ tự ghi và được lưu trên persistent storage, cho phép Ingester replay và khôi phục lại TSDB Head sau khi khởi động lại.

Khôi phục Ingester sau khi khởi động lại

Khi Ingester gặp sự cố, Kubernetes sẽ tạo một Pod mới và khởi động lại tiến trình Mimir.

Quá trình khởi động diễn ra theo trình tự:

Trong suốt quá trình WAL Replay, Ingester chưa tham gia Hash Ring để nhận ghi dữ liệu mới và Readiness Probe vẫn ở trạng thái Not Ready. Chỉ sau khi hoàn tất quá trình khôi phục, Ingester mới bắt đầu phục vụ ingest và query.

WAL Replay hoạt động như thế nào?

WAL Replay là quá trình khôi phục toàn bộ trạng thái của TSDB Head từ các WAL Segment còn lưu trên đĩa.

Ví dụ:

000001

000002

000003

...

Mimir đọc từng WAL Segment theo thứ tự và xử lý lần lượt từng record.

│ WAL Segment │──▶│ Read Record│──▶│ Snappy Decode │──▶│ Parse Series │──▶
│ Append to Head │──▶│ Rebuild Index │──▶│ Complete │

1. Read Record

Mimir đọc tuần tự từng record trong WAL Segment. Các record có thể chứa:

• Series Record (khai báo series mới)
• Sample Record (dữ liệu metric)
• Tombstone Record (xóa dữ liệu)

Việc đọc tuần tự giúp đảm bảo thứ tự ghi ban đầu được giữ nguyên.

2. Decode Record

Record được giải mã từ định dạng nhị phân của WAL.

Ở bước này, Mimir kiểm tra tính hợp lệ của dữ liệu trước khi đưa vào bộ nhớ.

3. Parse Series

Đối với các Series Record, Mimir khôi phục:

• Metric Name
• Label Set
• Series Reference

Nhờ đó hệ thống biết mỗi sample thuộc time series nào.

4. Append to TSDB Head

Đây là bước quan trọng nhất.

Mỗi sample được append trở lại TSDB Head giống như khi dữ liệu vừa được ingest.

Trong quá trình này, Mimir đồng thời:

• tạo lại các Series trong Head
• tạo lại Chunks
• cập nhật Postings List
• xây dựng lại các cấu trúc Head Index

Nói cách khác, toàn bộ trạng thái của TSDB Head được tái tạo hoàn toàn từ WAL.

5. Head Restored

Sau khi toàn bộ WAL được replay:

• TSDB Head chứa đầy đủ dữ liệu như trước khi Ingester gặp sự cố.
• Readiness Probe chuyển sang Ready.
• Ingester tham gia lại Hash Ring.
• Distributor bắt đầu gửi dữ liệu mới đến Ingester.

Quá trình này được lặp lại cho đến khi toàn bộ WAL được xử lý.

Thay vì tải trực tiếp TSDB Head từ đĩa, Mimir xây dựng lại toàn bộ trạng thái trong bộ nhớ bằng cách phát lại (replay) từng bản ghi trong WAL. Đây là lý do WAL Replay có thể mất nhiều thời gian khi WAL lớn hoặc số lượng active series cao.

Thời gian WAL Replay phụ thuộc vào nhiều yếu tố, trong đó quan trọng nhất là:

• Kích thước WAL: WAL càng lớn, thời gian replay càng dài.
• Hiệu năng lưu trữ: SSD giúp đọc WAL nhanh hơn đáng kể so với HDD.
• Số lượng Active Series: Càng nhiều series, Mimir càng mất nhiều thời gian để khôi phục TSDB Head.
• wal_replay_concurrency: Tăng số luồng replay có thể rút ngắn thời gian khởi động trên các máy nhiều CPU, nhưng đồng thời làm tăng mức sử dụng CPU và bộ nhớ trong quá trình replay.

Kết luận

Ingester không chỉ là nơi lưu metric tạm thời trong RAM mà còn là thành phần chịu trách nhiệm đảm bảo tính bền vững của dữ liệu trước khi tạo TSDB block. Khi xảy ra sự cố, WAL Replay là cơ chế giúp khôi phục trạng thái của TSDB Head, còn Quorum Write và Replication Factor giúp giảm nguy cơ mất dữ liệu khi một hoặc nhiều Ingester gặp lỗi.

Hiểu rõ chu trình Receive → WAL → ACK → Crash → Replay → Ready sẽ giúp bạn:

• Phân tích đúng nguyên nhân khi Ingester khởi động chậm.
• Ước lượng thời gian phục hồi sau sự cố.
• Thiết kế kích thước WAL, khoảng thời gian compaction và replication phù hợp.
• Tự tin hơn khi vận hành Grafana Mimir trong môi trường production.