Sao chép MySQL sau khi VPN ngắt: đọc cả hai giai đoạn trước

Giám sát sao chép chuyển sang màu đỏ khi VPN sập, và bản năng đầu tiên là đặt lại một vị trí. Chính bản năng đó biến một sự cố mạng thành vấn đề dữ liệu. Một đường dẫn bị ngắt không nói gì về những gì bản sao đã nhận hoặc đã áp dụng, và đó là hai giai đoạn với hai trạng thái. Hãy đọc riêng chúng trước khi thay đổi bất cứ điều gì.

Hai giai đoạn, hai câu trả lời riêng

Một bản sao không đồng bộ thông thường làm hai việc. Bộ nhận kết nối với nguồn, kéo các sự kiện và ghi chúng vào nhật ký chuyển tiếp tại chỗ. Bộ áp dụng đọc nhật ký đó và thực thi các sự kiện trên bản sao. Khi đường dẫn đứt, bộ nhận dừng ngay lập tức trong khi bộ áp dụng tiếp tục xử lý phần tồn đọng đã có trên đĩa. Vì vậy một sự cố tạo ra hai câu hỏi khác nhau: kết nối đã trở lại chưa, và công việc tích lũy đã được áp dụng chưa? Coi chúng là một câu hỏi sẽ lấy trung bình hai trạng thái thành một câu trả lời gây nhầm lẫn.

Bộ nhận phục hồi cho bạn biết đường dẫn đang hoạt động. Nó không nói gì về việc bộ áp dụng tụt lại bao xa, hay liệu nó có gặp lỗi khi bị ngắt kết nối hay không.

Đọc kênh bằng câu lệnh đúng

Trên MySQL 8.4, SHOW REPLICA STATUS trả về một hàng cho mỗi kênh được cấu hình, vì vậy hãy đọc hàng của kênh bạn muốn chứ không phải hàng đầu tiên trong danh sách. Replica_IO_Running phân biệt bộ nhận đã kết nối với bộ nhận đang kết nối hoặc đã dừng, và Replica_SQL_Running mô tả bộ áp dụng. Hãy đọc cả các cột lỗi bên cạnh, vì một bộ nhận kết nối lại và thất bại ngay sẽ để lại thông báo mà không cờ trạng thái nào hiển thị. Các bản phát hành cũ dùng tên cột khác, nên đừng dịch một công thức cũ chỉ bằng cách đổi tên lệnh.

Cũng hãy kiểm tra danh tính của nguồn và mọi bộ lọc đã cấu hình. Một bản sao trỏ tới sai nguồn, hoặc bị lọc hẹp hơn bạn nghĩ, sẽ báo khỏe mạnh trong khi sao chép một thứ khác với điều bạn mong đợi.

Vì sao một con số trễ bằng không có thể nói dối

Giá trị độ trễ so sánh dấu thời gian của sự kiện được áp dụng cuối cùng với thời gian hiện tại. Khi bộ nhận đã dừng một giờ, bộ áp dụng có thể xử lý hết phần tồn đọng và chạm tới cuối những gì nó đã nhận, và khi đó con số rơi về không dù bản sao vẫn chậm hơn nguồn một giờ. Chỉ số này đo hàng đợi của bộ áp dụng, không đo tính cập nhật của bản sao.

Thay vào đó, hãy so sánh các giao dịch đã thực thi với những gì nguồn đang có. Phép so sánh đó vẫn đứng vững khi bộ nhận bị kẹt.

Thời hạn lưu giữ quyết định cửa sổ phục hồi thực sự

Để đuổi kịp, nguồn phải còn giữ các giao dịch mà bản sao cần. Khi chúng bị xóa, bản sao không thể lấy được, và dù kết nối lại bao nhiêu lần cũng không thay đổi điều đó.

Với định vị tự động GTID, thất bại là rõ ràng: bản sao yêu cầu lịch sử mà nguồn không còn giữ và từ chối tiếp tục. Khi đó các lựa chọn là lấy những sự kiện còn thiếu từ một nguồn vẫn còn giữ chúng, hoặc dựng lại từ bản sao lưu và để nó đuổi kịp. Bỏ qua khoảng trống không phải là đuổi kịp, và nó để lại một bản sao có dữ liệu âm thầm không đầy đủ. Hãy lập kế hoạch cho cửa sổ bằng cách so sánh thời gian sự cố dự kiến với thời hạn lưu giữ nhật ký nhị phân trên nguồn và tốc độ thay đổi, vì ba con số đó quyết định liệu một sự cố có thể phục hồi được hay không.

Kiểm chứng việc đuổi kịp, không phải màu của chỉ báo

Khôi phục đường dẫn, bao gồm phân giải tên và bảo mật truyền tải, rồi quan sát xem kênh hiện có có tự kết nối lại theo chính sách của nó không. Hãy cho nó một khoảng thời gian xác định trước khi can thiệp, và ghi lại tiến độ nhận và áp dụng ở cả hai đầu của khoảng đó. Một kênh khởi động lại và một kênh đã cập nhật là hai phát hiện khác nhau.

Xác nhận rằng bộ áp dụng đã đạt tới vị trí hiện tại của nguồn, chứ không chỉ tới cuối phần tồn đọng cũ. Kiểm tra rằng không có lỗi nào đang chờ trong bộ áp dụng, vì một sự kiện thất bại sẽ dừng tiến độ trong khi bộ nhận vẫn tiếp tục báo có kết nối. Sau đó ghi lại bằng chứng: tên kênh, trạng thái của cả hai giai đoạn, vị trí đã thực thi và thời điểm. Một chỉ báo xanh là một lời khẳng định; vị trí là một sự thật.