Thay đổi schema không gián đoạn: các migration bổ sung an toàn

Không gián đoạn thực sự nghĩa là gì đối với thay đổi schema

Không gián đoạn khi thay đổi schema không có nghĩa là chẳng có gì thay đổi. Nó có nghĩa là người dùng vẫn có thể làm việc trong khi bạn cập nhật cơ sở dữ liệu và ứng dụng, mà không bị lỗi hoặc quy trình bị chặn.

Downtime là bất kỳ lúc nào hệ thống không hoạt động bình thường. Điều đó có thể là lỗi 500, timeout API, màn hình tải nhưng trống hoặc hiển thị sai giá trị, job nền bị crash, hoặc cơ sở dữ liệu chỉ cho đọc nhưng chặn ghi vì một migration dài đang giữ khóa.

Một thay đổi schema có thể phá vỡ nhiều thứ hơn giao diện chính. Những điểm thất bại phổ biến bao gồm client API mong đợi kiểu phản hồi cũ, job nền đọc/ghi cột cụ thể, báo cáo truy vấn trực tiếp bảng, tích hợp bên thứ ba, và script admin nội bộ mà “hôm qua vẫn chạy tốt”.

App di động cũ và client cache thường gây vấn đề vì bạn không thể cập nhật chúng ngay lập tức. Một số người dùng giữ phiên bản app trong vài tuần. Một số khác kết nối gián đoạn và retry request cũ sau. Ngay cả client web cũng có thể cư xử như “phiên bản cũ” khi service worker, CDN, hoặc proxy cache giữ mã hoặc giả định lỗi thời.

Mục tiêu thực sự không phải là “một migration lớn xong nhanh”. Mà là một chuỗi bước nhỏ trong đó mỗi bước tự hoạt động tốt, kể cả khi các client khác nhau ở các phiên bản khác nhau.

Một định nghĩa thực tế: bạn nên có thể deploy mã mới và schema mới theo bất kỳ thứ tự nào mà hệ thống vẫn hoạt động.

Tư duy này giúp tránh cái bẫy kinh điển: deploy app mới mong đợi cột mới trước khi cột tồn tại, hoặc thêm cột mới mà mã cũ không xử lý được. Hãy lên kế hoạch để thay đổi là bổ sung trước, triển khai theo giai đoạn, và chỉ gỡ đường cũ khi bạn chắc chắn không còn ai dùng.

Bắt đầu với thay đổi bổ sung không làm hỏng mã hiện tại

Con đường an toàn nhất để đạt không gián đoạn là thêm chứ không thay thế. Thêm cột mới hoặc bảng mới hiếm khi phá vỡ vì mã hiện tại vẫn có thể đọc và ghi theo cấu trúc cũ.

Đổi tên và xóa là động tác rủi ro. Đổi tên thực chất là “thêm mới + bỏ cũ”, và phần "bỏ cũ" là chỗ client cũ crash. Nếu cần đổi tên, xử lý như thay đổi hai bước: thêm trường mới trước, giữ trường cũ một thời gian, và chỉ xóa khi chắc chắn không còn phụ thuộc.

Khi thêm cột, bắt đầu với trường nullable. Cột nullable cho phép mã cũ tiếp tục insert hàng mà không cần biết về cột mới. Nếu cuối cùng bạn muốn NOT NULL, hãy thêm là nullable trước, backfill, rồi enforce NOT NULL sau.

Default cũng hữu ích, nhưng cẩn thận: thêm default vẫn có thể chạm tới nhiều hàng trong một số cơ sở dữ liệu, và làm chậm thay đổi.

Index là một bổ sung “an toàn nhưng không miễn phí”. Chúng làm reads nhanh hơn, nhưng tạo và duy trì index có thể làm chậm writes. Thêm index khi bạn biết chính xác truy vấn sẽ dùng nó, và cân nhắc triển khai vào giờ thấp điểm nếu DB bận.

Một tập quy tắc đơn giản cho migration bổ sung:

• Thêm bảng hoặc cột mới trước, giữ nguyên các cột cũ.
• Để trường mới là tuỳ chọn (nullable) cho tới khi dữ liệu được điền.
• Giữ các truy vấn và payload cũ hoạt động cho tới khi client cập nhật.
• Hoãn các ràng buộc (NOT NULL, unique, foreign keys) cho tới sau khi backfill.

Kế hoạch rollout từng bước để giữ client cũ hoạt động

Hãy coi thay đổi schema không gián đoạn như một rollout, không phải một lần deploy duy nhất. Mục tiêu là cho phép phiên bản app cũ và mới chạy song song trong khi DB dần chuyển sang hình dạng mới.

Một trình tự thực tế:

1. Thêm schema mới theo cách tương thích. Tạo cột hoặc bảng mới, cho phép null, và tránh các ràng buộc nghiêm ngặt mà mã cũ không thỏa mãn. Nếu cần index, thêm theo cách không chặn ghi.
2. Deploy thay đổi backend có thể nói được cả hai “ngôn ngữ”. Cập nhật API để chấp nhận request cũ và mới. Bắt đầu ghi trường mới trong khi vẫn giữ trường cũ đúng. Pha "ghi kép" này làm cho các phiên bản trộn lẫn an toàn.
3. Backfill dữ liệu hiện có theo lô nhỏ. Điền cột mới cho các hàng cũ dần dần. Giới hạn kích thước lô, thêm nghỉ nếu cần, và theo dõi tiến độ để tạm dừng khi tải tăng.
4. Chuyển reads chỉ khi độ bao phủ cao. Khi hầu hết hàng đã backfill và bạn tự tin, đổi backend để ưu tiên trường mới. Giữ fallback về trường cũ một thời gian.
5. Xóa trường cũ cuối cùng, và chỉ khi thực sự không dùng. Chờ tới khi các build di động cũ phần lớn đã hết thời, logs không còn đọc trường cũ, và bạn có kế hoạch rollback rõ ràng. Sau đó mới drop cột cũ và mã liên quan.

Ví dụ: bạn thêm full_name nhưng client cũ vẫn gửi first_name và last_name. Trong một thời gian, backend có thể tạo full_name khi ghi, backfill người dùng hiện có, rồi sau đó đọc full_name mặc định trong khi vẫn hỗ trợ payload cũ. Chỉ khi adoption rõ ràng mới drop các trường cũ.

Backfill không bất ngờ: cách điền dữ liệu mới an toàn

Backfill điền cột hoặc bảng mới cho các hàng hiện có. Đây thường là phần rủi ro nhất vì có thể tạo tải cao, khóa dài, và hành vi “half-migrated” gây nhầm lẫn.

Bắt đầu bằng cách chọn cách chạy backfill. Với dataset nhỏ, một runbook thủ công một lần có thể ổn. Với dataset lớn, nên dùng worker nền hoặc task định kỳ có thể chạy lặp lại và dừng an toàn.

Phân lô công việc để kiểm soát áp lực lên DB. Đừng cập nhật hàng triệu dòng trong một transaction. Nhắm kích thước chunk có thể dự đoán và nghỉ ngắn giữa các lô để traffic người dùng vẫn mượt.

Một pattern thực tế:

• Chọn lô nhỏ (ví dụ 1.000 hàng kế tiếp) dùng khóa đã được index.
• Chỉ cập nhật những gì còn thiếu (tránh ghi lại hàng đã backfill).
• Commit nhanh, rồi sleep ngắn.
• Ghi lại tiến độ (ID hoặc timestamp đã xử lý).
• Retry khi thất bại mà không bắt đầu lại từ đầu.

Làm job có thể restart. Lưu một marker tiến độ đơn giản trong bảng riêng, và thiết kế job để chạy lại không làm hỏng dữ liệu. Các cập nhật idempotent (ví dụ update where new_field IS NULL) rất hữu ích.

Validate khi chạy. Theo dõi còn bao nhiêu hàng chưa có giá trị mới, và thêm vài kiểm tra sanity. Ví dụ: không có số dư âm, timestamp trong khoảng dự kiến, trạng thái nằm trong tập hợp hợp lệ. Kiểm tra mẫu một vài bản ghi thực tế.

Quyết định app nên làm gì trong khi backfill chưa hoàn thành. Một lựa chọn an toàn là đọc fallback: nếu trường mới null, tính toán hoặc đọc giá trị cũ. Ví dụ: bạn thêm preferred_language. Cho tới khi backfill xong, API có thể trả ngôn ngữ hiện có từ profile khi preferred_language rỗng, và chỉ bắt trường mới khi hoàn tất.

Quy tắc tương thích API cho các client trộn lẫn phiên bản

Khi bạn ship thay đổi schema, bạn hiếm khi kiểm soát mọi client. Người dùng web cập nhật nhanh, trong khi các build di động cũ có thể tồn tại hàng tuần. Vì vậy API tương thích ngược vẫn quan trọng ngay cả khi migration DB “an toàn”.

Đầu tiên hãy coi dữ liệu mới là tuỳ chọn. Thêm trường mới vào request và response, nhưng đừng bắt buộc ngay ngày đầu. Nếu client cũ không gửi, server vẫn nên chấp nhận request và hành xử như trước.

Tránh thay đổi ý nghĩa của trường hiện có. Đổi tên trường có thể ổn nếu bạn giữ tên cũ vẫn hoạt động. Tái dùng trường cho ý nghĩa mới chính là nơi xảy ra các lỗi tinh vi.

Default phía server là mạng lưới an toàn. Khi giới thiệu cột mới như preferred_language, đặt giá trị mặc định ở server khi thiếu. Response API có thể bao gồm trường mới, và client cũ sẽ bỏ qua nó.

Quy tắc tương thích ngăn hầu hết sự cố:

• Thêm trường mới là tuỳ chọn trước, rồi mới enforce sau khi adoption.
• Giữ hành vi cũ ổn định, ngay cả khi bạn thêm hành vi tốt hơn phía sau một flag.
• Áp default phía server để client cũ có thể bỏ qua trường mới.
• Giả định có traffic trộn lẫn và test cả hai đường: “client mới gửi” và “client cũ bỏ trống”.
• Giữ thông điệp lỗi và mã lỗi ổn định để monitoring không bị ồn ào đột ngột.

Ví dụ: bạn thêm company_size vào flow đăng ký. Backend có thể đặt default là “unknown” khi trường thiếu. Client mới gửi giá trị thực, client cũ vẫn hoạt động, và dashboard vẫn đọc được.

Khi ứng dụng của bạn được tái sinh: giữ schema và logic đồng bộ

Nếu nền tảng của bạn tái sinh ứng dụng (regenerate), bạn có một bản build sạch của mã và cấu hình. Điều này giúp thay đổi schema không gián đoạn vì bạn có thể thực hiện các bước nhỏ, bổ sung và deploy thường xuyên thay vì giữ vá trong nhiều tháng.

Chìa khóa là một nguồn chân lý duy nhất. Nếu schema DB thay đổi ở chỗ này và logic nghiệp vụ ở chỗ kia, drift xảy ra nhanh. Quyết định nơi định nghĩa thay đổi và coi mọi thứ khác là output được sinh.

Đặt tên rõ ràng giảm tai nạn trong rollout theo giai đoạn. Nếu bạn thêm trường mới, làm cho dễ nhận ra trường nào an toàn cho client cũ và trường nào là đường mới. Ví dụ, đặt tên status_v2 an toàn hơn status_new vì vẫn có ý nghĩa sau sáu tháng.

Cần test lại gì sau mỗi lần tái sinh

Ngay cả khi thay đổi là bổ sung, một build lại có thể lộ coupling ẩn. Sau mỗi lần regenerate và deploy, kiểm tra lại một tập luồng quan trọng:

• Đăng ký, đăng nhập, reset mật khẩu, refresh token.
• Các hành động tạo và cập nhật cốt lõi (những thao tác dùng nhiều nhất).
• Admin và kiểm tra quyền.
• Thanh toán và webhook (ví dụ, sự kiện Stripe).
• Thông báo và nhắn tin (email/SMS, Telegram).

Lên kế hoạch migration trước khi chạm vào editor: thêm trường mới, deploy hỗ trợ cả hai trường, backfill, chuyển reads, rồi retire đường cũ sau. Trình tự đó giữ schema, logic và mã sinh cùng tiến để thay đổi nhỏ, dễ review và có thể hoàn tác.

Sai lầm phổ biến gây outage (và cách tránh)

Hầu hết outage trong migration không phải do công việc DB “khó”. Chúng đến từ thay đổi hợp đồng giữa DB, API và client theo thứ tự sai.

Bẫy phổ biến và cách an toàn hơn:

• Đổi tên cột trong khi mã cũ vẫn đọc. Giữ cột cũ, thêm cột mới, ánh xạ cả hai một thời gian (ghi cả hai, hoặc dùng view). Chỉ rename khi chắc không ai phụ thuộc tên cũ.
• Bắt trường nullable thành required quá sớm. Thêm là nullable, ship mã ghi khắp nơi, backfill hàng cũ, rồi enforce NOT NULL bằng migration cuối.
• Backfill trong một transaction khổng lồ gây khóa bảng. Backfill theo lô nhỏ, có giới hạn và nghỉ giữa các lô. Theo dõi tiến độ để resume an toàn.
• Chuyển reads trước khi writes tạo dữ liệu mới. Chuyển writes trước, rồi backfill, rồi chuyển reads. Nếu reads đổi trước, bạn sẽ gặp màn hình trống, tổng sai, hoặc lỗi “thiếu trường”.
• Drop trường cũ khi chưa chứng minh client cũ đã hết. Giữ trường cũ lâu hơn bạn nghĩ. Xóa chỉ khi metric cho thấy phiên bản cũ gần như không hoạt động và bạn đã thông báo deprecation.

Nếu bạn regenerate app, rất dễ bị cám dỗ “dọn dẹp” tên và ràng buộc một lần. Hãy kiềm chế. Dọn dẹp là bước cuối, không phải bước đầu.

Một quy tắc tốt: nếu một thay đổi không thể rollback hay roll forward an toàn, thì chưa sẵn sàng lên production.

Giám sát và lập kế hoạch rollback cho migration theo giai đoạn

Thành công của thay đổi schema không gián đoạn dựa vào hai thứ: bạn theo dõi gì, và bạn có thể dừng nhanh thế nào.

Theo dõi tín hiệu phản ánh tác động người dùng thực, không chỉ “deploy xong”:

• Tỷ lệ lỗi API (đặc biệt spike 4xx/5xx trên endpoint đã thay đổi).
• Truy vấn chậm (p95 hoặc p99 cho bảng bạn chạm tới).
• Độ trễ ghi (thời gian insert/update trong peak).
• Độ dài hàng chờ (queue depth) cho job backfill hoặc xử lý event.
• Áp lực CPU/IO DB (bất kỳ nhảy vọt nào sau thay đổi).

Nếu bạn làm dual write, thêm logging tạm thời so sánh hai đường. Giữ chặt: chỉ log khi khác nhau, gồm ID bản ghi và mã lý do ngắn, và sample nếu volume cao. Tạo reminder xóa logging này sau migration để không thành tiếng ồn vĩnh viễn.

Rollback cần thực tế. Thường bạn không rollback schema. Bạn rollback mã và giữ schema bổ sung.

Một runbook rollback thực tế:

• Revert logic ứng dụng về phiên bản biết chạy tốt.
• Vô hiệu hóa đọc mới trước, rồi vô hiệu hóa ghi mới.
• Giữ bảng hoặc cột mới, nhưng dừng dùng chúng.
• Tạm dừng backfill cho đến khi metric ổn định.

Với backfill, làm một công tắc dừng có thể gạt trong vài giây (feature flag, config, pause job). Cũng thông báo các pha trước: khi bắt đầu dual write, khi backfill chạy, khi reads chuyển, và “dừng” nghĩa là gì để không ai ứng biến trong áp lực.

Checklist nhanh trước deploy

Trước khi ship thay đổi schema, dừng lại và chạy checklist này. Nó bắt các giả định nhỏ có thể biến thành outage khi có client trộn phiên bản.

• Thay đổi là bổ sung, không phá hủy. Migration chỉ thêm bảng, cột hoặc index. Không xóa, rename hoặc thắt chặt theo cách từ chối ghi cũ.
• Reads hoạt động với cả hai hình dạng. Mã server mới xử lý cả “trường mới có” và “trường mới thiếu” mà không lỗi. Giá trị tuỳ chọn có default an toàn.
• Writes vẫn tương thích. Client mới có thể gửi dữ liệu mới, client cũ vẫn gửi payload cũ và thành công. Nếu hai phiên bản phải cùng tồn tại, server chấp nhận cả hai định dạng và trả về response mà client cũ hiểu.
• Backfill có thể dừng và khởi động lại. Job chạy theo lô, restart không duplicate/corrupt dữ liệu, và có số “hàng còn lại” đo được.
• Bạn biết ngày xóa. Có quy tắc cụ thể khi an toàn để xóa trường hoặc logic cũ (ví dụ sau X ngày cộng xác nhận Y% request từ client đã cập nhật).

Nếu bạn dùng nền tảng regenerate, thêm một kiểm tra nữa: generate và deploy build từ model chính xác bạn sẽ migrate, rồi xác nhận API và logic sinh ra vẫn chịu được các bản ghi cũ. Một lỗi phổ biến là giả định schema mới ngụ ý logic mới bắt buộc.

Cũng viết ra hai hành động nhanh bạn sẽ làm nếu có vấn đề sau deploy: bạn sẽ giám sát gì (lỗi, timeout, tiến độ backfill) và bạn sẽ rollback gì trước (tắt feature flag, pause backfill, revert release). Điều đó biến “chúng tôi sẽ phản ứng nhanh” thành kế hoạch cụ thể.

Ví dụ: thêm trường mới khi app di động cũ vẫn hoạt động

Bạn chạy app đơn hàng. Bạn cần trường mới delivery_window, và nó sẽ bắt buộc cho quy tắc nghiệp vụ mới. Vấn đề là build iOS/Android cũ vẫn được dùng, và chúng sẽ không gửi trường đó trong vài ngày hoặc vài tuần. Nếu bạn bắt DB yêu cầu nó ngay lập tức, client cũ sẽ bị lỗi.

Một đường an toàn:

• Giai đoạn 1: Thêm cột nullable, không ràng buộc. Giữ reads và writes cũ không đổi.
• Giai đoạn 2: Dual write. Client mới (hoặc backend) ghi trường mới. Client cũ vẫn hoạt động vì cột cho phép null.
• Giai đoạn 3: Backfill. Điền delivery_window cho hàng cũ theo quy tắc (suy ra từ phương thức vận chuyển, hoặc default “bất kỳ lúc nào” cho tới khi khách chỉnh sửa).
• Giai đoạn 4: Chuyển reads. Cập nhật API và UI để đọc delivery_window trước, nhưng fallback về giá trị suy ra khi thiếu.
• Giai đoạn 5: Enforce sau. Sau khi adoption và backfill xong, thêm NOT NULL và xóa fallback.

Người dùng cảm nhận trong mỗi giai đoạn vẫn bình thường (đó là mục tiêu):

• Người dùng di động cũ vẫn đặt được đơn vì API không từ chối dữ liệu thiếu.
• Người dùng mới thấy trường mới và lựa chọn của họ được lưu nhất quán.
• Support và ops thấy trường dần đầy mà không có khoảng trống đột ngột.

Một cổng giám sát đơn giản cho mỗi bước: theo dõi tỉ lệ đơn mới có delivery_window không null. Khi nó ổn định ở mức cao (và lỗi xác thực “thiếu trường” gần như bằng 0), thường an toàn để chuyển từ backfill sang enforce constraint.

Bước tiếp theo: xây playbook migration có thể lặp lại

Làm một rollout tỉ mỉ một lần không phải là chiến lược. Hãy coi thay đổi schema như quy trình: cùng các bước, cùng tên, cùng sign-off. Khi đó thay đổi bổ sung tiếp theo vẫn nhàm chán (tức là an toàn), ngay cả khi app bận và client ở nhiều phiên bản.

Giữ playbook ngắn. Nó nên trả lời: chúng ta thêm gì, làm sao ship an toàn, và khi nào xóa phần cũ.

Một mẫu đơn giản:

• Chỉ thêm (cột/bảng/index mới, trường API mới là tuỳ chọn).
• Ship mã có thể đọc cả hai hình dạng cũ và mới.
• Backfill theo lô nhỏ, với tín hiệu "xong" rõ ràng.
• Chớp hành vi bằng feature flag hoặc config, không redeploy.
• Xóa cột/endpoint cũ chỉ sau ngày cutoff và xác minh.

Bắt đầu với một bảng rủi ro thấp (trạng thái tùy chọn mới, trường ghi chú) và chạy toàn bộ playbook: thay đổi bổ sung, backfill, client trộn phiên bản, rồi dọn dẹp. Chạy thử sẽ lộ lỗ hổng trong monitoring, batching và giao tiếp trước khi bạn thử một redesign lớn.

Một thói quen ngăn ngừa lộn xộn lâu dài: theo dõi những mục “xóa sau” như công việc thực sự. Khi bạn thêm cột tạm, mã tương thích tạm thời, hoặc logic ghi kép, tạo ticket cleanup ngay với owner và ngày. Giữ một ghi chú “compatibility debt” nhỏ trong tài liệu phát hành để nó luôn hiển thị.

Nếu bạn xây với AppMaster, bạn có thể coi việc regenerate là một phần của quy trình an toàn: mô hình hóa schema bổ sung, cập nhật logic nghiệp vụ để xử lý cả trường cũ và mới trong quá trình chuyển, và tái sinh mã để source code luôn sạch khi yêu cầu thay đổi. Nếu bạn muốn thấy workflow này phù hợp với môi trường no-code nhưng vẫn sinh mã nguồn thực, AppMaster (appmaster.io) được thiết kế xoay quanh phong cách giao hàng theo từng bước lặp này.

Mục tiêu không phải là hoàn hảo. Mà là khả năng lặp: mỗi migration có kế hoạch, số liệu và lối thoát.