Ngày nay có rất nhiều nhà cung cấp dịch vụ đám mây. Họ có thể nhỏ hoặc lớn, địa phương hoặc với các trung tâm dữ liệu trải rộng trên toàn thế giới. Nhiều nhà cung cấp đám mây trong số này cung cấp một số loại giải pháp cơ sở dữ liệu quan hệ được quản lý. Các cơ sở dữ liệu được hỗ trợ có xu hướng là MySQL hoặc PostgreSQL hoặc một số hương vị khác của cơ sở dữ liệu quan hệ.
Khi thiết kế bất kỳ loại cơ sở hạ tầng cơ sở dữ liệu nào, điều quan trọng là phải hiểu nhu cầu kinh doanh của bạn và quyết định loại khả dụng bạn cần đạt được.
Trong bài đăng trên blog này, chúng tôi sẽ xem xét các tùy chọn tính khả dụng cao cho các giải pháp dựa trên MySQL từ một trong những nhà cung cấp đám mây lớn nhất - Google Cloud Platform.
Triển khai Môi trường Khả dụng Cao bằng Phiên bản SQL GCP
Đối với blog này, chúng tôi muốn có một môi trường rất đơn giản - một cơ sở dữ liệu, có thể một hoặc hai bản sao. Chúng tôi muốn có thể chuyển đổi dự phòng dễ dàng và khôi phục hoạt động càng sớm càng tốt nếu bản chính bị lỗi. Chúng tôi sẽ sử dụng MySQL 5.7 làm phiên bản lựa chọn và bắt đầu với trình hướng dẫn triển khai phiên bản:
Sau đó, chúng ta phải tạo mật khẩu gốc, đặt tên phiên bản và xác định vị trí của nó:
Tiếp theo, chúng ta sẽ xem xét các tùy chọn cấu hình:
Chúng tôi có thể thực hiện các thay đổi về kích thước phiên bản (chúng tôi sẽ thực hiện với db-n1-standard-4), lịch trình lưu trữ và bảo trì. Điều quan trọng nhất đối với chúng tôi trong thiết lập này là các tùy chọn có tính khả dụng cao:
Tại đây chúng ta có thể chọn tạo bản sao chuyển đổi dự phòng. Bản sao này sẽ được thăng cấp thành bản chính nếu bản chính ban đầu bị lỗi.
Sau khi chúng tôi triển khai thiết lập, hãy thêm một nô lệ sao chép:
Sau khi quá trình thêm bản sao hoàn tất, chúng tôi đã sẵn sàng cho một số các bài kiểm tra. Chúng tôi sẽ chạy khối lượng công việc thử nghiệm bằng cách sử dụng Sysbench trên bản sao chính, chuyển đổi dự phòng và đọc bản sao để xem điều này sẽ diễn ra như thế nào. Chúng tôi sẽ chạy ba phiên bản của Sysbench, sử dụng các điểm cuối cho cả ba loại nút.
Sau đó, chúng tôi sẽ kích hoạt chuyển đổi dự phòng thủ công qua giao diện người dùng:
Thử nghiệm chuyển đổi dự phòng MySQL trên Google Cloud Platform?
Tôi đã đến thời điểm này mà không có bất kỳ kiến thức chi tiết nào về cách hoạt động của các nút SQL trong GCP. Tuy nhiên, tôi đã có một số kỳ vọng dựa trên trải nghiệm MySQL trước đây và những gì tôi đã thấy ở các nhà cung cấp đám mây khác. Đối với người mới bắt đầu, quá trình chuyển đổi dự phòng đến nút chuyển đổi dự phòng sẽ rất nhanh chóng. Những gì chúng tôi muốn là giữ nguyên các nô lệ sao chép sẵn có mà không cần phải xây dựng lại. Chúng tôi cũng muốn xem chúng tôi có thể thực hiện chuyển đổi dự phòng lần thứ hai nhanh như thế nào (vì không có gì lạ khi vấn đề lan truyền từ cơ sở dữ liệu này sang cơ sở dữ liệu khác).
Những gì chúng tôi đã xác định trong quá trình thử nghiệm của mình ...
- Trong khi không thành công, bản chính sẽ khả dụng trở lại sau 75 - 80 giây.
- Bản sao chuyển đổi dự phòng không khả dụng trong 5-6 phút.
- Bản sao đã đọc khả dụng trong quá trình chuyển đổi dự phòng, nhưng nó sẽ không khả dụng trong 55 - 60 giây sau khi bản sao chuyển đổi dự phòng có sẵn
Điều chúng tôi không chắc chắn về ...
Điều gì đang xảy ra khi không có bản sao chuyển đổi dự phòng? Dựa trên thời gian, có vẻ như bản sao chuyển đổi dự phòng đang được xây dựng lại. Điều này có lý, nhưng sau đó thời gian khôi phục sẽ liên quan nhiều đến kích thước của phiên bản (đặc biệt là hiệu suất I / O) và kích thước của tệp dữ liệu.
Điều gì đang xảy ra với bản sao đọc sau khi bản sao chuyển đổi dự phòng sẽ được xây dựng lại? Ban đầu, bản sao đã đọc được kết nối với bản chính. Khi bản gốc không thành công, chúng tôi mong đợi bản sao đã đọc cung cấp chế độ xem đã lỗi thời của tập dữ liệu. Khi bản chính mới xuất hiện, nó sẽ kết nối lại thông qua bản sao với bản sao (từng là bản sao chuyển đổi dự phòng và đã được thăng cấp thành bản chính). Không cần một phút ngừng hoạt động khi CHANGE MASTER đang được thực thi.
Quan trọng hơn, trong quá trình chuyển đổi dự phòng, không có cách nào để thực hiện chuyển đổi dự phòng khác (điều này hợp lý):
Cũng không thể quảng cáo bản sao đã đọc (điều này không nhất thiết có ý nghĩa - chúng tôi mong muốn có thể quảng bá các bản sao đã đọc bất cứ lúc nào).
Điều quan trọng cần lưu ý là dựa vào các bản sao đã đọc để cung cấp tính khả dụng cao (không tạo bản sao chuyển đổi dự phòng) không phải là một giải pháp khả thi. Bạn có thể thúc đẩy một bản sao đã đọc trở thành một bản chính, tuy nhiên một cụm mới sẽ được tạo; tách khỏi phần còn lại của các nút.
Không có cách nào để bổ sung các bản sao khác của bạn khỏi cụm mới. Cách duy nhất để làm điều này là tạo các bản sao mới, nhưng đây là một quá trình tốn nhiều thời gian. Nó cũng hầu như không thể sử dụng được, làm cho bản sao chuyển đổi dự phòng trở thành lựa chọn thực sự duy nhất để có tính khả dụng cao cho các nút SQL trong Google Cloud Platform.
Kết luận
Mặc dù có thể tạo môi trường có tính khả dụng cao cho các nút SQL trong GCP, nhưng cái chính sẽ không khả dụng trong khoảng một phút rưỡi. Toàn bộ quá trình (bao gồm xây dựng lại bản sao chuyển đổi dự phòng và một số hành động trên bản sao đã đọc) mất vài phút. Trong thời gian đó, chúng tôi không thể kích hoạt thêm một lần chuyển đổi dự phòng, cũng như không thể quảng cáo một bản sao đã đọc.
Chúng tôi có bất kỳ người dùng GCP nào ngoài đó không? Làm thế nào để bạn đạt được tính khả dụng cao?
