Bản ghi DNS đã đổi sang IP mới, nhưng một nhóm client vẫn gọi đích cũ. Điều đó không tự chứng minh nhà cung cấp chưa cập nhật. DNS cache, kết nối còn mở và đường phân giải của từng client phải nằm trong kế hoạch chuyển dịch vụ.
Đổi bản ghi không xóa câu trả lời đã cache
AWS giải thích TTL là thời gian resolver cache giá trị trước khi hỏi lại. Khi một resolver còn giữ câu trả lời cũ, thay đổi ở nơi có thẩm quyền không lập tức làm bản cache đó biến mất. Các lớp cache và hành vi client cần được kiểm theo môi trường thật.
Hạ TTL ngay lúc cutover cũng không rút ngắn TTL của câu trả lời cũ đã được cache trước đó. Muốn sử dụng TTL thấp trong kế hoạch, phải đặt trước và chờ đủ cửa sổ liên quan. Không có một con số “propagation” duy nhất áp dụng chính xác cho mọi client; cần biết resolver, cache của ứng dụng và cách tái sử dụng kết nối.
Một timeline giả định để tránh hiểu sai
Giả sử resolver R lấy IP cũ lúc 09:00 với TTL một giờ. Lúc 09:10, owner đổi bản ghi và TTL mới xuống năm phút. R có thể còn dùng câu trả lời cũ theo thời hạn đã nhận, thay vì tự hỏi lại sau năm phút tính từ 09:10. Các mốc chỉ minh họa logic cache, không phải số đo của một nhà cung cấp.
Ngay cả sau khi DNS được hỏi lại, một kết nối lâu sống có thể tiếp tục đến đích đã kết nối trước đó. DNS không di chuyển một TCP session đang mở. Vì thế, sổ cutover phải tách câu trả lời phân giải khỏi endpoint thực của kết nối và yêu cầu nghiệp vụ.
Giữ đích cũ theo điều kiện, không theo cảm giác
Nếu đích cũ còn nhận lưu lượng, nó cần hành vi an toàn: tiếp tục phục vụ theo phạm vi, chuyển tiếp phù hợp hoặc từ chối có kiểm soát tùy kiến trúc. Không xóa ngay chỉ vì công cụ DNS trên máy quản trị đã thấy IP mới. Nhưng giữ hai nơi cùng ghi dữ liệu mà không có thiết kế nhất quán cũng có thể tạo lỗi nghiêm trọng.
Kế hoạch phải xác định nơi nào có thẩm quyền ghi, dữ liệu chia sẻ ra sao và đích cũ còn được làm gì. Bài này không hướng dẫn thay cơ sở dữ liệu hay split-write. Khi chưa có phương án, HOLD bước tắt đích cũ và giải quyết ownership trước; không gọi “giữ cả hai” là mặc định an toàn.
Sổ bằng chứng cho từng nhóm client
| Trường | Vì sao cần |
|---|---|
| Nhóm client và owner | Biết ai kiểm lại khi còn gọi cũ |
| Resolver và thời điểm quan sát | Không so câu trả lời khác nguồn |
| IP phân giải | Thấy trạng thái DNS |
| Endpoint kết nối thực | Phát hiện connection reuse |
| Kết quả nghiệp vụ | IP mới không tự chứng minh chức năng đúng |
Giữ dữ liệu ở mức đủ điều tra, không công khai địa chỉ nội bộ hoặc thông tin khách. Nếu có split-horizon DNS, kết quả trong mạng nội bộ và ngoài mạng có thể khác theo thiết kế. Một công cụ public không đại diện cho resolver của worker hoặc đối tác.
Rollback DNS cũng chịu cache
Đổi lại bản ghi không lập tức kéo tất cả client về đích cũ. Có thể cùng tồn tại client đang giữ câu trả lời mới và cũ. Phương án rollback phải giữ endpoint cần thiết và biết cách xử lý request ở mỗi nơi trong khoảng đó. Đừng dùng “sửa lại IP” như toàn bộ kế hoạch phục hồi.
Cần chuẩn bị certificate, hostname và kiểm kết nối phù hợp ở cả đường chuyển tiếp được dùng. Không tắt kiểm TLS hoặc thay host tùy tiện để vượt một lỗi trong cutover. Nếu có vấn đề ngoài scope, giao owner hạ tầng có quyền quyết định, không thực hiện một bản vá nóng không có bằng chứng.
Ngày chuyển cần có người quan sát và điều kiện đóng
Trước thời điểm đổi, xác nhận bản ghi, TTL trước đó, dependency, liên hệ đối tác và cửa sổ vận hành. Trong khi chuyển, quan sát kết quả theo nhóm client và log endpoint. Sau đó, chỉ ngừng đích cũ khi đáp ứng điều kiện đã duyệt, với các ngoại lệ và rủi ro còn lại được ghi rõ.
Tương thích schema khi migration là lớp dữ liệu riêng, không giải quyết cache DNS. Circuit breaker cũng không ép client hỏi DNS lại. Khi trao đổi phạm vi tích hợp với Onter, một timeline và sổ nhóm client đã ẩn dữ liệu giúp xác định phần ứng dụng cần hỗ trợ; mọi thay đổi DNS/hạ tầng vẫn theo owner và quyền hiện có.
