Ngày nay, cơ sở dữ liệu trải dài trên nhiều đám mây khá phổ biến. Chúng hứa hẹn tính sẵn sàng cao và khả năng dễ dàng thực hiện các quy trình khắc phục thảm họa. Chúng cũng là một phương pháp để tránh sự khóa nhà cung cấp:nếu bạn thiết kế môi trường cơ sở dữ liệu của mình để nó có thể hoạt động trên nhiều nhà cung cấp đám mây, rất có thể bạn không bị ràng buộc với các tính năng và triển khai dành riêng cho một nhà cung cấp cụ thể. Điều này giúp bạn dễ dàng thêm một nhà cung cấp cơ sở hạ tầng khác vào môi trường của mình, có thể là một đám mây khác hoặc thiết lập tại chỗ. Tính linh hoạt như vậy là rất quan trọng do có sự cạnh tranh gay gắt giữa các nhà cung cấp đám mây và việc di chuyển từ nhà cung cấp này sang nhà cung cấp khác có thể khá khả thi nếu nó được hỗ trợ bằng cách giảm chi phí.
Mở rộng cơ sở hạ tầng của bạn trên nhiều trung tâm dữ liệu (từ cùng một nhà cung cấp hay không, điều đó không thực sự quan trọng) mang lại những vấn đề nghiêm trọng cần giải quyết. Làm thế nào người ta có thể thiết kế toàn bộ cơ sở hạ tầng theo cách mà dữ liệu sẽ an toàn? Làm thế nào để đối phó với những thách thức mà bạn phải đối mặt khi làm việc trong môi trường đa đám mây? Trong blog này, chúng ta sẽ xem xét một thứ, nhưng được cho là nghiêm trọng nhất - tiềm năng của một bộ não phân chia. Nó có nghĩa là gì? Hãy cùng tìm hiểu một chút về phân chia não bộ là gì.
“Split-Brain” là gì?
Split-brain là một tình trạng trong đó một môi trường bao gồm nhiều nút bị phân vùng mạng và bị chia thành nhiều đoạn không có liên hệ với nhau. Trường hợp đơn giản nhất sẽ giống như sau:
Chúng tôi có hai nút, A và B, được kết nối qua mạng bằng bi sao chép không đồng bộ -directional. Sau đó, kết nối mạng bị cắt giữa các nút đó. Do đó, cả hai nút không thể kết nối với nhau và bất kỳ thay đổi nào được thực hiện trên nút A không thể được truyền đến nút B và ngược lại. Cả hai nút, A và B, đều thiết lập và chấp nhận kết nối, chúng chỉ không thể trao đổi dữ liệu. Điều này có thể dẫn đến các vấn đề nghiêm trọng vì ứng dụng có thể thực hiện các thay đổi trên cả hai nút mong muốn thấy trạng thái đầy đủ của cơ sở dữ liệu trong khi trên thực tế, nó chỉ hoạt động trên một trạng thái dữ liệu đã biết một phần. Do đó, ứng dụng có thể thực hiện các hành động không chính xác, kết quả không chính xác có thể được hiển thị cho người dùng, v.v. Chúng tôi nghĩ rằng rõ ràng não phân chia có khả năng là một tình trạng rất nguy hiểm và một trong những ưu tiên sẽ là giải quyết nó ở một mức độ nào đó. Có thể làm gì với nó?
Làm thế nào để Tránh phân tách não
Nói tóm lại là tùy. Vấn đề chính cần giải quyết là thực tế là các nút đang hoạt động nhưng không có kết nối giữa chúng, do đó chúng không biết về trạng thái của nút kia. Nói chung, sao chép không đồng bộ MySQL không có bất kỳ loại cơ chế nào có thể giải quyết nội bộ vấn đề của bộ não phân chia. Bạn có thể cố gắng thực hiện một số giải pháp giúp bạn tránh được tình trạng phân chia não bộ nhưng chúng có những hạn chế hoặc chúng vẫn không giải quyết được đầy đủ vấn đề.
Khi chúng ta thoát khỏi tính năng sao chép không đồng bộ, mọi thứ sẽ khác. MySQL Group Replication và MySQL Galera Cluster là những công nghệ được hưởng lợi từ nhận thức về cụm build-it. Cả hai giải pháp đó đều duy trì giao tiếp giữa các nút và đảm bảo rằng cụm nhận biết được trạng thái của các nút. Họ thực hiện một cơ chế túc số quản lý xem các cụm có thể hoạt động hay không.
Hãy thảo luận chi tiết hơn về hai giải pháp đó (sao chép không đồng bộ và cụm dựa trên túc số).
Phân nhóm dựa trên số đại biểu
Chúng ta sẽ không thảo luận về sự khác biệt triển khai giữa MySQL Galera Cluster và MySQL Group Replication, chúng ta sẽ tập trung vào ý tưởng cơ bản đằng sau phương pháp dựa trên túc số và cách nó được thiết kế để giải quyết vấn đề của phân chia bộ não trong cụm của bạn.
Điểm mấu chốt là:cluster, để hoạt động, yêu cầu phần lớn các nút của nó phải có sẵn. Với yêu cầu này, chúng tôi có thể chắc chắn rằng thiểu số không bao giờ có thể thực sự ảnh hưởng đến phần còn lại của cụm vì thiểu số không thể thực hiện bất kỳ hành động nào. Điều này cũng có nghĩa là, để có thể xử lý lỗi của một nút, một cụm phải có ít nhất ba nút. Nếu bạn chỉ có hai nút:
Khi có sự phân chia mạng, bạn kết thúc với hai phần của cụm, mỗi cụm bao gồm chính xác 50% tổng số nút trong cụm. Cả hai phần này đều không có đa số. Tuy nhiên, nếu bạn có ba nút, mọi thứ sẽ khác:
Các nút B và C chiếm đa số:phần đó bao gồm hai nút ngoài trong ba vì vậy nó có thể tiếp tục hoạt động. Mặt khác, nút A chỉ đại diện cho 33% số nút trong cụm do đó nó không có đa số và nó sẽ ngừng xử lý lưu lượng truy cập để tránh não bị chia cắt.
Với cách triển khai như vậy, rất khó xảy ra hiện tượng tách não (nó sẽ phải được giới thiệu thông qua một số trạng thái mạng kỳ lạ và không mong muốn, điều kiện chủng tộc hoặc các lỗi rõ ràng trong mã phân cụm. Mặc dù không phải là không thể gặp phải những điều kiện như vậy, sử dụng một trong những giải pháp dựa trên số đại biểu là lựa chọn tốt nhất để tránh tình trạng phân chia não trạng tồn tại vào thời điểm này.
Sao chép Không đồng bộ
Mặc dù không phải là lựa chọn lý tưởng khi nói đến việc xử lý phân tách não, nhưng sao chép không đồng bộ vẫn là một lựa chọn khả thi. Có một số điều bạn nên cân nhắc trước khi triển khai cơ sở dữ liệu đa đám mây với tính năng sao chép không đồng bộ.
Đầu tiên, chuyển đổi dự phòng. Sao chép không đồng bộ đi kèm với một trình ghi - chỉ bản chính mới có thể ghi được và các nút khác chỉ được phục vụ lưu lượng truy cập chỉ đọc. Thách thức là làm thế nào để đối phó với thất bại chính?
Hãy xem xét thiết lập như trên sơ đồ trên. Chúng tôi có hai nhà cung cấp dịch vụ đám mây, mỗi nhà cung cấp có hai nút. Nhà cung cấp A cũng là chủ. Điều gì sẽ xảy ra nếu chủ không thành công? Một trong những nô lệ nên được thúc đẩy để đảm bảo rằng cơ sở dữ liệu sẽ tiếp tục hoạt động. Lý tưởng nhất, nó nên là một quy trình tự động để giảm thời gian cần thiết để đưa cơ sở dữ liệu về trạng thái hoạt động. Tuy nhiên, điều gì sẽ xảy ra nếu có sự phân vùng mạng? Chúng tôi dự kiến sẽ xác minh trạng thái của cụm như thế nào?
Đây là thử thách. Kết nối mạng bị mất giữa hai nhà cung cấp dịch vụ đám mây. Từ quan điểm của các nút C và D, cả nút B và nút chính, nút A đang ngoại tuyến. Nút C hoặc D có nên được thăng cấp để trở thành nút chính không? Nhưng chủ cũ vẫn hoạt động - nó không bị sập, chỉ là không thể truy cập được qua mạng. Nếu chúng tôi quảng cáo một trong các nút nằm tại nhà cung cấp B, chúng tôi sẽ kết thúc với hai nút chính có thể ghi, hai tập dữ liệu và bộ não phân chia:
Đây chắc chắn không phải là thứ chúng ta muốn. Có một số lựa chọn ở đây. Đầu tiên, chúng ta có thể xác định các quy tắc chuyển đổi dự phòng theo cách mà quá trình chuyển đổi dự phòng có thể chỉ xảy ra ở một trong các phân đoạn mạng, nơi chứa cái chính. Trong trường hợp của chúng tôi, điều đó có nghĩa là chỉ nút B có thể được tự động thăng cấp để trở thành nút chính. Bằng cách đó, chúng tôi có thể đảm bảo rằng quá trình chuyển đổi dự phòng tự động sẽ xảy ra nếu nút A bị hỏng nhưng sẽ không có hành động nào được thực hiện nếu có sự phân vùng mạng. Một số công cụ có thể giúp bạn xử lý chuyển đổi dự phòng tự động (như ClusterControl) hỗ trợ danh sách trắng và danh sách đen, cho phép người dùng xác định nút nào có thể được coi là ứng cử viên để chuyển đổi dự phòng và nút nào không bao giờ được sử dụng làm nút chính.
Một tùy chọn khác sẽ là thực hiện một số loại giải pháp “nhận thức cấu trúc liên kết”. Ví dụ:người ta có thể cố gắng kiểm tra trạng thái chính bằng cách sử dụng các dịch vụ bên ngoài như bộ cân bằng tải.
Nếu tự động chuyển đổi dự phòng có thể kiểm tra trạng thái của cấu trúc liên kết như được thấy bởi bộ cân bằng tải, có thể là bộ cân bằng tải, nằm ở vị trí thứ ba, thực sự có thể tiếp cận cả hai trung tâm dữ liệu và làm rõ rằng các nút trong nhà cung cấp đám mây A không bị hỏng, chúng chỉ không thể truy cập được từ nhà cung cấp đám mây B. Như vậy một lớp kiểm tra bổ sung được triển khai trong ClusterControl.
Cuối cùng, bất kể công cụ nào bạn sử dụng để thực hiện chuyển đổi dự phòng tự động, nó cũng có thể được thiết kế để có thể nhận biết được số đại biểu. Sau đó, với ba nút trên ba vị trí, bạn có thể dễ dàng biết phần nào của cơ sở hạ tầng nên được duy trì tồn tại và phần nào không nên.
Ở đây, chúng ta có thể thấy rõ rằng vấn đề chỉ liên quan đến kết nối giữa các nhà cung cấp A và B. Nút quản lý C sẽ hoạt động như một rơle và do đó, không có chuyển đổi dự phòng nào được bắt đầu. Mặt khác, nếu một trung tâm dữ liệu bị cắt hoàn toàn:
Cũng khá rõ ràng chuyện gì đã xảy ra. Nút quản lý A sẽ báo cáo rằng nó không thể tiếp cận với phần lớn cụm trong khi các nút quản lý B và C sẽ tạo thành phần lớn. Có thể xây dựng dựa trên điều này và, ví dụ, viết các tập lệnh sẽ quản lý cấu trúc liên kết theo trạng thái của nút quản lý. Điều đó có thể có nghĩa là các tập lệnh được thực thi trong nhà cung cấp đám mây A sẽ phát hiện ra rằng nút quản lý A không chiếm đa số và chúng sẽ dừng tất cả các nút cơ sở dữ liệu để đảm bảo không có lần ghi nào xảy ra trong nhà cung cấp đám mây được phân vùng.
ClusterControl, khi được triển khai ở chế độ Tính sẵn sàng cao có thể được coi là các nút quản lý mà chúng tôi đã sử dụng trong các ví dụ của mình. Ba nút ClusterControl, trên đầu giao thức RAFT, có thể giúp bạn xác định xem một phân đoạn mạng nhất định có được phân vùng hay không.
Kết luận
Chúng tôi hy vọng bài đăng trên blog này cung cấp cho bạn một số ý tưởng về các tình huống phân chia não bộ có thể xảy ra đối với việc triển khai MySQL trải dài trên nhiều nền tảng đám mây.
