Cách thiết lập sao chép không đồng bộ giữa các cụm MySQL Galera

Cụm Galera thực thi tính nhất quán dữ liệu mạnh mẽ, trong đó tất cả các nút trong cụm được kết hợp chặt chẽ với nhau. Mặc dù phân đoạn mạng được hỗ trợ, hiệu suất sao chép vẫn bị ràng buộc bởi hai yếu tố:

Thời gian khứ hồi (RTT) đến nút xa nhất trong cụm từ nút khởi tạo.
Kích thước của bộ ghi sẽ được chuyển và chứng nhận xung đột trên nút thu.

Mặc dù có nhiều cách để tăng hiệu suất của Galera, nhưng không thể khắc phục được hai yếu tố hạn chế này.

May mắn thay, Galera Cluster được xây dựng trên MySQL, cũng đi kèm với tính năng sao chép tích hợp (duh!). Cả bản sao Galera và bản sao MySQL đều tồn tại trong cùng một phần mềm máy chủ một cách độc lập. Chúng ta có thể sử dụng các công nghệ này để làm việc cùng nhau, nơi mà tất cả các bản sao trong một trung tâm dữ liệu sẽ được thực hiện trên Galera, trong khi bản sao liên trung tâm dữ liệu sẽ trên MySQL Replication tiêu chuẩn. Trang web nô lệ có thể hoạt động như một trang web chờ nóng, sẵn sàng cung cấp dữ liệu khi các ứng dụng được chuyển hướng đến trang web sao lưu. Chúng tôi đã đề cập vấn đề này trong một blog trước đây về kiến trúc MySQL để khôi phục sau thảm họa.

Sao chép cụm-thành-cụm đã được giới thiệu trong ClusterControl trong phiên bản 1.7.4. Trong bài đăng blog này, chúng tôi sẽ cho thấy việc thiết lập sao chép giữa hai Cụm Galera (PXC 8.0) đơn giản như thế nào. Sau đó, chúng ta sẽ xem xét phần thách thức hơn:xử lý lỗi ở cả cấp độ nút và cụm với sự trợ giúp của ClusterControl; chuyển đổi dự phòng và các hoạt động dự phòng là rất quan trọng để duy trì tính toàn vẹn của dữ liệu trên toàn hệ thống.

Triển khai theo cụm

Vì lợi ích của ví dụ của chúng tôi, chúng tôi sẽ cần ít nhất hai cụm và hai trang web - một cho chính và một cho phụ. Nó hoạt động tương tự như bản sao MySQL master-slave truyền thống nhưng ở quy mô lớn hơn với ba nút cơ sở dữ liệu trong mỗi trang web. Với ClusterControl, bạn sẽ đạt được điều này bằng cách triển khai một cụm chính, tiếp theo là triển khai cụm phụ trên trang web khắc phục thảm họa dưới dạng một cụm sao, được sao chép bởi một bản sao không đồng bộ hai hướng.

Sơ đồ sau minh họa kiến trúc cuối cùng của chúng tôi:

Tổng cộng chúng tôi có sáu nút cơ sở dữ liệu, ba nút trên trang chính và một nút khác ba trên địa điểm khắc phục hậu quả thiên tai. Để đơn giản hóa việc biểu diễn nút, chúng tôi sẽ sử dụng các ký hiệu sau:

Trang web chính:
- galera1-P - 192.168.11.171 (chính)
- galera2-P - 192.168.11.172
- galera3-P - 192.168.11.173
Trang web khôi phục thảm họa:
- galera1-DR - 192.168.11.181 (nô lệ)
- galera2-DR - 192.168.11.182
- galera3-DR - 192.168.11.183

Đầu tiên, chỉ cần triển khai cụm đầu tiên và chúng tôi gọi nó là PXC-Primary. Mở giao diện người dùng ClusterControl → Triển khai → MySQL Galera và nhập tất cả các chi tiết được yêu cầu:

Đảm bảo mọi nút được chỉ định đều có dấu tích màu xanh lá cây bên cạnh, cho biết rằng ClusterControl có thể kết nối với máy chủ thông qua SSH không cần mật khẩu. Nhấp vào Triển khai và đợi quá trình triển khai hoàn tất. Sau khi hoàn tất, bạn sẽ thấy cụm sau được liệt kê trên trang bảng điều khiển cụm:

Tiếp theo, chúng ta sẽ sử dụng tính năng ClusterControl được gọi là Create Replica Cluster, có thể truy cập từ trình đơn thả xuống Hành động cụm:

Bạn sẽ thấy cửa sổ bật lên của thanh bên sau:

Chúng tôi đã chọn tùy chọn "Phát trực tuyến từ Master", trong đó ClusterControl sẽ sử dụng chủ đã chọn để đồng bộ cụm bản sao và định cấu hình bản sao. Chú ý đến tùy chọn sao chép hai hướng. Nếu được bật, ClusterControl sẽ thiết lập một bản sao hai chiều giữa cả hai vị trí (sao chép vòng tròn). Bản chính được chọn sẽ sao chép từ bản chính đầu tiên được xác định cho cụm bản sao và ngược lại. Thiết lập này sẽ giảm thiểu thời gian dàn dựng cần thiết khi khôi phục sau khi chuyển đổi dự phòng hoặc sao lưu dự phòng. Nhấp vào "Tạo cụm bản sao", tại đây ClusterControl sẽ mở một trình hướng dẫn triển khai mới cho cụm bản sao, như được hiển thị bên dưới:

Bạn nên bật mã hóa SSL nếu quá trình sao chép liên quan đến các mạng không đáng tin cậy như WAN, mạng không đường hầm, hoặc Internet. Ngoài ra, hãy đảm bảo rằng "Tạo cụm dưới dạng chỉ đọc" được bật tắt; đây là biện pháp bảo vệ chống lại việc ghi ngẫu nhiên và là một chỉ báo tốt để dễ dàng phân biệt giữa cụm chủ động (đọc-ghi) và cụm bị động (chỉ đọc).

Khi điền vào tất cả các thông tin cần thiết, bạn sẽ đến giai đoạn sau để xác định cấu trúc liên kết cụm bản sao:

Từ trang tổng quan ClusterControl, khi việc triển khai hoàn tất, bạn sẽ thấy Trang web DR có một mũi tên hai chiều được kết nối với trang web Chính:

Việc triển khai hiện đã hoàn tất. Các ứng dụng chỉ nên gửi ghi tới Trang chính vì đây là trang đang hoạt động và trang DR được định cấu hình ở chế độ chỉ đọc (được đánh dấu bằng màu vàng). Các bài đọc có thể được gửi đến cả hai trang, mặc dù trang DR có nguy cơ bị tụt hậu do tính chất sao chép không đồng bộ. Thiết lập này sẽ làm cho các trang khôi phục sau thảm họa và chính độc lập với nhau, được kết nối lỏng lẻo với sao chép không đồng bộ. Một trong các nút Galera trong trang DR sẽ là một nô lệ sao chép từ một trong các nút Galera (chính) trong trang chính.

Bây giờ chúng tôi có một hệ thống mà lỗi cụm trên trang chính sẽ không ảnh hưởng đến trang dự phòng. 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.

Ngoài ra, cũng có thể có một phiên bản nô lệ chuyên dụng làm bộ chuyển tiếp nhân bản thay vì sử dụng một trong các nút Galera làm phụ kiện.

Quy trình chuyển đổi dự phòng nút Galera

Trong trường hợp nút chính hiện tại (galera1-P) bị lỗi và các nút còn lại trong Trang web chính vẫn hoạt động, nút phụ trên trang Khôi phục thảm họa (galera1-DR) phải được chuyển hướng đến bất kỳ nút nào có sẵn trên Trang web chính, như được hiển thị trong sơ đồ sau:

Từ danh sách cụm ClusterControl, bạn có thể thấy rằng trạng thái cụm bị giảm và nếu bạn di chuột qua biểu tượng dấu chấm than, bạn có thể thấy lỗi cho nút cụ thể đó (galera1-P):

Với ClusterControl, bạn chỉ cần đi tới cụm PXC-DR → Nodes → chọn galera1-DR → Node Actions → Rebuild Replication Slave, và bạn sẽ thấy hộp thoại cấu hình sau:

Chúng tôi có thể thấy tất cả các nút Galera tại Trang web chính (192.168.11.17x ) từ danh sách thả xuống. Chọn nút phụ, 192.168.11.172 (galera2-P) và nhấp vào Tiếp tục. Sau đó, ClusterControl sẽ định cấu hình cấu trúc liên kết sao chép như bình thường, thiết lập sao chép hai chiều từ galera2-P sang galera1-DR. Bạn có thể xác nhận điều này từ trang bảng điều khiển cụm (được đánh dấu bằng màu vàng):

Tại thời điểm này, cụm chính (PXC-Primary) vẫn đang phân phát là cụm hoạt động cho cấu trúc liên kết này. Nó sẽ không ảnh hưởng đến thời gian hoạt động của dịch vụ cơ sở dữ liệu của cụm chính.

Quy trình chuyển đổi dự phòng cụm Galera

Nếu cụm chính gặp sự cố, gặp sự cố hoặc đơn giản là mất kết nối từ quan điểm ứng dụng, ứng dụng có thể được chuyển hướng đến trang DR gần như ngay lập tức. SysAdmin chỉ cần tắt chế độ chỉ đọc trên tất cả các nút Galera trên trang web khôi phục thảm họa bằng cách sử dụng câu lệnh sau:

mysql> SET GLOBAL read_only = 0; -- repeat on galera1-DR, galera2-DR, galera3-DR

Đối với người dùng ClusterControl, bạn có thể sử dụng ClusterControl UI → Nodes → chọn nút DB → Node Actions → Disable Read-only. ClusterControl CLI cũng có sẵn, bằng cách thực hiện các lệnh sau trên nút ClusterControl:

$ s9s node --nodes="192.168.11.181" --cluster-id=11 --set-read-write
$ s9s node --nodes="192.168.11.182" --cluster-id=11 --set-read-write
$ s9s node --nodes="192.168.11.183" --cluster-id=11 --set-read-write

Quá trình chuyển đổi dự phòng sang trang DR hiện đã hoàn tất và các ứng dụng có thể bắt đầu gửi các bản ghi tới cụm PXC-DR. Từ giao diện người dùng ClusterControl, bạn sẽ thấy một cái gì đó như sau:

Sơ đồ sau cho thấy kiến trúc của chúng tôi sau khi ứng dụng không vào được trang web DR :

Giả sử Trang web chính vẫn không hoạt động, tại thời điểm này, không có nhân rộng giữa các trang web cho đến khi Trang web chính hoạt động trở lại.

Quy trình dự phòng cụm Galera

Sau khi trang web chính xuất hiện, điều quan trọng cần lưu ý là cụm chính phải được đặt thành chỉ đọc, vì vậy chúng tôi biết rằng cụm đang hoạt động là cụm trong trang web khôi phục thảm họa. Từ ClusterControl, đi tới trình đơn thả xuống của cụm và chọn "Bật chỉ đọc", thao tác này sẽ cho phép chỉ đọc trên tất cả các nút trong cụm chính và tóm tắt cấu trúc liên kết hiện tại như bên dưới:

Đảm bảo rằng mọi thứ đều có màu xanh lục trước khi bắt đầu quy trình dự phòng cụm (màu xanh lục có nghĩa là tất cả các nút được thiết lập và đồng bộ hóa với nhau). Nếu có một nút đang ở trạng thái xuống cấp, ví dụ:nút sao chép vẫn bị tụt lại phía sau hoặc chỉ một số nút trong cụm chính có thể truy cập được, hãy đợi cho đến khi cụm được khôi phục hoàn toàn, bằng cách chờ quy trình khôi phục tự động ClusterControl để hoàn thành hoặc can thiệp thủ công.

Tại thời điểm này, cụm hoạt động vẫn là cụm của DR, và cụm chính hoạt động như một cụm phụ. Sơ đồ sau minh họa kiến trúc hiện tại:

Cách an toàn nhất để dự phòng trở lại Trang web chính là đặt chỉ đọc trên cụm của DR, tiếp theo là tắt chế độ chỉ đọc trên Trang web chính. Đi tới Giao diện người dùng ClusterControl → PXC-DR (menu thả xuống) → Bật Chỉ đọc. Điều này sẽ kích hoạt công việc thiết lập chỉ đọc trên tất cả các nút trên cụm DR. Sau đó, đi tới ClusterControl UI → PXC-Primary → Nodes và tắt chế độ chỉ đọc trên tất cả các nút cơ sở dữ liệu trong cụm chính.

Bạn cũng có thể đơn giản hóa các quy trình trên với ClusterControl CLI. Ngoài ra, hãy thực hiện các lệnh sau trên máy chủ ClusterControl:

$ s9s cluster --cluster-id=11 --set-read-only # enable cluster-wide read-only
$ s9s node --nodes="192.168.11.171" --cluster-id=8 --set-read-write
$ s9s node --nodes="192.168.11.172" --cluster-id=8 --set-read-write
$ s9s node --nodes="192.168.11.173" --cluster-id=8 --set-read-write

Sau khi thực hiện xong, hướng sao chép đã quay trở lại cấu hình ban đầu, trong đó PXC-Primary là cụm hoạt động và PXC-DR là cụm dự phòng. Sơ đồ sau minh họa kiến trúc cuối cùng sau hoạt động dự phòng cụm:

Tại thời điểm này, bạn có thể chuyển hướng các ứng dụng để viết trên đó một cách an toàn Trang web chính.

Ưu điểm của Sao chép không đồng bộ cụm-thành-cụm

Cluster-to-cluster với sao chép không đồng bộ có một số ưu điểm:

Thời gian chết tối thiểu trong quá trình chuyển đổi dự phòng cơ sở dữ liệu. Về cơ bản, bạn có thể chuyển hướng ghi gần như ngay lập tức đến trang web nô lệ, chỉ khi bạn có thể bảo vệ các ghi không đến được trang chủ (vì những ghi này sẽ không được sao chép và có thể sẽ bị ghi đè khi đồng bộ hóa lại từ trang DR).
Không ảnh hưởng đến hiệu suất trên trang chính vì nó độc lập với trang dự phòng (DR). Việc sao chép từ chủ đến tớ được thực hiện không đồng bộ. Trang web chính tạo nhật ký nhị phân, trang web phụ sao chép các sự kiện và áp dụng các sự kiện sau đó.
Cá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, chẳng hạn 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 các truy vấn phân tích nặng (OLAP). Cả hai trang web có thể được sử dụng đồng thời, ngoại trừ độ trễ của bản sao và các hoạt động chỉ đọc ở phía máy chủ.
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 với cụm chính. Bạn có thể nâng cấp các phiên bản nếu cần. Trong một số trường hợp nhất định, nó có thể giúp bạn tiết kiệm một số chi phí.
Bạn chỉ cần một trang web bổ sung cho Khôi phục thảm họa so với thiết lập nhân rộng nhiều trang web Galera đang hoạt động, mà yêu cầu ít nhất ba trang web đang hoạt động để hoạt động chính xác.

Nhược điểm của Sao chép không đồng bộ theo cụm-thành-cụm

Thiết lập này cũng có những hạn chế, tùy thuộc vào việc bạn đang sử dụng sao chép hai chiều hay một chiều:

Có khả năng thiếu một số dữ liệu trong quá trình chuyển đổi dự phòng nếu nô lệ ở sau, vì sao chép là không đồng bộ. Điều này có thể được cải thiện với sao chép nô lệ bán đồng bộ và đa luồng, mặc dù sẽ có một loạt thách thức khác đang chờ đợi (chi phí mạng, khoảng cách sao chép, v.v.).
Trong sao chép một chiều, mặc dù các thủ tục chuyển đổi dự phòng khá đơn giản, các thủ tục dự phòng có thể phức tạp và dễ bị con người lỗi. Nó yêu cầu một số kiến thức chuyên môn về việc chuyển đổi vai trò chủ / tớ trở lại trang web chính. Bạn nên ghi lại các thủ tục, diễn tập hoạt động chuyển đổi dự phòng / dự phòng thường xuyên và sử dụng các công cụ giám sát và báo cáo chính xác.
Nó có thể khá tốn kém, vì bạn phải thiết lập một số lượng nút tương tự trên trang web khôi phục thảm họa . Đây không phải là trắng đen, vì việc biện minh chi phí thường xuất phát từ các yêu cầu của doanh nghiệp bạn. Với một số kế hoạch, có thể tối đa hóa việc sử dụng tài nguyên cơ sở dữ liệu ở cả hai trang web, bất kể vai trò cơ sở dữ liệu.

Kết thúc

Thiết lập sao chép không đồng bộ cho MySQL Galera Cluster của bạn có thể là một quá trình tương đối đơn giản - miễn là bạn hiểu cách xử lý đúng các lỗi ở cả cấp độ nút và cụm. Cuối cùng, các hoạt động chuyển đổi dự phòng và dự phòng là rất quan trọng để đảm bảo tính toàn vẹn của dữ liệu.

Để biết thêm mẹo về thiết kế Galera Cluster của bạn có lưu ý đến các chiến lược chuyển đổi dự phòng và dự phòng, hãy xem bài đăng này về kiến trúc MySQL để khôi phục sau thảm họa. Nếu bạn đang tìm kiếm trợ giúp để tự động hóa các hoạt động này, hãy đánh giá ClusterControl miễn phí trong 30 ngày và làm theo các bước trong bài đăng này.

Đừng quên theo dõi chúng tôi trên Twitter hoặc LinkedIn và đăng ký nhận bản tin của chúng tôi để được cập nhật những tin tức mới nhất và các phương pháp hay nhất để quản lý cơ sở hạ tầng cơ sở dữ liệu nguồn mở của bạn.