Migration Database Không Downtime Với Expand and Contract

Đổi tên hoặc tái cấu trúc một cột cơ sở dữ liệu khi hệ thống đang chạy là một trong những nguyên nhân hàng đầu dẫn đến sự cố sập ứng dụng (production outage) bất ngờ. Khi bạn chạy một câu lệnh migration duy nhất để đổi tên cột trên cơ sở dữ liệu trực tiếp, những phiên bản ứng dụng cũ đang xử lý request sẽ lập tức quăng lỗi và làm gián đoạn trải nghiệm của người dùng.

Để đạt được khả năng cập nhật schema mà không gây downtime (zero-downtime database migration), các kỹ sư phần mềm cần tách rời việc thay đổi cấu trúc bảng ra khỏi chu kỳ release mã nguồn ứng dụng. Mẫu thiết kế Expand and Contract (còn được gọi là Parallel Change) giải quyết bài toán này bằng cách chia nhỏ các thao tác phá hủy (breaking changes) thành nhiều giai đoạn tương thích ngược, giúp hệ thống hoạt động liên tục và trơn tru trong suốt quá trình triển khai.

Cái bẫy của Rolling Deployment khi đổi tên cột

Trong các môi trường hạ tầng hiện đại như Kubernetes, AWS ECS hay các nền tảng container, việc cập nhật ứng dụng không diễn ra đồng loạt trên mọi node trong cùng một tích tắc. Quá trình triển khai cuốn chiếu (rolling deployment) sẽ lần lượt tắt từng container cũ và thay thế bằng container mới trong khoảng thời gian vài phút.

Trong khoảng thời gian chuyển tiếp này, phiên bản code cũ (v1) và phiên bản code mới (v2) sẽ cùng tồn tại song song sau bộ cân bằng tải (load balancer) và cùng tiếp nhận lưu lượng truy cập thực tế từ người dùng. Giả sử bạn cần đổi tên cột phone_number thành contact_phone trong bảng users, nếu bạn thực thi một câu lệnh đổi tên trực tiếp:

ALTER TABLE users RENAME COLUMN phone_number TO contact_phone;

Bạn sẽ lập tức tạo ra một tình trạng tranh chấp (race condition) không thể cứu vãn:

1. Nếu chạy migration trước khi hoàn tất rollout code mới: Các pod v1 đang chạy vẫn tiếp tục thực thi các câu lệnh dạng SELECT phone_number FROM users hoặc INSERT INTO users (phone_number, ...). Ngay khi PostgreSQL hay MySQL đổi tên cột xong, mọi câu truy vấn này sẽ lập tức quăng lỗi không tìm thấy cột (column "phone_number" does not exist), khiến tỷ lệ lỗi HTTP 500 tăng vọt.
2. Nếu chạy migration sau khi code mới đã lên: Các pod v2 mới khởi động sẽ tìm kiếm ngay cột contact_phone. Mọi request đi vào pod v2 trước khi migration hoàn tất cũng sẽ sập với lý do tương tự.

Thực tế này cho thấy việc thay đổi schema trong một bước duy nhất hoàn toàn mâu thuẫn với cơ chế triển khai cuốn chiếu phân tán. Muốn đạt zero downtime, mọi trạng thái trung gian của cơ sở dữ liệu đều phải tương thích đồng thời với nhiều phiên bản code khác nhau.

Giai đoạn 1: Expand (Mở rộng schema mà không phá vỡ code cũ)

Nguyên tắc cốt lõi của zero-downtime migration là: Database luôn luôn phải tương thích ngược với phiên bản code đang chạy trên production. Thay vì sửa đổi hay đổi tên trực tiếp cột đang có, bạn tạo thêm một cột mới song song và cho phép giá trị NULL hoặc gán giá trị mặc định an toàn:

ALTER TABLE users ADD COLUMN contact_phone VARCHAR(32);

Sau khi migration đầu tiên này được áp dụng thành công trên production, bạn tiến hành triển khai phiên bản code trung gian v1.1. Phiên bản này bổ sung cơ chế ghi kép (dual-writing) ở tầng truy xuất dữ liệu hoặc ORM model:

• Luồng đọc (Read): Ứng dụng vẫn tiếp tục đọc dữ liệu độc quyền từ cột cũ phone_number.
• Luồng ghi (Write): Mọi thao tác thêm mới hoặc cập nhật thông tin sẽ ghi đồng thời vào cả hai cột phone_number và contact_phone trong cùng một database transaction.

Nhờ vậy, dù một request được định tuyến vào pod chạy code v1.0 hay pod chạy code v1.1, toàn bộ hệ thống vẫn xử lý chính xác mà không hề sinh ra bất kỳ ngoại lệ nào.

Giai đoạn 2: Backfill dữ liệu lịch sử

Cơ chế ghi kép đảm bảo các bản ghi mới phát sinh sẽ có dữ liệu đầy đủ ở cả hai cột. Tuy nhiên, các dòng dữ liệu cũ được tạo từ trước thời điểm triển khai vẫn mang giá trị NULL ở cột mới contact_phone. Bạn cần thực hiện đồng bộ hóa (backfill) số dữ liệu lịch sử này sang cột mới một cách bất đồng bộ.

Tuyệt đối không chạy một câu lệnh cập nhật hàng loạt như UPDATE users SET contact_phone = phone_number trên toàn bộ bảng chứa hàng triệu bản ghi. Hành động này sẽ khóa số lượng lớn dòng dữ liệu, làm phình to log WAL và gây trễ sao chép nghiêm trọng giữa database chính và các bản sao read replica. Thay vào đó, hãy viết một background script hoặc worker xử lý theo từng lô nhỏ (batching):

-- Cập nhật theo từng khoảng ID nhỏ có đánh index
UPDATE users
SET contact_phone = phone_number
WHERE id BETWEEN 10001 AND 15000
  AND contact_phone IS NULL;

Việc đặt một khoảng nghỉ ngắn (khoảng 100 đến 200 mili-giây) giữa các lô cập nhật sẽ nhường tài nguyên I/O và CPU cho các giao dịch người dùng thông thường. Khi các câu lệnh kiểm tra xác nhận không còn dòng nào có phone_number IS NOT NULL nhưng contact_phone IS NULL, dữ liệu giữa hai cột đã đạt trạng thái đồng nhất hoàn toàn.

Giai đoạn 3: Chuyển hướng đọc sang cột mới

Khi tính toàn vẹn của dữ liệu đã được xác nhận tuyệt đối, bạn triển khai tiếp phiên bản ứng dụng v1.2. Phiên bản này sẽ chính thức chuyển giao trách nhiệm đọc dữ liệu sang cột mới:

• Luồng đọc (Read): Chuyển sang đọc hoàn toàn từ contact_phone.
• Luồng ghi (Write): Vẫn duy trì cơ chế ghi kép vào cả hai cột contact_phone và phone_number.

Duy trì việc ghi vào cột cũ trong giai đoạn này tạo ra một tấm lưới an toàn vô giá. Nếu phát sinh lỗi logic tiềm ẩn hoặc vấn đề hiệu năng bất ngờ ở phiên bản v1.2, bạn có thể rollback hệ thống về bản v1.1 hoặc v1.0 ngay lập tức mà không sợ bị thất thoát dữ liệu phát sinh trong thời gian vừa qua.

Giai đoạn 4: Contract (Thu hẹp và dọn dẹp cột cũ)

Sau khi phiên bản v1.2 vận hành ổn định trên production qua một chu kỳ theo dõi định sẵn, bạn có thể tự tin loại bỏ cấu trúc cũ.

Trước tiên, bạn triển khai phiên bản code v1.3 nhằm xóa bỏ triệt để mọi tham chiếu đến cột phone_number trong mã nguồn ứng dụng, repository và các câu truy vấn.

Cuối cùng, chạy migration dọn dẹp để giải phóng cột cũ khỏi database:

ALTER TABLE users DROP COLUMN phone_number;

Trong các hệ quản trị cơ sở dữ liệu hiện đại như PostgreSQL, thao tác DROP COLUMN diễn ra gần như tức thì dưới dạng cập nhật metadata của bảng, không khóa bảng lâu và không làm ảnh hưởng đến hiệu năng vận hành chung.

Đánh đổi thực tế trong kỹ thuật phần mềm

Áp dụng mẫu thiết kế Expand and Contract biến một câu lệnh RENAME tưởng chừng diễn ra trong vài giây thành một quy trình đòi hỏi kỷ luật cao với nhiều pull request và chu kỳ release nối tiếp nhau. Với các dự án phụ cá nhân hoặc sản phẩm thử nghiệm ban đầu chấp nhận được downtime ngắn, đây có thể là chi phí vận hành không cần thiết.

Tuy nhiên, đối với các hệ thống sản xuất phục vụ lượng người dùng lớn và yêu cầu sẵn sàng cao 24/7, sự kiên nhẫn chia nhỏ migration thành từng bước tương thích ngược chính là ranh giới phân định giữa một đợt phát hành êm thấm và một sự cố sập hệ thống nghiêm trọng.

Nguồn tham khảo

1. martinfowler.com