How Stripe's document databases supported 99.999% uptime with zero-downtime data migrations

Stripe · 2024 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• Stripe chọn MongoDB từ 2011 (Atlas chưa có) và xây DocDB, DB-as-a-service nội bộ trên MongoDB Community: hơn 5 triệu query/giây, hơn 10.000 dạng query, hơn 5.000 collection trên hơn 2.000 shard, hàng petabyte dữ liệu tài chính; năm 2023 xử lý 1 nghìn tỉ USD với uptime 99,999%.
• Ứng dụng đi qua proxy DB tự viết bằng Go (độ tin cậy, admission control, phân quyền, chỉ lộ tập hàm tối thiểu), proxy tra chunk metadata service để định tuyến tới shard; ghi chảy ra CDC (oplog → Kafka → S3).

Thay đổi chính

• Data Movement Platform, ban đầu để scale ngang vượt giới hạn dọc của MongoDB, nay dùng cho: tách shard khi tải lên, gộp (bin-pack) shard dùng ít, nâng phiên bản engine, chuyển khách lớn từ multi-tenant sang tenant riêng. Từ vài shard hàng chục TB thành hàng nghìn shard nhỏ.
• Yêu cầu: dữ liệu đầy đủ và nhất quán giữa nguồn và đích; bước then chốt ngắn hơn một lần failover primary có kế hoạch (vài giây, nằm trong ngân sách retry của ứng dụng); không giới hạn số migration đồng thời; không làm chậm shard nguồn.
• Các bước (Coordinator điều phối):
  1. Đăng ký ý định migrate chunk trong metadata service, dựng index trên shard đích.
  2. Bulk import từ snapshot tại thời điểm T. Gom lô và chỉnh tham số engine không giúp; sắp dữ liệu theo thuộc tính index phổ biến nhất rồi chèn theo thứ tự (tận dụng B-tree) tăng throughput ghi 10 lần.
  3. Replication bất đồng bộ từ T đọc oplog qua Kafka/S3 (không tốn throughput đọc của shard nguồn, không bị giới hạn kích thước oplog); dừng/tiếp tục từ checkpoint; hai chiều (đánh dấu ghi để không lặp vòng) để có thể đưa traffic về nguồn.
  4. Kiểm đầy đủ và đúng bằng so snapshot tại một thời điểm (không đè shard).
  5. Chuyển traffic bằng versioned gating: proxy gắn version token vào request; bản vá MongoDB cho shard từ chối request có token cũ. Tăng token trên shard nguồn (mọi đọc/ghi chunk bị từ chối), chờ replication đuổi kịp, cập nhật route và token trong metadata service; proxy lấy route mới. Dưới 2 giây, request lỗi trong lúc đó thành công khi retry.
  6. Đánh dấu xong, xoá dữ liệu chunk ở nguồn.
• Kết quả 2023: bin-pack hàng nghìn DB dùng ít, chuyển 1,5 PB trong suốt với ứng dụng, giảm khoảng 3/4 số shard; nâng MongoDB bằng cách chép dữ liệu sang phiên bản mới một bước, không qua từng bản trung gian. Đang làm: cân bằng nhiệt theo kích thước và throughput, autoscale shard.

Vì sao

• Một nền tảng di chuyển dữ liệu trực tuyến biến tách, gộp, nâng cấp, đổi tenancy thành cùng một thao tác thường ngày.

Bài học cho SWE

• Đặt ngưỡng downtime của cutover bằng thứ ứng dụng đã chịu được (failover, retry) thay vì "zero".
• Thứ tự chèn theo cấu trúc lưu trữ có thể quan trọng hơn gom lô.
• Replication hai chiều trong lúc migrate giữ đường lùi; cổng version ở chính shard ngăn ghi lạc khi định tuyến đổi.

Liên quan

• Multi-tenancy và cô lập tenant
• Sharding và tách database · Migration không downtime
• Cùng công ty: Stripe 2026
• Reshard khác: Notion 2023 · Figma 2024