Trong loạt blog ba phần này, chúng tôi đã giới thiệu Khung công tác sẵn sàng cao (HA) cho lưu trữ MySQL trong Phần I và thảo luận chi tiết về sao chép bán đồng bộ MySQL trong Phần II. Bây giờ trong Phần III, chúng tôi xem xét cách khung xử lý một số trường hợp lỗi quan trọng của MySQL và khôi phục để đảm bảo tính khả dụng cao.
Tình huống Lỗi MySQL
Tình huống 1 - Master MySQL gặp sự cố
- Khung Corosync và Pacemaker phát hiện rằng MySQL chính không còn khả dụng. Pacemaker giảm tài nguyên chính và cố gắng khôi phục bằng cách khởi động lại dịch vụ MySQL, nếu có thể.
- Tại thời điểm này, do tính chất bán đồng bộ của quá trình sao chép, tất cả các giao dịch được cam kết trên bản chính đã được nhận bởi ít nhất một trong các nô lệ.
- Pacemaker đợi cho đến khi tất cả các giao dịch đã nhận được áp dụng trên nô lệ và cho phép nô lệ báo cáo điểm thăng cấp của họ. Việc tính điểm được thực hiện theo cách sao cho điểm là "0" nếu điểm phụ hoàn toàn đồng bộ với điểm chính và ngược lại là số âm.
- Pacemaker chọn nô lệ đã báo cáo điểm 0 và thúc đẩy nô lệ đó hiện đảm nhận vai trò của MySQL chính mà trên đó được phép ghi.
- Sau khi quảng cáo nô lệ, Tác nhân tài nguyên kích hoạt mô-đun định tuyến lại DNS. Mô-đun cập nhật mục nhập DNS proxy bằng địa chỉ IP của thiết bị chính mới, do đó, tạo điều kiện thuận lợi cho tất cả các ứng dụng ghi được chuyển hướng đến thiết bị chính mới.
- Pacemaker cũng thiết lập các nô lệ có sẵn để bắt đầu sao chép từ trang cái mới này.
Do đó, bất cứ khi nào một MySQL chính gặp sự cố (cho dù do sự cố MySQL, sự cố hệ điều hành, khởi động lại hệ thống, v.v.), khung HA của chúng tôi sẽ phát hiện nó và thúc đẩy một nô lệ phù hợp cho đảm nhận vai trò của người chủ. Điều này đảm bảo rằng hệ thống tiếp tục khả dụng cho các ứng dụng.
Giải thích về khung khả dụng cao của #MySQL - Phần III:Kịch bản sự cốNhấp để Tweet
Tình huống 2 - MySQL Slave ngừng hoạt động
- Khung Corosync và Pacemaker phát hiện rằng MySQL nô lệ không còn khả dụng.
- Pacemaker cố gắng khôi phục tài nguyên bằng cách thử khởi động lại MySQL trên nút. Nếu nó xuất hiện, nó sẽ được thêm trở lại cái chính hiện tại như một nô lệ và quá trình sao chép vẫn tiếp tục.
- Nếu quá trình khôi phục không thành công, Pacemaker sẽ báo cáo tài nguyên đó là không hoạt động - dựa trên đó các cảnh báo hoặc thông báo có thể được tạo. Nếu cần, nhóm hỗ trợ ScaleGrid sẽ xử lý việc khôi phục nút này.
- Trong trường hợp này, không có tác động nào đến tính khả dụng của các dịch vụ MySQL.
Tình huống 3 - Phân vùng mạng - Kết nối mạng bị ngắt giữa các nút chính và nút nô lệ
Đây là một vấn đề cổ điển trong bất kỳ hệ thống phân tán nào mà mỗi nút cho rằng các nút khác bị hỏng, trong khi thực tế, chỉ có mạng liên lạc giữa các nút bị hỏng. Kịch bản này thường được gọi là kịch bản phân chia và nếu không được xử lý đúng cách, có thể dẫn đến nhiều nút tự xưng là MySQL chính, từ đó dẫn đến sự không nhất quán và hỏng dữ liệu.
Hãy sử dụng một ví dụ để xem lại cách khung của chúng tôi xử lý các tình huống phân chia não bộ trong cụm. Chúng tôi giả định rằng do sự cố mạng, cụm đã được phân chia thành hai nhóm - chính trong một nhóm và 2 nô lệ trong nhóm còn lại và chúng tôi sẽ ký hiệu điều này là [(M), (S1, S2)].
- Corosync phát hiện rằng nút chính không thể giao tiếp với các nút phụ và các nút phụ có thể giao tiếp với nhau nhưng không giao tiếp với nút chính .
- Nút chính sẽ không thể thực hiện bất kỳ giao dịch nào vì bản sao bán đồng bộ mong đợi xác nhận từ ít nhất một trong các nô lệ trước khi nút chính có thể cam kết. Đồng thời, Pacemaker tắt MySQL trên nút chính do thiếu túc số dựa trên cài đặt Pacemaker ‘no-quorum-policy =stop’. Quorum ở đây có nghĩa là phần lớn các nút, hoặc hai phần ba trong thiết lập cụm 3 nút. Vì chỉ có một nút chính đang chạy trong phân vùng này của cụm, cài đặt chính sách không số đại biểu được kích hoạt dẫn đến việc tắt MySQL chính.
- Bây giờ, Máy tạo nhịp tim trên phân vùng [(S1), (S2)] phát hiện rằng không có cái chính nào có sẵn trong cụm và bắt đầu quá trình thăng hạng. Giả sử rằng S1 được cập nhật với bản chính (được đảm bảo bởi sao chép bán đồng bộ), thì nó sẽ được thăng cấp là bản chính mới.
- Lưu lượng ứng dụng sẽ được chuyển hướng đến nút MySQL chính mới này và S2 nô lệ sẽ bắt đầu sao chép từ nút chính mới.
Do đó, chúng ta thấy rằng khung MySQL HA xử lý các tình huống phân chia một cách hiệu quả, đảm bảo cả tính nhất quán và tính khả dụng của dữ liệu trong trường hợp kết nối mạng bị ngắt giữa các nút chính và nút phụ.
Phần này kết thúc loạt blog gồm 3 phần của chúng tôi về khung MySQL High Av available (HA) sử dụng sao chép bán đồng bộ và ngăn xếp Corosync cộng với Pacemaker. Tại ScaleGrid, chúng tôi cung cấp dịch vụ lưu trữ có tính khả dụng cao cho MySQL trên AWS và MySQL trên Azure được triển khai dựa trên các khái niệm được giải thích trong loạt bài blog này. Vui lòng truy cập Bảng điều khiển ScaleGrid để dùng thử miễn phí các giải pháp của chúng tôi.
