Cách Di Chuyển VPS Sang Máy Chủ Mới Mà Không Gây Gián Đoạn

Phần lớn các cuộc di chuyển không thất bại trong lúc sao chép dữ liệu. Chúng thất bại trong hai mươi phút sau khi đổi DNS, khi một nửa internet vẫn đang nói chuyện với máy chủ cũ còn nửa kia đã chuyển sang máy mới — và cả hai máy đều đang chấp nhận ghi dữ liệu. File thì đến nơi nguyên vẹn, trang web vẫn tải được, vậy mà đơn hàng lại rơi vào hai cơ sở dữ liệu sẽ chẳng bao giờ được đối chiếu lại với nhau. Tránh được chuyện đó gần như chẳng liên quan gì tới tốc độ truyền dữ liệu, mà liên quan gần như hoàn toàn tới trình tự: cái gì đổi trước, cái gì bị đóng băng, và cái gì phải tiếp tục chạy cho tới khi bạn thực sự chắc chắn.

Không gián đoạn thực sự nghĩa là gì

Đáng để nói cho chính xác, vì cụm từ này gộp chung hai lời hứa rất khác nhau, và chi phí công sức để đạt được chúng cũng khác nhau rất nhiều. Quyết định xem mình thực sự đang nhắm tới điều nào chính là quyết định thật sự đầu tiên của cả cuộc di chuyển.

Nếu buộc phải hy sinh một trong hai, hãy hy sinh tính khả dụng. Một trang bảo trì kéo dài bốn phút là thứ bạn có thể giải thích được. Dữ liệu phân kỳ là thứ bạn không thể sửa được, vì chẳng còn ai đủ thẩm quyền để nói bản sao nào mới là bản đúng.

Kiểm kê trước khi sao chép

Một máy chủ tích tụ dần những thứ chẳng ai từng ghi lại: một cron job được thêm vào giữa lúc xử lý sự cố, một quy tắc firewall cho địa chỉ của một đối tác, một API key được dán thẳng vào một service file. Bản sao chép sẽ không mang theo những thứ đó, và bạn sẽ phải lần mò tìm ra chúng từng cái một trong suốt hai tuần sau đó. Nửa tiếng kiểm kê ngay từ bây giờ loại bỏ được gần như toàn bộ rắc rối đó.

Hãy ghi lại tất cả vào một file được lưu trong version control, chứ đừng chỉ để trong lịch sử cuộn của terminal. Bạn sẽ phải đọc lại nó ba lần trong lúc chuyển đổi, và có một lần rơi đúng vào lúc đầu óc bạn không còn tỉnh táo.

Chọn đích đến dựa trên những thứ bạn sẽ không thể đổi được về sau

Cấu hình phần cứng thì có thể chỉnh sửa; nhưng một vài đặc tính thì không, và những đặc tính đó đáng để cân nhắc thật kỹ trong khi bạn vẫn còn toàn quyền lựa chọn. Vì đằng nào bạn cũng đang di chuyển, đây chính là thời điểm rẻ nhất để sửa một giới hạn mà bấy lâu nay bạn vẫn phải tìm cách lách qua.

• Vị trí đặt máy chủ, vì cả độ trễ tới người dùng lẫn luật áp dụng đều bị cố định bởi yếu tố này. /locations liệt kê các khu vực cùng đặc tính round-trip của từng nơi; hãy chọn một khu vực gặp sự cố độc lập với nơi bạn đang rời đi.
• Nền tảng pháp lý, nếu lý do khiến bạn chuyển đi là vì nhà cung cấp hiện tại chuyển tiếp khiếu nại còn nhanh hơn cả chuyển tiếp gói tin. /offshore-hosting trình bày rõ khu vực pháp lý thực sự kiểm soát được điều gì và không kiểm soát được điều gì.
• Danh tính thanh toán, vì một nhà cung cấp đòi giấy tờ trước khi nhận thanh toán thì mặc nhiên đã có sẵn một hồ sơ về bạn. /no-kyc-vps và /pay-with mô tả phương án thay thế — một số dư nạp bằng tiền mã hóa, không cần thẻ, không có tên nào gắn với cỗ máy đó.
• Dư địa tài nguyên, vì phải di chuyển tới hai lần là kết cục chẳng ai lên kế hoạch cho nó cả. /vps liệt kê các gói, còn /guides có phương pháp tính toán kích thước nếu cỗ máy hiện tại của bạn chưa từng được đo đạc thực sự.
• IPv6 và một IPv4 sạch, vì một địa chỉ tái sử dụng có thể mang theo sẵn tai tiếng của ai đó trước bạn — hãy kiểm tra trước khi nó biến thành một vấn đề về mail.

Hạ TTL của DNS trước tiên, từ nhiều ngày trước đó

Đây là bước chuẩn bị duy nhất không thể dồn vội vào phút chót, vì hiệu quả của nó bị khống chế bởi một chiếc đồng hồ mà bạn không kiểm soát được. TTL trên các bản ghi của bạn cho resolver biết cần cache câu trả lời trong bao lâu. Nếu TTL được đặt là một ngày, một resolver đã hỏi cách đây một tiếng sẽ tiếp tục đưa người dùng về máy chủ cũ trong suốt hai mươi ba giờ tiếp theo, bất kể bạn đã công bố gì đi nữa.

1. 1

   Đọc TTL hiện tại

   dig +noall +answer yourdomain.com cho biết thời gian cache còn lại; truy vấn thẳng tới nameserver có thẩm quyền của bạn bằng dig @ns1.example.net yourdomain.com sẽ cho biết giá trị đã cấu hình. Hãy ghi lại con số đó — nó quyết định thời gian bạn phải chờ đợi.

2. 2

   Hạ xuống còn 300 giây

   Hạ TTL trên mọi bản ghi sẽ thay đổi: A, AAAA, và bất kỳ bản ghi MX hay CNAME nào đang trỏ về máy chủ. Năm phút là đủ ngắn để việc chuyển đổi diễn ra thoải mái, và đủ dài để không dồn dập tra tấn nameserver của bạn.

3. 3

   Chờ hết TTL cũ, rồi chờ thêm một lần nữa

   TTL ngắn mới chỉ thực sự đến được resolver sau khi TTL dài cũ hết hạn. Hãy chờ ít nhất trọn một chu kỳ TTL cũ — một ngày nếu TTL cũ là một ngày — trước khi coi TTL thấp là đã có hiệu lực thật sự. Bắt đầu sớm bước này chẳng tốn kém gì, mà lại mua cho toàn bộ cuộc chuyển đổi một khoảng dư an toàn.

Dựng máy chủ mới, đừng clone máy chủ cũ

Bản năng tự nhiên là tạo image ổ đĩa hiện tại rồi khôi phục nó ở nơi khác. Đây là nước đi sai, cùng một lý do khiến nó sai trong một lần khôi phục: một bản clone ở cấp block sao chép trung thành cả độ trôi cấu hình, các package mồ côi, dịch vụ cấu hình dở dang mà ai đó đã bỏ quên, và bất kỳ cơ chế bám trụ nào mà một kẻ xâm nhập trước đó để lại. Nó còn khiến bạn bị khóa chặt vào phiên bản distro cũ.

Hãy dựng máy mới từ một base image mới nhất, cài đặt các dịch vụ bằng một script, và chỉ sao chép mỗi phần dữ liệu. Chính script đó mới là thành quả thực sự — nó biến lần di chuyển kế tiếp thành chuyện của một buổi chiều thay vì hai tuần, và cho phép bạn dựng lại máy sau một sự cố mà không phải làm công việc khảo cổ.

• Khởi tạo, cập nhật và gia cố trước khi bất cứ thứ gì khác chạm vào máy: SSH chỉ đăng nhập bằng khóa, một tường lửa mặc định từ chối tất cả, cập nhật bảo mật tự động. /guides có phiên bản đầy đủ mất một tiếng đồng hồ của danh sách kiểm tra này.
• Hãy cài đúng phiên bản chính của runtime và cơ sở dữ liệu giống hệt production. Một cuộc di chuyển không phải lúc thích hợp để đồng thời nâng cấp PostgreSQL từ 14 lên 17 — chỉ nên thay đổi từng thứ một, để nếu có thất bại thì cũng chỉ có đúng một lời giải thích.
• Hãy tạo lại user và group với đúng ID dạng số trước khi sao chép file, hoặc tự sửa lại quyền sở hữu bằng tay sau đó. Truyền dữ liệu với --numeric-ids giữ nguyên các con số; việc ánh xạ chúng trở lại đúng tên là việc của bạn.
• Hãy đưa địa chỉ mới vào mọi danh sách cho phép đang nêu tên địa chỉ cũ — API của đối tác, firewall của cơ sở dữ liệu quản lý, cổng thanh toán, hệ thống giám sát của chính bạn — trong khi cả hai địa chỉ vẫn còn hợp lệ.

Sao chép file theo hai lượt

Một lượt truyền duy nhất trên một hệ thống file đang sống chỉ là một snapshot của một mục tiêu vẫn đang di chuyển. Hai lượt giải quyết chuyện này một cách gọn gàng: lượt đầu dài và chạy trong lúc hệ thống vẫn đang sống, lượt hai ngắn và chạy trong lúc đóng băng, và chỉ có lượt hai mới thực sự cần phải nhanh.

Chạy lượt đầu tiên bất cứ khi nào bạn muốn — chạy trước nhiều ngày cũng hoàn toàn ổn. Lượt này gánh phần lớn khối lượng: thư mục upload, mail spool, các volume của container, hàng năm trời media tích lũy. Đến lúc chuyển đổi thì lượt này đã lỗi thời, và đó chính xác là lý do cần có lượt thứ hai.

• Hãy dùng rsync -aAXH --numeric-ids --info=progress2 qua SSH: -a cho các thuộc tính thông thường, -A cho ACL, -X cho các thuộc tính mở rộng, -H cho hard link — thứ này quan trọng nếu có gì đó trên máy đang khử trùng lặp.
• Loại trừ những gì không nên đi theo: /proc, /sys, /dev, /run, các thư mục tạm, cache của package và các log bạn không cần đến. Sao chép các giao diện của kernel, nhẹ thì lãng phí thời gian, nặng thì làm treo cứng cả quá trình truyền.
• Chỉ thêm --delete vào lượt thứ hai thôi. Ở lượt đầu, cờ này vô hại; ở lượt hai, nó xóa đi những file đã bị xóa ở nguồn kể từ đó, và đó chính xác là độ trôi mà bạn đang cố loại bỏ.
• Hãy sao chép cấu hình hệ thống có chọn lọc, đừng bê nguyên toàn bộ. Thứ bạn cần là các vhost của web server, các service unit và cấu hình ứng dụng của bạn — chứ không phải bảng hệ thống file, cấu hình mạng hay machine ID của máy cũ.
• Hãy tạo một khóa SSH dùng một lần riêng cho việc truyền dữ liệu, cấp quyền cho nó trên máy đích, rồi gỡ bỏ ngay khi cuộc di chuyển hoàn tất. Một khóa migration còn sót lại sau hai năm là một thông tin đăng nhập mà chẳng còn ai nhớ nổi mình đã từng cấp ra.

Giữa hai lượt, hãy kiểm chứng thay vì mặc định là ổn. Chạy lượt thứ hai với --dry-run sẽ in ra chính xác những gì nó sẽ thay đổi: một danh sách vài trăm file gần đây là dấu hiệu khỏe mạnh, còn một danh sách bốn mươi nghìn file nghĩa là có một quy tắc loại trừ bị sai, hoặc có thứ gì đó đang ghi đè timestamp một cách vô cớ.

Di chuyển cơ sở dữ liệu mà không mất bản ghi nào

Đây chính là nơi ngân sách thời gian đóng băng bị tiêu vào, và kỹ thuật phù hợp hoàn toàn phụ thuộc vào con số bạn đã viết ra ngay từ đầu. Cả ba phương án dưới đây đều đúng — chỉ là đúng với những con số khác nhau.

Hãy dump schema và dữ liệu riêng ra khi tập dữ liệu lớn. Restore schema trước cho phép bạn kiểm tra sớm cấu trúc, index và quyền hạn trên máy chủ mới, biến việc nạp dữ liệu thành một thao tác dài duy nhất mà bạn có thể bắt đầu ngay trong lúc đóng băng, với sự tự tin sẵn có rằng nó sẽ thành công.

Cấp chứng chỉ TLS trước khi chuyển đổi, không phải sau

Chứng chỉ trên máy chủ mới phải có hiệu lực ngay từ khoảnh khắc người dùng đầu tiên ghé tới. Phát hiện ra điều ngược lại nghĩa là mọi khách truy cập đều gặp phải một trang cảnh báo chặn giữa của trình duyệt, và nếu bạn có gửi header HSTS — điều mà bạn nên làm — thì họ thậm chí không thể bấm qua được. Có hai cách để luôn sẵn một chứng chỉ hoạt động được trước khi DNS trỏ đi bất cứ đâu mới.

• Sao chép chứng chỉ hiện có. Có thể lấy nguyên thư mục state của ACME, hoặc chỉ lấy chứng chỉ và khóa từ bất cứ nơi nào client của bạn đang lưu chúng. Nó có hiệu lực ngay lập tức, vì tính hợp lệ chẳng liên quan gì tới việc máy chủ nào đang giữ file đó, và việc gia hạn sẽ tiếp tục diễn ra bình thường ngay khi DNS đã chuyển xong.
• Cấp một chứng chỉ mới bằng thử thách DNS-01, chứng minh quyền kiểm soát domain thông qua một bản ghi TXT thay vì một HTTP request tới địa chỉ hiện tại. Cách này hoạt động được cả trước khi di chuyển, trước khi chuyển đổi, và cho cả wildcard — điều mà HTTP-01 hoàn toàn không làm được.
• Đừng thử xác thực HTTP-01 trên máy chủ mới trước khi chuyển đổi. Thử thách này được lấy qua cổng 80 tại chính tên domain, mà domain thì vẫn đang phân giải về máy cũ, nên việc xác thực sẽ thất bại mọi lần.

Hãy kiểm chứng mà không cần đụng tới DNS, bằng cách phân giải hostname về địa chỉ mới chỉ cho đúng một lệnh: curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/ — thay bằng địa chỉ thật của bạn. Một dòng lệnh đó chính là bước kiểm tra giá trị nhất trong toàn bộ cuộc di chuyển. Nó chạy thật qua đúng vhost, đúng chứng chỉ và đúng application stack trên máy mới, và đó là cách bạn phát hiện ra cấu hình sai trong khi việc phát hiện đó vẫn chưa tốn kém gì cả.

Nếu máy chủ có gửi mail, hãy bắt đầu sớm hơn

Mail chính là phần của một cuộc di chuyển thất bại muộn hơn nhiều ngày sau đó, âm thầm, và bị đổ lỗi cho một thứ gì khác. Một địa chỉ mới chưa có uy tín gửi thư, thậm chí có thể đã thừa hưởng tai tiếng của ai đó trước mình, và mọi bản ghi xác thực bạn công bố đều đang gắn với địa chỉ mà bạn sắp rời bỏ.

• Hãy kiểm tra địa chỉ mới với các danh sách chặn lớn trước khi quyết định gắn bó với nó. Một IP tái sử dụng đã có tiền sử xấu thì đáng để đổi ngay trong khi việc đổi vẫn còn miễn phí.
• Hãy đặt bản ghi reverse DNS trên địa chỉ mới trỏ về đúng hostname mail của bạn. Các máy chủ nhận thư sẽ kiểm tra xem phân giải xuôi và ngược có khớp nhau không, và chỉ riêng việc thiếu PTR thôi cũng đủ để bị xếp vào spam.
• Hãy thêm địa chỉ mới vào SPF trước khi chuyển đổi, rồi gỡ địa chỉ cũ ra sau đó — cả hai cùng được liệt kê trong suốt khoảng chồng lấn, để mail luôn được xác thực dù nó thực sự được gửi đi từ máy chủ nào.
• Hãy sao chép các khóa riêng tư DKIM thay vì tạo mới, để selector đã được công bố sẵn trong DNS tiếp tục xác thực được. Tạo mới nghĩa là phải công bố lại, mà công bố lại thì lại có độ trễ lan truyền của riêng nó.
• Hãy làm nóng địa chỉ mới một cách từ từ nếu bạn gửi mail với số lượng đáng kể. Một máy chủ suốt đời chưa từng gửi gì rồi bỗng dưng bắn ra mười nghìn tin nhắn, dưới góc nhìn của bên nhận, chẳng khác gì một máy chủ đã bị xâm nhập.

Chuyển đổi

Mọi thứ ở trên chỉ là chuẩn bị, để cho phần này được ngắn gọn, có trình tự và có thể đảo ngược. Hãy thực hiện vào đúng thời điểm lưu lượng truy cập thấp nhất thực sự của bạn, thay vì ba giờ sáng chỉ vì mê tín — hãy kiểm tra dữ liệu phân tích của chính bạn. Hãy viết sẵn phương án rollback trước khi bắt đầu, vì đúng lúc bạn cần đến nó cũng chính là lúc bạn ít muốn ngồi soạn nó ra nhất.

1. 1

   Đóng băng việc ghi trên máy chủ cũ

   Chế độ bảo trì, một user cơ sở dữ liệu chỉ đọc, hoặc trả lỗi trên các đường ghi ngay tại reverse proxy. Các lệnh đọc vẫn tiếp tục được phục vụ từ máy cũ trong suốt quá trình — đó chính là thứ giữ cho trang web không sập trong lúc dữ liệu đang được chuyển đi.

2. 2

   Tắt mọi timer trên máy chủ cũ

   Comment hết các crontab, dừng các timer, dừng các worker xử lý hàng đợi. Từ thời điểm này, máy cũ không được phép xử lý bất cứ điều gì nữa, nếu không tác vụ sẽ chạy trùng hai lần: hai hóa đơn, hai email, hai lần gửi webhook.

3. 3

   Chạy phần chênh lệch cuối cùng

   Lượt file thứ hai kèm --delete, sau đó là bản dump cơ sở dữ liệu cuối cùng hoặc bước replica bắt kịp. Đây là lượt ngắn, tối đa vài phút, vì lượt đầu đã chuyển đi phần lớn khối lượng dữ liệu rồi.

4. 4

   Kiểm chứng máy chủ mới qua đúng hostname thật của nó

   Dùng mẹo --resolve ở trên, thử chạy một trang có đọc từ cơ sở dữ liệu, một lần đăng nhập, và một đường ghi dữ liệu. Xác nhận số dòng khớp với nguồn. Hãy làm tất cả những điều này trước khi đổi DNS, trong lúc việc rollback vẫn hoàn toàn chưa tốn kém gì cả.

5. 5

   Đổi DNS và khởi động các dịch vụ

   Cập nhật A và AAAA về địa chỉ mới, rồi bật và khởi động ứng dụng cùng các timer của nó trên máy chủ mới. Lưu lượng truy cập bắt đầu đổ về trong vòng một chu kỳ TTL và tiếp tục dịch chuyển dần trong suốt giờ tiếp theo.

6. 6

   Giữ máy chủ cũ tiếp tục phục vụ các lệnh đọc

   Hãy để nó chạy tiếp, ở chế độ chỉ đọc, trong ít nhất hai mươi bốn giờ. Các client còn giữ cache cũ vẫn sẽ tìm tới nó, và một máy chủ cũ chỉ đọc sẽ trả về những trang hơi cũ một chút thay vì một kết nối bị từ chối — đó chính là khác biệt giữa một cuộc di chuyển vô hình và một cuộc di chuyển ai cũng nhìn thấy.

48 giờ đầu tiên

Cuộc di chuyển chưa kết thúc chỉ vì trang web đã tải được. Nó chỉ thực sự kết thúc khi không còn gì phụ thuộc vào máy cũ nữa, và việc tìm ra những phụ thuộc đó là một việc phải chủ động đi tìm, chứ không phải ngồi chờ.

• Hãy theo dõi nhật ký truy cập của máy chủ cũ. Mỗi request vẫn còn đổ về đó là một phụ thuộc chưa được di chuyển — một địa chỉ bị ghi cứng trong một tích hợp của đối tác, một client di động còn giữ cache cũ, một probe giám sát chẳng ai còn nhớ mình sở hữu. Nhật ký đó chính là danh sách việc cần làm.
• Hãy xác nhận các timer thực sự đã chạy trên máy chủ mới. Không phải chỉ là chúng đã được bật — mà là chúng đã thực sự chạy, đúng giờ như kỳ vọng, cho ra đúng kết quả như kỳ vọng. Một cron job âm thầm không làm gì cả trông chẳng khác gì một cron job đang hoạt động bình thường.
• Hãy kiểm tra việc gia hạn chứng chỉ một cách thực sự bằng một lần chạy thử (dry run), thay vì sáu mươi ngày sau mới phát hiện ra rằng client ACME của bạn vẫn đang cố gia hạn nhắm vào một máy chủ không còn nhận được thử thách xác thực nữa.
• Hãy kiểm tra luồng mail từ đầu tới cuối theo cả hai chiều, kể cả những gì ứng dụng tự động gửi đi. Email đặt lại mật khẩu chính là nạn nhân kinh điển nhất, vì chẳng ai kiểm tra nó cho tới khi có người dùng thực sự cần đến.
• Hãy sao lưu máy chủ mới rồi khôi phục thử ở một nơi nào đó. Một cỗ máy mới tinh mà không có bản sao lưu đã được xác minh còn ở thế bất lợi hơn cả cỗ máy bạn vừa rời bỏ; /guides có phiên bản đầy đủ của lập luận này.
• Hãy đưa TTL của DNS về giá trị bình thường ngay khi bạn đã thực sự yên tâm. Để nó mãi ở mức 300 giây là một khoản chi phí nhỏ nhưng vĩnh viễn về số lượng truy vấn và độ trễ, trong khi lợi ích thì chẳng còn lại gì.

Ngừng sử dụng máy chủ cũ

Bước cuối cùng chính là bước hay bị bỏ qua nhất, và cũng là bước duy nhất để lại hậu quả về quyền riêng tư. Ổ đĩa cũ giữ các khóa của bạn, cơ sở dữ liệu của bạn, dữ liệu khách hàng và log của bạn, và việc hủy dịch vụ không hề xóa đi bất kỳ thứ gì trong số đó — nó chỉ trả volume trở lại một kho chung, nơi người thuê tiếp theo sẽ nhận được bất cứ thứ gì mà chính sách xóa dữ liệu của nhà cung cấp để sót lại.

• Hãy chờ cho tới khi nhật ký truy cập của máy cũ hoàn toàn im ắng trước khi động vào bất cứ thứ gì. Hủy dịch vụ trong khi một cổng thanh toán vẫn còn đang gửi webhook về địa chỉ cũ chính là cách khiến một cuộc di chuyển biến thành một sự cố một tuần sau đó.
• Hãy đổi mới thay vì chỉ xóa đi: mọi thông tin đăng nhập mà máy chủ cũ từng nắm giữ — API key, mật khẩu cơ sở dữ liệu, deploy key, khóa migration tạm thời. Hãy mặc định rằng bất cứ thứ gì từng tồn tại trên một cỗ máy bạn không còn kiểm soát đều đã bị lộ, vì sớm muộn gì điều đó cũng thành sự thật.
• Hãy ghi đè dữ liệu trước khi trả lại volume. Xóa vĩnh viễn các thư mục nhạy cảm, hoặc lấp đầy dung lượng trống bằng một file ngẫu nhiên thật lớn rồi xóa nó đi. Cách này không hoàn hảo trên một ổ đĩa ảo hóa, nhưng vẫn tốt hơn rất nhiều so với không làm gì cả.
• Hãy lưu trữ lần cuối bất cứ thứ gì bạn có thể cần tham khảo sau này — log, cấu hình, lịch sử shell ghi lại những gì thực sự đã được làm — rồi mã hóa và cất nó ở một nơi không phải là cả hai máy chủ kia.
• Chỉ hủy dịch vụ sau khi máy chủ mới đã sống sót qua trọn một chu kỳ thanh toán và một lần kiểm thử sao lưu-khôi phục đầy đủ. Tháng chồng lấn đó chính là khoản bảo hiểm rẻ nhất trong toàn bộ quá trình.

Một lịch trình bạn có thể áp dụng nguyên xi

Không có bước nào trong số này khó nếu xét riêng lẻ. Lý do khiến các cuộc di chuyển đi vào ngõ cụt là vì tất cả các bước bị dồn nén vào một buổi tối duy nhất, khi TTL chưa hết hạn, chứng chỉ chưa được kiểm tra và phương án rollback chưa được viết ra. Trải đều ra trong một tuần, mỗi ngày chỉ mất hai mươi phút.

Các cuộc di chuyển thực sự thất bại như thế nào

Không phải vì khâu sao chép. Mà vì những thứ chưa từng nằm trên ổ đĩa, và những thứ đã chạy trùng lặp hai lần.

• Cả hai máy chủ cùng ghi dữ liệu một lúc — cửa sổ split-brain, và cũng là thất bại duy nhất ở đây không có cách sửa sạch sẽ. Nó được ngăn chặn bằng trình tự, không phải bằng công cụ: dừng máy cũ, rồi mới khởi động máy mới.
• Timer chạy trên cả hai máy, đây chính là lý do khiến khách hàng nhận được mọi thứ nhân đôi. Hãy tắt timer cũ trước khi đồng bộ lần cuối, không phải sau đó.
• Một TTL chưa từng được hạ xuống, biến một cuộc chuyển đổi năm phút thành một cái đuôi kéo dài cả ngày mà chẳng ai bố trí người trực.
• Quyền sở hữu file bị sai lệch vì ID dạng số khác nhau giữa hai máy, khiến ứng dụng khởi động được nhưng lại không thể ghi vào chính thư mục upload của nó.
• Một chứng chỉ định bụng xử lý sau khi đã chuyển đổi xong, gặp phải một header HSTS khiến khách truy cập chẳng còn cách nào để đi tiếp.
• Một địa chỉ bị ghi cứng ở đâu đó bạn không kiểm soát được — một tích hợp của đối tác, một quy tắc firewall, một bản ghi DNS cho một subdomain mà bạn đã quên mất là nó từng tồn tại.
• Hủy máy chủ cũ ngay trong ngày di chuyển, xóa mất đường lui rollback đúng vào thời điểm mà số liệu thống kê cho thấy bạn nhiều khả năng cần đến nó nhất.