Đã qua lâu rồi những ngày cơ sở dữ liệu được triển khai dưới dạng một nút hoặc phiên bản duy nhất - một máy chủ độc lập, mạnh mẽ được giao nhiệm vụ xử lý tất cả các yêu cầu đến cơ sở dữ liệu. Chia tỷ lệ dọc là cách để đi - thay thế máy chủ bằng một máy chủ khác, thậm chí mạnh hơn. Trong thời gian này, người ta không thực sự phải bận tâm đến hiệu suất mạng. Miễn là có các yêu cầu, tất cả đều tốt.
Nhưng ngày nay, cơ sở dữ liệu được xây dựng dưới dạng cụm với các nút được kết nối với nhau qua mạng. Nó không phải lúc nào cũng là một mạng cục bộ, nhanh chóng. Với các doanh nghiệp vươn ra quy mô toàn cầu, cơ sở hạ tầng cơ sở dữ liệu cũng phải trải dài trên toàn cầu, để luôn gần gũi với khách hàng và giảm độ trễ. Nó đi kèm với những thách thức bổ sung mà chúng ta phải đối mặt khi thiết kế một môi trường cơ sở dữ liệu có tính khả dụng cao. Trong bài đăng trên blog này, chúng tôi sẽ xem xét các vấn đề mạng mà bạn có thể gặp phải và đưa ra một số đề xuất về cách giải quyết chúng.
Hai tùy chọn chính cho MySQL hoặc MariaDB HA
Chúng tôi đã đề cập chủ đề cụ thể này khá rộng rãi trong một trong các sách trắng, nhưng hãy xem xét hai cách chính để xây dựng tính khả dụng cao cho MySQL và MariaDB.
Cụm Galera
Galera Cluster là công nghệ cụm hầu như không đồng bộ cho MySQL. Nó cho phép xây dựng các thiết lập nhiều người viết có thể trải dài trên toàn cầu. Galera phát triển mạnh trong môi trường có độ trễ thấp nhưng nó cũng có thể được cấu hình để hoạt động với các kết nối WAN dài. Galera có một cơ chế túc số được tích hợp sẵn để đảm bảo rằng dữ liệu sẽ không bị xâm phạm trong trường hợp phân vùng mạng của một số nút.
Bản sao MySQL
MySQL Replication có thể là không đồng bộ hoặc bán đồng bộ. Cả hai đều được thiết kế để xây dựng các cụm nhân rộng quy mô lớn. Giống như trong bất kỳ thiết lập sao chép master-slave hoặc chính-phụ nào khác, chỉ có thể có một người viết, chính. Các nút khác, nô lệ, được sử dụng cho mục đích chuyển đổi dự phòng vì chúng chứa bản sao của tập dữ liệu từ maser. Các nô lệ cũng có thể được sử dụng để đọc dữ liệu và giảm tải một số khối lượng công việc từ trang cái.
Cả hai giải pháp đều có các giới hạn và tính năng riêng, cả hai đều gặp phải các vấn đề khác nhau. Cả hai đều có thể bị ảnh hưởng bởi kết nối mạng không ổn định. Hãy xem xét những hạn chế đó và cách chúng tôi có thể thiết kế môi trường để giảm thiểu tác động của cơ sở hạ tầng mạng không ổn định.
Galera Cluster - Sự cố mạng
Đầu tiên, chúng ta hãy xem xét Cụm Galera. Như chúng ta đã thảo luận, nó hoạt động tốt nhất trong môi trường có độ trễ thấp. Một trong những vấn đề chính liên quan đến độ trễ trong Galera là cách Galera xử lý các lần ghi. Chúng tôi sẽ không đi vào tất cả các chi tiết trong blog này, nhưng đọc thêm trong hướng dẫn Galera Cluster cho MySQL của chúng tôi. Điểm mấu chốt là, do quá trình chứng nhận để ghi, nơi tất cả các nút trong cụm phải đồng ý về việc ghi có thể được áp dụng hay không, hiệu suất ghi của bạn cho hàng đơn bị giới hạn nghiêm ngặt bởi thời gian vòng quanh mạng giữa người viết. nút và nút xa nhất. Miễn là độ trễ có thể chấp nhận được và miễn là bạn không có quá nhiều điểm phát sóng trong dữ liệu của mình, thiết lập WAN có thể hoạt động tốt. Sự cố bắt đầu xảy ra khi độ trễ mạng tăng đột biến theo thời gian. Khi đó, quá trình ghi sẽ lâu hơn gấp 3 hoặc 4 lần so với bình thường và do đó, cơ sở dữ liệu có thể bắt đầu bị quá tải khi ghi trong thời gian dài.
Một trong những tính năng tuyệt vời của Galera Cluster là khả năng phát hiện trạng thái cụm và phản ứng khi phân vùng mạng. Nếu không thể truy cập vào một nút của cụm, nó sẽ bị loại khỏi cụm và nó sẽ không thể thực hiện bất kỳ lần ghi nào. Điều này rất quan trọng trong việc duy trì tính toàn vẹn của dữ liệu trong thời gian cụm được tách ra - chỉ phần lớn nhóm chấp nhận ghi. Thiểu số sẽ phàn nàn. Để xử lý điều này, Galera giới thiệu một loạt các kiểm tra và thời gian chờ có thể định cấu hình để tránh cảnh báo sai về các sự cố mạng rất thoáng qua. Thật không may, nếu mạng không đáng tin cậy, Galera Cluster sẽ không thể hoạt động chính xác - các nút sẽ bắt đầu rời khỏi cụm, tham gia nó sau. Nó sẽ đặc biệt có vấn đề khi chúng tôi có Cụm Galera trải dài qua mạng WAN - các phần tách biệt của cụm có thể biến mất ngẫu nhiên nếu mạng kết nối không hoạt động bình thường.
Làm thế nào để thiết kế Cụm Galera cho một mạng không ổn định?
Đầu tiên, nếu bạn gặp sự cố mạng trong một trung tâm dữ liệu, bạn sẽ không thể làm được gì nhiều trừ khi bạn có thể giải quyết những vấn đề đó bằng cách nào đó. Mạng cục bộ không đáng tin cậy là điều không nên đối với Galera Cluster, bạn phải xem xét lại việc sử dụng một số giải pháp khác (mặc dù thành thật mà nói, mạng không đáng tin cậy sẽ luôn là một vấn đề). Mặt khác, nếu các vấn đề chỉ liên quan đến kết nối WAN (và đây là một trong những trường hợp điển hình nhất), có thể thay thế các liên kết WAN Galera bằng sao chép không đồng bộ thường xuyên (nếu điều chỉnh WAN Galera không giúp ích được gì).
Có một số hạn chế cố hữu trong thiết lập này - vấn đề chính là việc ghi thường xảy ra cục bộ. Bây giờ, tất cả các lần ghi sẽ phải đi đến trung tâm dữ liệu “chính” (DC A trong trường hợp của chúng tôi). Điều này không phải là xấu như nó âm thanh. Xin lưu ý rằng trong môi trường all-Galera, quá trình ghi sẽ bị chậm lại do độ trễ giữa các nút nằm trong các trung tâm dữ liệu khác nhau. Ngay cả các bài viết địa phương cũng sẽ bị ảnh hưởng. Nó sẽ ít nhiều xảy ra tình trạng chậm tương tự như khi thiết lập không đồng bộ, trong đó bạn sẽ gửi các bản ghi qua mạng WAN đến trung tâm dữ liệu “chính”.
Sử dụng sao chép không đồng bộ đi kèm với tất cả các vấn đề điển hình cho sao chép không đồng bộ. Độ trễ của bản sao có thể trở thành một vấn đề - không phải Galera sẽ hoạt động tốt hơn, mà chỉ là Galera sẽ làm chậm lưu lượng truy cập thông qua điều khiển luồng trong khi bản sao không có bất kỳ cơ chế nào để điều chỉnh lưu lượng trên bản chính.
Một vấn đề khác là chuyển đổi dự phòng:nếu nút Galera “chính” (nút đóng vai trò chủ đối với các nô lệ trong các trung tâm dữ liệu khác) bị lỗi, một số cơ chế phải được tạo ra để chỉ định lại các nô lệ cho một nút chính đang hoạt động khác. Nó có thể là một loại kịch bản nào đó, cũng có thể thử một cái gì đó với VIP trong đó cụm Galera “nô lệ” tắt IP ảo luôn được gán cho nút Galera còn sống trong cụm “chủ”.
Ưu điểm chính của việc thiết lập như vậy là chúng tôi loại bỏ liên kết WAN Galera, điều đó có nghĩa là cụm "chính" của chúng tôi sẽ không bị chậm lại do một số nút bị tách biệt về mặt địa lý. Như chúng tôi đã đề cập, chúng tôi mất khả năng viết trong tất cả các trung tâm dữ liệu nhưng việc viết theo độ trễ khôn ngoan trên mạng WAN cũng giống như viết cục bộ vào cụm Galera trải dài trên mạng WAN. Do đó, độ trễ tổng thể sẽ được cải thiện. Sao chép không đồng bộ cũng ít bị ảnh hưởng bởi các mạng không ổn định. Trường hợp xấu nhất, liên kết sao chép sẽ bị đứt và nó sẽ được tạo lại khi các mạng hội tụ.
Làm cách nào để thiết kế bản sao MySQL cho một mạng không ổn định?
Trong phần trước, chúng tôi đã đề cập đến cụm Galera và một giải pháp là sử dụng sao chép không đồng bộ. Nó trông như thế nào trong một thiết lập sao chép không đồng bộ đơn giản? Hãy xem cách mạng không ổn định có thể gây ra gián đoạn lớn nhất trong quá trình thiết lập nhân rộng.
Trước hết, độ trễ - một trong những điểm đau chính của Galera Cluster. Trong trường hợp nhân rộng, nó gần như là một vấn đề không. Trừ khi bạn sử dụng sao chép bán đồng bộ - trong trường hợp đó, độ trễ tăng lên sẽ làm chậm quá trình ghi. Trong sao chép không đồng bộ, độ trễ không ảnh hưởng đến hiệu suất ghi. Tuy nhiên, nó có thể có một số tác động đến độ trễ sao chép. Nó không phải là bất cứ điều gì đáng kể như đối với Galera nhưng bạn có thể mong đợi nhiều lần giật lag hơn và hiệu suất sao chép tổng thể kém ổn định hơn nếu mạng giữa các nút có độ trễ cao. Điều này chủ yếu là do cái chính cũng có thể phục vụ một số lần ghi trước khi quá trình truyền dữ liệu tới máy phụ có thể được bắt đầu trên mạng có độ trễ cao.
Sự không ổn định của mạng chắc chắn có thể ảnh hưởng đến các liên kết sao chép nhưng một lần nữa, nó không quá nghiêm trọng. Các nô lệ MySQL sẽ cố gắng kết nối lại với các bản gốc của chúng và quá trình nhân rộng sẽ bắt đầu.
Vấn đề chính với sao chép MySQL thực sự là một cái gì đó mà Galera Cluster giải quyết nội bộ - phân vùng mạng. Chúng ta đang nói về phân vùng mạng là điều kiện trong đó các phân đoạn của mạng được tách biệt với nhau. Bản sao MySQL sử dụng một nút người viết duy nhất - nút chính. Bất kể bạn thiết kế môi trường của mình như thế nào, bạn phải gửi bài viết của mình cho người chủ. Nếu bản gốc không khả dụng (vì bất kỳ lý do gì), ứng dụng không thể thực hiện công việc của mình trừ khi nó chạy ở một số loại chế độ chỉ đọc. Do đó cần phải chọn chủ nhân mới càng sớm càng tốt. Đây là nơi các vấn đề xuất hiện.
Đầu tiên, làm thế nào để biết máy chủ nào là chính và máy nào không. Một trong những cách thông thường là sử dụng biến “read_only” để phân biệt nô lệ với chủ. Nếu nút đã bật read_only (đặt read_only =1), nó là một nô lệ (vì các nô lệ không nên xử lý bất kỳ ghi trực tiếp nào). Nếu nút đã tắt read_only (đặt read_only =0), nó là một nút chính. Để làm cho mọi thứ an toàn hơn, một cách tiếp cận phổ biến là đặt read_only =1 trong cấu hình MySQL - trong trường hợp khởi động lại, sẽ an toàn hơn nếu nút hiển thị dưới dạng nô lệ. “Ngôn ngữ” như vậy có thể được hiểu bởi các proxy như ProxySQL hoặc MaxScale.
Hãy xem một ví dụ.
Chúng tôi có các máy chủ ứng dụng kết nối với lớp proxy. Các proxy thực hiện phân chia đọc / ghi gửi các SELECT tới các nô lệ và ghi lên chủ. Nếu cái chính gặp sự cố, chuyển đổi dự phòng được thực hiện, cái chính mới được thăng cấp, lớp proxy sẽ phát hiện ra điều đó và bắt đầu gửi ghi tới một nút khác.
Nếu nút1 khởi động lại, nó sẽ xuất hiện với read_only =1 và nó sẽ được phát hiện là một nô lệ. Nó không phải là lý tưởng vì nó không tái tạo nhưng nó có thể chấp nhận được. Tốt nhất, chủ cũ hoàn toàn không nên xuất hiện cho đến khi nó được xây dựng lại và xóa sổ chủ mới.
Có một tình huống khó khăn hơn nếu chúng ta phải giải quyết vấn đề phân vùng mạng. Hãy xem xét cùng một thiết lập:cấp ứng dụng, cấp proxy và cơ sở dữ liệu.
Khi mạng không thể truy cập được cái chính, ứng dụng sẽ không thể sử dụng được vì không có lần ghi nào đưa nó đến đích. Chủ nhân mới được thăng cấp, các bài viết được chuyển hướng đến nó. Điều gì sẽ xảy ra sau đó nếu sự cố mạng chấm dứt và máy chủ cũ có thể truy cập được? Nó vẫn chưa bị dừng lại, do đó nó vẫn đang sử dụng read_only =0:
Bây giờ bạn đã kết thúc trong một bộ não phân chia, khi các bài viết được chuyển hướng đến hai nút. Tình huống này khá tệ vì để hợp nhất các tập dữ liệu phân kỳ có thể mất một lúc và đây là một quá trình khá phức tạp.
Có thể làm gì để tránh vấn đề này? Không có viên đạn bạc nhưng có thể thực hiện một số hành động để giảm thiểu xác suất xảy ra hiện tượng não bị chia cắt.
Trước hết, bạn có thể thông minh hơn trong việc phát hiện trạng thái của chủ nhân. Làm thế nào để các nô lệ thấy nó? Họ có thể tái tạo từ nó không? Có thể một số nô lệ vẫn có thể kết nối với chủ nhân, có nghĩa là chủ nhân đang hoạt động hoặc ít nhất là có thể ngăn chặn nó nếu điều đó là cần thiết. Còn về lớp proxy? Tất cả các nút proxy có thấy cái chính là không khả dụng không? Nếu một số vẫn có thể kết nối, bạn có thể cố gắng sử dụng các nút đó để chuyển sang chế độ chính và dừng nó trước khi chuyển đổi dự phòng?
Phần mềm quản lý chuyển đổi dự phòng cũng có thể thông minh hơn trong việc phát hiện trạng thái của mạng. Có thể nó sử dụng RAFT hoặc một số giao thức phân cụm khác để xây dựng một cụm đại biểu nhận biết. Nếu một phần mềm quản lý chuyển đổi dự phòng có thể phát hiện bộ não phân chia, nó cũng có thể thực hiện một số hành động dựa trên điều này, chẳng hạn như đặt tất cả các nút trong phân đoạn được phân vùng thành read_only để đảm bảo rằng nút chính cũ sẽ không hiển thị dưới dạng có thể ghi khi các mạng hội tụ.
Bạn cũng có thể bao gồm các công cụ như Consul hoặc Etcd để lưu trữ trạng thái của cụm. Lớp proxy có thể được cấu hình để sử dụng dữ liệu từ Consul, không phải trạng thái của biến read_only. Sau đó, phần mềm quản lý chuyển đổi dự phòng sẽ thực hiện các thay đổi cần thiết trong Consul để tất cả proxy sẽ gửi lưu lượng truy cập đến một tổng thể mới, chính xác.
Một số gợi ý thậm chí có thể được kết hợp với nhau để làm cho việc phát hiện lỗi trở nên đáng tin cậy hơn. Nhìn chung, có thể giảm thiểu khả năng cụm sao chép bị ảnh hưởng bởi các mạng không đáng tin cậy.
Như bạn có thể thấy, bất kể chúng ta đang nói về Galera hay MySQL Replication, mạng không ổn định có thể trở thành một vấn đề nghiêm trọng. Mặt khác, nếu bạn thiết kế môi trường một cách chính xác, bạn vẫn có thể làm cho nó hoạt động. Chúng tôi hy vọng bài đăng trên blog này sẽ giúp bạn tạo ra môi trường hoạt động ổn định ngay cả khi mạng không hoạt động.
