Trong một blog trước, chúng ta đã thảo luận về cách chuyển thiết lập Moodle độc lập sang thiết lập có thể mở rộng dựa trên cơ sở dữ liệu được phân nhóm. Bước tiếp theo bạn sẽ cần nghĩ đến là cơ chế chuyển đổi dự phòng - bạn sẽ làm gì nếu và khi dịch vụ cơ sở dữ liệu của bạn gặp sự cố.
Máy chủ cơ sở dữ liệu bị lỗi không có gì lạ nếu bạn có MySQL Replication làm cơ sở dữ liệu Moodle phụ trợ của mình và nếu điều đó xảy ra, bạn sẽ cần tìm cách khôi phục cấu trúc liên kết của mình bằng cách thúc đẩy máy chủ dự phòng để trở thành một máy chủ chính mới. Việc tự động chuyển đổi dự phòng cho cơ sở dữ liệu Moodle MySQL của bạn sẽ giúp ứng dụng có thời gian hoạt động. Chúng tôi sẽ giải thích cách hoạt động của các cơ chế chuyển đổi dự phòng và cách xây dựng chuyển đổi dự phòng tự động vào thiết lập của bạn.
Kiến trúc sẵn có cao cho Cơ sở dữ liệu MySQL
Có thể đạt được kiến trúc tính sẵn sàng cao bằng cách nhóm cơ sở dữ liệu MySQL của bạn theo một vài cách khác nhau. Bạn có thể sử dụng MySQL Replication, thiết lập nhiều bản sao theo sát cơ sở dữ liệu chính của bạn. Trên hết, bạn có thể đặt một bộ cân bằng tải cơ sở dữ liệu để phân chia lưu lượng đọc / ghi và phân phối lưu lượng trên các nút đọc-ghi và chỉ đọc. Kiến trúc tính khả dụng cao của cơ sở dữ liệu sử dụng MySQL Replication có thể được mô tả như sau:
Nó bao gồm một cơ sở dữ liệu chính, hai bản sao cơ sở dữ liệu và bộ cân bằng tải cơ sở dữ liệu (trong blog này, chúng tôi sử dụng ProxySQL làm bộ cân bằng tải cơ sở dữ liệu) và được lưu giữ như một dịch vụ để giám sát các quy trình ProxySQL. Chúng tôi sử dụng Địa chỉ IP ảo làm một kết nối duy nhất từ ứng dụng. Lưu lượng sẽ được phân phối đến bộ cân bằng tải hoạt động dựa trên cờ vai trò trong keepalived.
ProxySQL có thể phân tích lưu lượng và hiểu liệu một yêu cầu là đọc hay ghi. Sau đó, nó sẽ chuyển yêu cầu đến (các) máy chủ lưu trữ thích hợp.
Chuyển đổi dự phòng trên MySQL Replication
MySQL Replication sử dụng ghi nhật ký nhị phân để sao chép dữ liệu từ bản chính sang bản sao. Các bản sao kết nối với nút chính và mọi thay đổi được sao chép và ghi vào nhật ký chuyển tiếp của các nút bản sao thông qua IO_THREAD. Sau khi các thay đổi được lưu trữ trong nhật ký chuyển tiếp, quy trình SQL_THREAD sẽ tiến hành áp dụng dữ liệu vào cơ sở dữ liệu bản sao.
Cài đặt mặc định cho tham số read_only trong bản sao là BẬT. Nó được sử dụng để bảo vệ chính bản sao khỏi bất kỳ ghi trực tiếp nào, vì vậy các thay đổi sẽ luôn đến từ cơ sở dữ liệu chính. Điều này rất quan trọng vì chúng tôi không muốn bản sao phân tách khỏi máy chủ chính. Kịch bản chuyển đổi dự phòng trong MySQL Replication xảy ra khi không thể truy cập được tệp chính. Có thể có nhiều lý do cho điều này; ví dụ:sự cố máy chủ hoặc sự cố mạng.
Bạn cần thăng cấp một trong các bản sao lên chính, tắt tham số chỉ đọc trên bản sao được thăng cấp để nó có thể ghi được. Bạn cũng cần thay đổi bản sao khác để kết nối với bản chính mới. Trong chế độ GTID, bạn không cần phải lưu ý tên nhật ký nhị phân và vị trí từ đâu để tiếp tục sao chép. Tuy nhiên, trong sao chép dựa trên binlog truyền thống, bạn chắc chắn cần biết tên và vị trí nhật ký nhị phân cuối cùng để tiếp tục. Chuyển đổi dự phòng trong sao chép dựa trên binlog là một quá trình khá phức tạp, nhưng ngay cả chuyển đổi dự phòng trong sao chép dựa trên GTID cũng không hề nhỏ vì bạn cần chú ý đến những thứ như giao dịch sai. Phát hiện lỗi là một chuyện, và sau đó phản ứng với lỗi trong một thời gian ngắn có lẽ không thể thực hiện được nếu không có tự động hóa.
Cách ClusterControl Bật Chuyển đổi Dự phòng Tự động
ClusterControl có khả năng thực hiện chuyển đổi dự phòng tự động cho cơ sở dữ liệu Moodle MySQL của bạn. Có một tính năng Khôi phục Tự động cho Cụm và Nút sẽ kích hoạt quá trình chuyển đổi dự phòng khi cơ sở dữ liệu chính gặp sự cố.
Chúng tôi sẽ mô phỏng cách Chuyển đổi dự phòng tự động xảy ra trong ClusterControl. Chúng tôi sẽ thực hiện sự cố cơ sở dữ liệu chính và chỉ cần xem trên bảng điều khiển ClusterControl. Dưới đây là cấu trúc liên kết hiện tại của cụm:
Cơ sở dữ liệu chính đang sử dụng Địa chỉ IP 10.10.10.11 và các bản sao là:10.10.10.12 và 10.10.10.13. Khi sự cố xảy ra trên chính, ClusterControl sẽ kích hoạt một cảnh báo và quá trình chuyển đổi dự phòng bắt đầu như thể hiện trong hình bên dưới:
Một trong các bản sao sẽ được thăng cấp thành chính, dẫn đến Cấu trúc liên kết là trong hình dưới đây:
Địa chỉ IP 10.10.10.12 hiện đang phục vụ lưu lượng ghi là chính, và chúng tôi cũng chỉ còn lại một bản sao có địa chỉ IP 10.10.10.13. Về phía ProxySQL, proxy sẽ tự động phát hiện trang chính mới. Nhóm máy chủ (HG10) vẫn phục vụ lưu lượng ghi có thành viên 10.10.10.12 như hình dưới đây:
Hostgroup (HG20) vẫn có thể phân phối lưu lượng đọc, nhưng như bạn thấy nút 10.10.10.11 ngoại tuyến do sự cố:
Sau khi máy chủ chính bị lỗi trực tuyến trở lại, nó sẽ không tự động hoạt động trở lại -được giới thiệu trong cấu trúc liên kết cơ sở dữ liệu. Điều này là để tránh mất thông tin khắc phục sự cố, vì việc giới thiệu lại nút dưới dạng bản sao có thể yêu cầu ghi đè một số nhật ký hoặc thông tin khác. Nhưng có thể cấu hình tự động tham gia lại của nút bị lỗi.
