Chạy Cụm Galera trong đám mây kết hợp phải bao gồm ít nhất hai vị trí địa lý khác nhau, kết nối các máy chủ trong đám mây tại chỗ hoặc riêng với các máy chủ trong đám mây công cộng. Cho dù bạn sử dụng nền tảng đám mây riêng không thể phá vỡ hoặc đám mây công cộng, thì Disaster Recovery (DR) thực sự là một vấn đề quan trọng. Đây không phải là việc sao chép dữ liệu của bạn vào một trang web sao lưu và có thể khôi phục nó, đây là về tính liên tục trong kinh doanh và tốc độ bạn có thể khôi phục dịch vụ khi thảm họa xảy ra.
Trong bài đăng trên blog này, chúng tôi sẽ xem xét các cách khác nhau để thiết kế Cụm Galera của bạn để có khả năng chịu lỗi trong môi trường đám mây lai.
Active-Active Setup
Galera Cluster phải chạy với tổng số nút là số lẻ trong một cụm và thường bắt đầu với 3 nút. Điều này là do Galera Cluster sử dụng túc số để tự động xác định thành phần chính, nơi phần lớn các nút được kết nối sẽ có thể phục vụ cụm tại một thời điểm, trong trường hợp phân vùng theo cụm đã xảy ra.
Để thiết lập đám mây hỗn hợp thiết lập hoạt động tích cực, Galera yêu cầu ít nhất 3 trang web khác nhau, tạo thành Cụm Galera trên mạng WAN. Nói chung, bạn sẽ cần một trang web thứ ba hoạt động như một trọng tài, bỏ phiếu cho số đại biểu và giữ nguyên “thành phần chính” nếu không thể truy cập được bất kỳ trang web nào. Điều này có thể được thiết lập tối thiểu là một cụm 3 nút trên 3 trang web khác nhau (1 nút trên mỗi trang web), tương tự như sơ đồ sau:
Tuy nhiên, vì mục đích hiệu suất và độ tin cậy, bạn nên có 7 -cụm nút, như được hiển thị trong sơ đồ sau:
Đây được coi là cấu trúc liên kết tốt nhất để hỗ trợ thiết lập hoạt động tích cực, nơi trang web DR sẽ có sẵn gần như ngay lập tức mà không cần bất kỳ sự can thiệp nào. Cả hai trang web đều có thể nhận các lần đọc / ghi bất kỳ lúc nào miễn là cụm này nằm trong số đại biểu.
Tuy nhiên, rất tốn kém nếu có 3 trang web và 7 nút cơ sở dữ liệu (nút thứ 7 có thể được thay thế bằng một garbd vì nó rất khó được sử dụng để cung cấp dữ liệu cho máy khách / ứng dụng). Đây thường không phải là cách triển khai phổ biến khi bắt đầu dự án do chi phí trả trước rất lớn và cách truyền thông và nhân rộng của nhóm Galera nhạy cảm như thế nào với độ trễ của mạng.
Thiết lập Chủ động-Bị động
Trong cấu hình chủ động-thụ động, cần có ít nhất 2 trang web và chỉ một trang web hoạt động tại một thời điểm, được gọi là trang chính và các nút trên trang phụ chỉ sao chép dữ liệu đến từ trang chính máy chủ / cụm. Đối với Galera Cluster, chúng ta có thể sử dụng bản sao không đồng bộ MySQL (bản sao chủ-nô lệ) hoặc chúng ta cũng có thể sử dụng bản sao hầu như đồng bộ của Galera với một số điều chỉnh để giảm bớt sự sao chép tập viết của nó để hoạt động như bản sao không đồng bộ.
Trang web phụ phải được bảo vệ khỏi việc ghi ngẫu nhiên, bằng cách sử dụng cờ chỉ đọc, tường lửa ứng dụng, proxy ngược hoặc bất kỳ phương tiện nào khác vì luồng dữ liệu luôn đến từ trang chính đến trang phụ trừ khi chuyển đổi dự phòng đã bắt đầu và quảng bá trang web thứ cấp là trang web chính.
Sử dụng sao chép không đồng bộ
Một điều tốt về sao chép không đồng bộ là việc sao chép không ảnh hưởng đến máy chủ / cụm nguồn, nhưng nó được phép tụt hậu so với máy chủ. Thiết lập này sẽ làm cho trang web chính và trang web DR độc lập với nhau, được kết nối lỏng lẻo với tính năng sao chép không đồng bộ. Điều này có thể được thiết lập tối thiểu là một cụm 4 nút trên 2 trang web khác nhau, tương tự như sơ đồ sau:
Một trong các nút Galera trong trang DR sẽ là một nô lệ, nó sao chép từ một trong các nút Galera (chính) trong trang chính. Cả hai trang web đều phải tạo nhật ký nhị phân với GTID và log_slave_updates được bật - các bản cập nhật đến từ luồng sao chép không đồng bộ sẽ được áp dụng cho các nút khác trong cụm. Tuy nhiên, để sử dụng trong sản xuất, chúng tôi khuyên bạn nên có hai nhóm cụm trên cả hai trang web, như thể hiện trong sơ đồ sau:
Bằng cách có hai cụm riêng biệt, chúng sẽ được ghép nối lỏng lẻo và không ảnh hưởng đến nhau, ví dụ:lỗi cụm trên trang chính sẽ không ảnh hưởng đến trang DR. Về mặt hiệu suất, độ trễ của mạng WAN sẽ không ảnh hưởng đến các bản cập nhật trên cụm hoạt động. Chúng được vận chuyển không đồng bộ đến trang web sao lưu. Cụm DR có thể chạy trên các phiên bản nhỏ hơn trong môi trường đám mây công cộng, miễn là chúng có thể theo kịp cụm chính. Các phiên bản có thể được nâng cấp nếu cần. Các ứng dụng phải gửi các bản ghi đến trang chính và trang phụ phải được đặt để chạy ở chế độ chỉ đọc. Trang web khôi phục thảm họa có thể được sử dụng cho các mục đích khác như sao lưu cơ sở dữ liệu, sao lưu nhật ký nhị phân và báo cáo hoặc xử lý các truy vấn phân tích (OLAP).
Mặt khác, có khả năng mất dữ liệu trong quá trình chuyển đổi dự phòng / dự phòng nếu máy chủ bị trễ. Do đó, bạn nên bật tính năng sao chép bán đồng bộ để giảm nguy cơ mất dữ liệu. Lưu ý rằng việc sử dụng sao chép bán đồng bộ vẫn không đảm bảo chắc chắn chống lại việc mất dữ liệu, nếu so sánh với sao chép hầu như đồng bộ của Galera. Đọc kỹ hướng dẫn sử dụng MySQL này, chẳng hạn như những câu sau:
"Với sao chép bán đồng bộ, nếu nguồn gặp sự cố và quá trình chuyển đổi dự phòng sang bản sao được thực hiện, thì nguồn bị lỗi không được sử dụng lại làm nguồn sao chép và nên bị loại bỏ. Nó có thể có các giao dịch không được thừa nhận bởi bất kỳ bản sao nào, do đó không được cam kết trước khi chuyển đổi dự phòng. "
Quá trình chuyển đổi dự phòng khá đơn giản. Để quảng bá trang khôi phục thảm họa, chỉ cần tắt cờ chỉ đọc và bắt đầu hướng ứng dụng đến các nút cơ sở dữ liệu trong trang DR. Mặc dù vậy, chiến lược dự phòng hơi phức tạp và nó đòi hỏi một số chuyên môn trong việc sắp xếp dữ liệu trên cả hai trang web, chuyển đổi vai trò chủ / phụ của một cụm và chuyển hướng luồng sao chép nô lệ theo cách ngược lại.
Sử dụng Bản sao Galera
Đối với thiết lập chủ động-bị động, chúng tôi có thể đặt phần lớn các nút nằm trong trang web chính trong khi phần nhỏ các nút nằm trong trang web khôi phục thảm họa, như được hiển thị trong ảnh chụp màn hình sau cho 3 nút Galera Cluster:
Nếu trang web chính bị lỗi, cụm sẽ không thành công vì nó đã hết túc số. Nút Galera trên trang web khôi phục thảm họa (db3-dr) sẽ cần được khởi động theo cách thủ công như một thành phần chính của nút duy nhất. Sau khi trang web chính hoạt động trở lại, cả hai nút trên trang web chính (db1-prod và db2-prod) cần phải tham gia lại galera3 để được đồng bộ hóa. Có một bộ nhớ đệm khá lớn sẽ giúp giảm nguy cơ SST qua mạng WAN. Kiến trúc này dễ thiết lập và quản lý và rất tiết kiệm chi phí.
Chuyển đổi dự phòng là thủ công, vì quản trị viên cần quảng bá nút đơn làm thành phần chính (bootstrap db3-dr hoặc sử dụng set pc.bootstrap =1 trong tham số wsrep_provider_options. Sẽ có thời gian ngừng hoạt động trong thời gian chờ đợi . Hiệu suất có thể là một vấn đề, vì trang DR sẽ chạy với số lượng nút ít hơn (vì trang DR luôn là thiểu số) để chạy hết tải. Có thể mở rộng quy mô với nhiều nút hơn sau khi chuyển sang Trang web DR nhưng hãy cẩn thận với tải bổ sung.
Lưu ý rằng Galera Cluster nhạy cảm với mạng do tính chất hầu như đồng bộ của nó. Các nút Galera càng xa trong một cụm nhất định, thì độ trễ càng cao và khả năng ghi của nó để phân phối và xác nhận các tập ghi càng cao. Ngoài ra, nếu kết nối không ổn định, việc phân vùng theo cụm có thể dễ dàng xảy ra, điều này có thể kích hoạt đồng bộ hóa cụm trên các nút kết hợp. Trong một số trường hợp, điều này có thể tạo ra sự không ổn định cho cụm. Điều này yêu cầu một chút điều chỉnh các thông số Galera, như được hiển thị trong bài đăng trên blog này, Triển khai Môi trường Cơ sở hạ tầng Kết hợp cho Cụm Percona XtraDB.
Lời kết
Galera Cluster là một công nghệ tuyệt vời có thể được triển khai theo nhiều cách khác nhau - một cụm trải dài trên nhiều địa điểm, nhiều cụm được giữ đồng bộ thông qua sao chép không đồng bộ, hỗn hợp sao chép đồng bộ và không đồng bộ, v.v. Giải pháp thực tế sẽ được quyết định bởi các yếu tố như độ trễ của mạng WAN, cuối cùng so với tính nhất quán dữ liệu mạnh mẽ và ngân sách.
