Database migration zero-downtime là kỹ thuật thay đổi schema mà không cần tắt service, giữ cho hệ thống hoạt động liên tục. Trong kiến trúc microservices và SaaS hiện đại, thời gian chết thậm chí vài phút cũng có thể gây mất doanh thu hàng triệu đô. Kỹ năng này trở thành yêu cầu bắt buộc với mọi database engineer và backend developer.
PostgreSQL, MySQL, và MongoDB hiện hỗ trợ nhiều kỹ thuật zero-downtime migration, nhưng việc triển khai đúng vẫn cần hiểu rõ trade-off giữa consistency, performance, và operational complexity. Bài viết này tổng hợp các pattern đã được thực chiến trong production.
Các pattern migration cơ bản
Trước khi đi vào chiến lược phức tạp, cần phân biệt 3 nhạng migration:
- Add column nullable: Đơn giản nhất — thêm cột nullable không có default value. Database chỉ cần cập nhật metadata, không cần rewrite toàn bộ table.
- Add column with default: Trên PostgreSQL = 11 hỗ trợ default không cần rewrite.
- Drop column: An toàn nhưng cần đảm bảo không còn application code nào tham chiếu cột đó.
Expand-Contract Pattern (khuyến nghị)
Expand-Contract là pattern an toàn nhất cho thay đổi phức tạp — rename cột, thay đổi kiểu dữ liệu, split bảng. Gồm 4 bước:
- Expand: Thêm cột mới, code application ghi vào cả cột cũ và mới (dual-write)
- Backfill: Đồng bộ dữ liệu cũ sang cột mới trong background, không ảnh hưởng user
- Switch: Chuyển đọc từ cột mới, ghi vẫn dual-write
- Contract: Dừng ghi cột cũ, xóa cột cũ sau khi chắc chắn không còn dùng
Pattern này đảm bảo rollback luôn có thể quay về bước trước, không bao giờ để hệ thống ở trạng thái inconsistent. Ví dụ: chuyển từ VARCHAR sang JSONB cho cột settings — thêm cột settings_jsonb, dual-write, backfill từng batch 1000 rows, rồi mới drop cột cũ.
Blue-Green và Rolling Migration
Với sharded database hoặc multi-region setup, cần kết hợp application-level deployment:
- Blue-Green: Deploy version mới viết cả schema cũ và mới, old version vẫn chạy. Sau khi data sync xong, chuyển traffic.
- Rolling: Deploy từng instance, mỗi instance chấp nhận cả old và new schema.
- Shadow write: Ghi song song vào cả hai schema, so sánh kết quả để validate trước khi cutover.
Công cụ như Dynomite hoặc Liquibase có hỗ trợ preconditions để tự động rollback nếu validation fail.
Online DDL và công cụ
| Công cụ | Database | Đặc điểm | Khuyến nghị |
|---|---|---|---|
| pg_repack | PostgreSQL | Rewrite table online, giảm bloat | Thay đổi kiểu dữ liệu nặng |
| pt-online-schema-change | MySQL | Tạo bảng mới, copy từng chunk | MySQL default choice |
| gh-ost | MySQL | Binary log based, lightweight | Large table, low traffic impact |
| Liquibase | Multi | Version control schema, rollback | Team collaboration |
| Flyway | Multi | SQL-based migrations, simple | Small team, simple schema |
| pgx_pages | PostgreSQL | Extension để migrate data pages | PostgreSQL advanced |
PostgreSQL-specific tips
PostgreSQL có CONCURRENTLY keyword cho CREATE INDEX — index được xây dần dần mà không lock bảng. Đây là công cụ mạnh nhất cho zero-downtime:
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);
Tuy nhiên, CONCURRENTLY không hoạt động bên trong transaction — cần tắt autocommit. Nếu index build fail giữa chừng, cần drop index và bắt đầu lại vì index bị marked invalid.
Với ALTER TABLE phức tạp, kết hợp pg_repack để tối ưu physical layout sau khi migration xong. PostgreSQL 14+ cải thiện nhiều operation — ALTER TABLE ... ADD COLUMN với default không còn trigger table rewrite trên nhiều trường hợp.
MySQL và MongoDB considerations
MySQL InnoDB lock table với ALTER TABLE nặng. gh-ost (GitHub’s Online Schema Transfer) là lựa chọn tốt nhất — nó đọc binlog để bắt thay đổi trong khi tạo bảng mới, rồi swap bằng RENAME TABLE atomic. pt-online-schema-change của Percona cũng phổ biến nhưng cần trigger tạm trên bảng.
MongoDB hỗ trợ db.collection.update() với bypassDocumentValidation và background: true (deprecated từ 4.2, giờ background là default). Index rebuild với background: true cho phép concurrent reads/writes. Với sharded cluster, migration cần đảm bảo chunk balancing không bị ảnh hưởng.
Testing và validation
Trước khi chạy migration production, cần:
- Replay traffic: Dùng production traffic log (sanitized) để replay qua staging database đang chạy migration.
- Lock monitoring: Theo dõi
pg_lockstrên PostgreSQL,performance_schematrên MySQL. - Rollback plan: Ghi rõ từng bước rollback — revert code, revert schema, clear cache.
- Canary deploy: Chạy migration trên một node hoặc một shard trước, sau đó mở rộng.
Công cụ như Testcontainers hoặc Docker Compose giúp tạo staging database giống production để test migration end-to-end.
Kết luận
Zero-downtime migration không phải là “không downtime” tuyệt đối, mà là kiểm soát và giảm thiểu rủi ro. Expand-Contract pattern kết hợp với online DDL tools là combo vàng cho hầu hết trường hợp. Luôn có rollback plan, test trên staging, và deploy canary — ba thói quen giúp team tự tin thay đổi schema bất cứ lúc nào.
