Migrate database 10TB không downtime: kế hoạch là gì?

Question

IT Interview Practice · Accepted Answer

**Dual-write vào cả cũ lẫn mới, backfill lịch sử ở nền, dùng CDC để bắt kịp phần đuôi, kiểm chứng bằng shadow read, rồi lật read một cách atomic — với đường rollback ở mọi bước.** Bạn không bao giờ tắt app; chạy song song hai database cho tới khi cái mới chứng minh được là giống hệt, rồi mới cutover.

## Kiến trúc

```text
        ┌── write ──▶ OLD DB (source of truth) ──CDC (Debezium)──┐
 App ───┤                                                        ▼
        └── write ──▶ NEW DB ◀──── backfill job (historical rows)
                        │
   shadow reads (compare OLD vs NEW) ─▶ diff metrics ─▶ atomic cutover ─▶ NEW is truth
                                                          (flip flag; rollback = flip back)
```

## Cách hoạt động

1. **Dual-write.** App ghi mọi thay đổi vào cả OLD lẫn NEW. Từ giờ dòng mới luôn đồng bộ; chỉ còn thiếu lịch sử.
2. **Backfill.** Một job nền copy dòng lịch sử theo batch (bóp tải để bảo vệ prod). Dùng `INSERT ... ON CONFLICT DO NOTHING` để idempotent, chạy lại an toàn.
3. **CDC catch-up.** Dual-write có thể sót dòng ghi ngay lúc bật. **Debezium** stream WAL/binlog của OLD DB replay mọi thay đổi, bịt khoảng trống mà backfill không với tới.
4. **Shadow read.** Đọc từ NEW song song với OLD, **so sánh kết quả**, và phát ra metric diff. Không diff nào theo thời gian = NEW đáng tin.
5. **Cutover.** Lật một feature flag để read (rồi write) đi vào NEW. Đây là đổi config, không phải deploy — tức thì, và **đảo ngược được bằng cách lật lại**.

## Góc nhìn phỏng vấn

Người phỏng vấn muốn biết **bạn đảm bảo không mất dữ liệu và không downtime ra sao**, và có **rollback** không. Câu trả lời khá nhắc dual-write; câu xuất sắc thêm **CDC để bắt cửa sổ race**, **shadow read để kiểm chứng trước khi tin**, và **lật flag atomic, đảo ngược được**. Bẫy kinh điển là "backfill rồi switch" không kiểm chứng — bạn phát hiện lệch sau khi user đã dính, mà không còn đường lui.

## Đánh đổi & lỗi

- **Nhất quán dual-write.** Nếu ghi NEW lỗi mà OLD thành công, chúng phân kỳ. Cho OLD làm nguồn chính và để CDC vá NEW, thay vì làm hỏng request của user.
- **Chi phí & độ phức tạp.** Chạy hai database + CDC + backfill tốn kém và nặng vận hành — chỉ đáng cho các kho lớn, trọng yếu.
- **Đổi schema** trong lúc migrate nhân đôi rủi ro; đóng băng schema tới khi cutover.
- **Tải backfill.** Backfill không bóp tải có thể bão hoà I/O prod và gây outage — trái với mục tiêu; hãy batch và rate-limit.
- **Cửa sổ rollback.** Giữ dual-write (giờ NEW→OLD) vài ngày sau cutover để lật lại nếu một bug ẩn lộ ra. Chỉ sau đó mới gỡ bỏ OLD.
- **Khi nào không dùng:** một DB nhỏ có cửa sổ bảo trì thì chẳng cần thế này — một `pg_dump`/restore 30 phút đơn giản và an toàn hơn một pipeline CDC.

Kiến trúc

Cách hoạt động

Góc nhìn phỏng vấn

Đánh đổi & lỗi

Câu hỏi liên quan