How to debug large db size issue?

etcd · 2023 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bài hướng dẫn vận hành của maintainer etcd, không kể một sự cố cụ thể; giữ vì nêu giới hạn thiết kế của etcd và cách Kubernetes tách một loại dữ liệu ra cụm riêng.

Bối cảnh

• Dung lượng DB của etcd có quota (--quota-backend-bytes), mặc định 2 GB, khuyến nghị tối đa 8 GB. Vượt quota thì mọi lệnh ghi lỗi mvcc: database space exceeded và cụm bật alarm NOSPACE, endpoint báo không khoẻ.
• Với cụm phục vụ Kubernetes, etcd đầy là API server không ghi được gì.

Nội dung chính

• Đo: kích thước file member/snap/db, hoặc etcdctl endpoint status -w json cho cả dbSize (cấp phát vật lý) lẫn dbSizeInUse (dùng thật); chênh lệch là chỗ trống lấy lại được. Có metric tương ứng (etcd_mvcc_db_total_size_in_bytes, ..._in_use_in_bytes, quota).
• Compaction + defragmentation: etcd là MVCC, giữ lịch sử mọi key. Compaction là cách duy nhất xoá lịch sử, nhưng không trả lại chỗ trống; phải defrag sau đó. Compaction chạy một lần cho cả cụm; defrag tốn thời gian và đắt nên chạy từng member một, càng ít càng tốt nhưng không để member nào chạm quota.
• Lỗi đã biết: mọi bản 3.5 (3.5.0–3.5.5) có thể mất nhất quán dữ liệu nếu crash giữa lúc defrag online (qua etcdctl hoặc client API). Khuyến nghị defrag offline bằng etcdutl: dừng từng member, defrag, khởi động lại. Sau đó gỡ alarm bằng tay.
• Tìm thứ chiếm chỗ: đếm key theo loại tài nguyên dưới /registry. Ví dụ trong bài: khoảng 971.000 event so với 51.000 pod, tức event chiếm gần hết. Hỏi tiếp: ai đổi --event-ttl của API server (mặc định 1 giờ)? Có phải lỗi đã biết? Cụm lớn thì tăng timeout cho lệnh đếm; etcd không chạy thì dùng etcd-dump-db đọc thẳng file.
• Giải pháp:
  • Nếu tăng trưởng là bình thường: tăng quota, nhưng boltDB map cả file DB vào bộ nhớ, nên quota lớn hơn là tốn RAM hơn (quá 8 GB chỉ khi máy có nhiều RAM), và phải chắc thay đổi sống qua lần nâng cấp hay tạo lại VM của nhà cung cấp.
  • Tách event ra cụm etcd riêng bằng --etcd-servers-overrides=/events#... của API server.
  • Xoá object không cần rồi compaction + defrag.
  • Nếu tăng trưởng không bình thường: tìm nguyên nhân trước; mọi cách trên chỉ là giảm nhẹ.

Vì sao

• Theo nhận định của wiki: etcd hợp với lượng nhỏ dữ liệu điều phối (boltDB map cả file vào bộ nhớ, quota vài GB); dữ liệu nhiều và mau hết hạn như event không hợp với giả định đó. Tách nó ra cụm riêng là chia kho theo loại dữ liệu (Sharding và tách database).
• MVCC biến mỗi lần ghi thành một phiên bản mới, nên bảo trì định kỳ (compaction + defrag) là bắt buộc; làm offline từng member một vì bản online có lỗi tính đúng (Tự động hoá vận hành và auto-remediation).

Bài học cho SWE

• Theo dõi cả dung lượng cấp phát lẫn dung lượng dùng thật; chênh lệch lớn nghĩa là đến lúc defrag, gần quota nghĩa là sắp mất khả năng ghi.
• Khi một loại dữ liệu chiếm áp đảo kho điều phối, tách nó ra kho riêng trước khi tăng quota.
• Thao tác bảo trì nặng chạy từng node, và ưu tiên bản offline nếu bản online chưa chắc an toàn khi crash.
• OpenAI 2018 đã gặp đúng hai chuyện này ở 2.500 node: tách Events ra cụm etcd riêng, và etcd chạm quota 2 GB khiến autoscaler xoá hết worker (OpenAI 2018).

Liên quan

• etcd 2017 · etcd (CNCF) 2025 · OpenAI 2018 · Kubernetes 2026
• Sharding và tách database · Tự động hoá vận hành và auto-remediation