Trong một trong những blog trước, chúng tôi đã đề cập đến các tính năng mới sắp ra mắt trong MariaDB 10.4. Chúng tôi đã đề cập ở đó rằng trong phiên bản này sẽ có một bản phát hành Galera Cluster mới. Trong bài đăng blog này, chúng tôi sẽ giới thiệu cho các bạn về các tính năng của Galera Cluster 26.4.0 (hoặc Galera 4), hãy xem nhanh chúng và khám phá xem chúng sẽ ảnh hưởng như thế nào đến thiết lập của bạn khi làm việc với MariaDB Galera Cluster.
Sao chép truyền trực tuyến
Galera Cluster hoàn toàn không phải là bản thay thế cho MySQL độc lập. Cách thức hoạt động của chứng chỉ tập viết đã đưa ra một số hạn chế và các trường hợp khó khăn có thể hạn chế nghiêm trọng khả năng di chuyển vào Galera Cluster. Ba hạn chế phổ biến nhất là ...
- Các vấn đề với các giao dịch dài
- Sự cố với các giao dịch lớn
- Sự cố với các điểm nóng trong bảng
Điều tuyệt vời để thấy là Galera 4 giới thiệu tính năng Sao chép truyền trực tuyến, có thể giúp giảm những hạn chế này. Hãy xem lại trạng thái hiện tại một cách chi tiết hơn.
Giao dịch dài hạn
Trong trường hợp này, chúng ta đang nói chuyện theo chiều thời gian, điều này chắc chắn có vấn đề ở Galera. Điều chính cần hiểu là Galera sao chép các giao dịch dưới dạng các bản ghi. Các bộ ghi đó được chứng nhận trên các thành viên của cụm, đảm bảo rằng tất cả các nút đều có thể áp dụng bộ ghi đã cho. Vấn đề là, các ổ khóa được tạo trên nút cục bộ, chúng không được sao chép trên toàn bộ cụm do đó nếu giao dịch của bạn mất vài phút để hoàn thành và nếu bạn đang ghi vào nhiều hơn một nút Galera, theo thời gian thì càng có nhiều khả năng một trong các nút còn lại, một số giao dịch sẽ sửa đổi một số hàng được cập nhật trong giao dịch lâu dài của bạn. Điều này sẽ khiến chứng nhận không thành công và giao dịch đang chạy lâu dài sẽ phải lùi lại. Nói tóm lại, nếu bạn gửi các bản ghi đến nhiều hơn một nút trong cụm, giao dịch càng lâu thì càng có nhiều khả năng không đạt được chứng nhận do một số xung đột.
Điểm phát sóng
Bởi đó chúng tôi có nghĩa là các hàng, được cập nhật thường xuyên. Thông thường, đó là một số loại bộ đếm được cập nhật lặp đi lặp lại. Thủ phạm của vấn đề cũng giống như trong các giao dịch dài - các hàng chỉ bị khóa cục bộ. Một lần nữa, nếu bạn gửi ghi cho nhiều nút, có khả năng cùng một lúc, cùng một bộ đếm sẽ được sửa đổi trên nhiều nút, gây ra xung đột và làm cho chứng nhận không thành công.
Đối với cả hai vấn đề đó, có một giải pháp - bạn có thể gửi các bản ghi của mình đến chỉ một nút thay vì phân phối chúng trên toàn bộ cụm. Bạn có thể sử dụng proxy cho việc đó - ClusterControl triển khai HAProxy và ProxySQL, cả hai đều có thể được định cấu hình để việc ghi sẽ chỉ được gửi đến một nút. Nếu bạn không thể chỉ gửi ghi cho một nút, bạn phải chấp nhận rằng bạn sẽ thấy các xung đột chứng nhận và quá trình khôi phục theo thời gian. Nói chung, ứng dụng phải có khả năng xử lý các lần khôi phục từ cơ sở dữ liệu - không có cách nào khác, nhưng nó thậm chí còn quan trọng hơn khi ứng dụng hoạt động với Galera Cluster.
Tuy nhiên, gửi lưu lượng đến một nút không đủ để xử lý vấn đề thứ ba.
Giao dịch lớn
Điều quan trọng cần ghi nhớ là tập ghi chỉ được gửi để chứng nhận khi giao dịch hoàn tất. Sau đó, tập ghi được gửi đến tất cả các nút và quá trình chứng nhận diễn ra. Điều này gây ra các giới hạn về mức độ lớn của một giao dịch đơn lẻ vì Galera, khi chuẩn bị writeet, lưu trữ nó trong bộ đệm trong bộ nhớ. Các giao dịch quá lớn sẽ làm giảm hiệu suất của cụm. Do đó, hai biến đã được giới thiệu:wsrep_max_ws_rows, giới hạn số hàng trên mỗi giao dịch (mặc dù nó có thể được đặt thành 0 - không giới hạn) và quan trọng hơn:wsrep_max_ws_size, có thể được thiết lập lên đến 2 GB. Vì vậy, giao dịch lớn nhất mà bạn có thể chạy với Galera Cluster có kích thước lên đến 2GB. Ngoài ra, bạn phải lưu ý rằng việc chứng nhận và áp dụng giao dịch lớn cũng mất thời gian, tạo ra "độ trễ" - đọc sau khi ghi, nút truy cập khác với nơi bạn đã thực hiện giao dịch ban đầu, rất có thể sẽ dẫn đến dữ liệu không chính xác vì giao dịch vẫn đang được áp dụng.
Galera 4 đi kèm với Streaming Replication, có thể được sử dụng để giảm thiểu tất cả những vấn đề đó. Sự khác biệt chính là tập ghi bây giờ có thể được chia thành các phần - không còn cần phải đợi toàn bộ giao dịch kết thúc trước khi dữ liệu được sao chép. Điều này có thể khiến bạn tự hỏi - chứng nhận trông như thế nào trong trường hợp như vậy? Nói tóm lại, chứng nhận đang diễn ra - mỗi phân đoạn được chứng nhận và tất cả các hàng liên quan bị khóa trên tất cả các nút trong cụm. Đây là một sự thay đổi nghiêm trọng trong cách hoạt động của Galera - cho đến nay các khóa đã được tạo cục bộ, với các khóa sao chép trực tuyến sẽ được tạo trên tất cả các nút. Điều này hữu ích trong các trường hợp chúng ta đã thảo luận ở trên - khóa các hàng khi các phân đoạn giao dịch đi vào, giúp giảm xác suất giao dịch sẽ phải được khôi phục. Các giao dịch xung đột được thực hiện cục bộ sẽ không thể nhận được các khóa mà chúng cần và sẽ phải đợi giao dịch lặp lại hoàn tất và giải phóng các khóa hàng.
Trong trường hợp các điểm nóng, với tính năng sao chép trực tuyến, có thể nhận được các khóa trên tất cả các nút khi cập nhật hàng. Các truy vấn khác muốn cập nhật cùng một hàng sẽ phải đợi khóa được giải phóng trước khi thực hiện các thay đổi của mình.
Các giao dịch lớn sẽ được hưởng lợi từ việc nhân rộng luồng vì sẽ không cần đợi toàn bộ giao dịch kết thúc và chúng sẽ không bị giới hạn bởi quy mô giao dịch - giao dịch lớn sẽ được chia thành các đoạn. Nó cũng giúp sử dụng mạng tốt hơn - thay vì gửi 2GB dữ liệu cùng một lúc, 2GB dữ liệu giống nhau có thể được chia thành các đoạn và gửi trong một khoảng thời gian dài hơn.
Có hai tùy chọn cấu hình để sao chép trực tuyến:wsrep_trx_fragment_size, cho biết độ lớn của một phân đoạn (theo mặc định, nó được đặt thành 0, có nghĩa là tính năng sao chép trực tuyến bị vô hiệu hóa) và wsrep_trx_fragment_unit, cho biết phân đoạn thực sự là gì. Theo mặc định, nó là byte, nhưng nó cũng có thể là một ‘câu lệnh’ hoặc ‘hàng’. Các biến đó có thể (và nên) được đặt ở cấp phiên, giúp người dùng có thể quyết định truy vấn cụ thể nào nên được sao chép bằng cách sử dụng sao chép trực tuyến. Ví dụ:đặt đơn vị thành 'câu lệnh' và kích thước thành 1 cho phép sử dụng sao chép trực tuyến chỉ cho một truy vấn duy nhất, chẳng hạn như cập nhật điểm phát sóng.
Tất nhiên, có những hạn chế của việc chạy sao chép luồng, chủ yếu là do các khóa hiện được thực hiện trên tất cả các nút trong cụm. Nếu bạn đã thấy giao dịch lớn quay trở lại trong nhiều thời gian, thì bây giờ giao dịch như vậy sẽ phải quay trở lại trên tất cả các nút. Rõ ràng, phương pháp hay nhất là giảm quy mô giao dịch càng nhiều càng tốt để tránh quá trình hoàn vốn mất nhiều giờ để hoàn thành. Một nhược điểm khác là, vì lý do khôi phục sự cố, các tập ghi được tạo từ mỗi phân đoạn được lưu trữ trong bảng wsrep_schema.SR trên tất cả các nút, thực hiện bộ đệm ghi kép, làm tăng tải trên cụm. Do đó, bạn nên quyết định cẩn thận giao dịch nào nên được nhân rộng bằng cách sử dụng tính năng sao chép trực tuyến và miễn là khả thi, bạn vẫn nên tuân thủ các phương pháp hay nhất là thực hiện các giao dịch nhỏ, ngắn hoặc chia giao dịch lớn thành các lô nhỏ hơn.
Khóa dự phòng
Cuối cùng, người dùng MariaDB sẽ có thể hưởng lợi từ các khóa dự phòng cho SST. Ý tưởng đằng sau SST được thực thi bằng cách sử dụng mariabackup (cho MariaDB) là toàn bộ tập dữ liệu phải được chuyển nhanh chóng, với các bản ghi làm lại được thu thập trong nền. Sau đó, một khóa toàn cầu phải được mua lại, đảm bảo rằng không có ghi nào xảy ra, vị trí cuối cùng của nhật ký làm lại phải được thu thập và lưu trữ. Về mặt lịch sử, đối với MariaDB, phần khóa được thực hiện bằng cách sử dụng FLUSH TABLES WITH READ LOCK đã thực hiện được công việc của nó nhưng khi chịu tải nặng thì khá khó để có được. Nó cũng khá nặng nề - không chỉ các giao dịch phải đợi khóa được phát hành mà còn phải chuyển dữ liệu vào đĩa. Giờ đây, với MariaDB 10.4, sẽ có thể sử dụng KHÓA DỰ PHÒNG ít xâm phạm hơn, không yêu cầu xóa dữ liệu, chỉ các cam kết sẽ bị chặn trong suốt thời gian khóa. Điều này có nghĩa là các hoạt động SST ít xâm phạm hơn, điều này chắc chắn rất tuyệt vời khi nghe. Tất cả những người đã phải chạy Cụm Galera của họ ở chế độ khẩn cấp, trên một nút, giữ cho các ngón tay vượt qua rằng SST sẽ không ảnh hưởng đến hoạt động của cụm sẽ rất vui khi biết về cải tiến này.
Kết quả đọc từ ứng dụng
Galera 4 đã giới thiệu ba chức năng mới nhằm giúp thêm hỗ trợ cho các lần đọc nhân quả trong ứng dụng - WSREP_LAST_WRITTEN_GTID (), trả về GTID của lần ghi cuối cùng được thực hiện bởi máy khách, WSREP_LAST_SEEN_GTID (), trả về GTID của lần ghi cuối cùng được quan sát bởi máy khách và WSREP_SYNC_WAIT_UPTO_GTID (), sẽ chặn máy khách cho đến khi GTID được chuyển cho hàm sẽ được cam kết trên nút. Chắc chắn, bạn có thể thực thi đọc nhân quả trong Galera ngay cả bây giờ, nhưng bằng cách sử dụng các chức năng đó, bạn sẽ có thể thực hiện đọc sau khi ghi an toàn trong các phần của ứng dụng khi cần thiết mà không cần thực hiện thay đổi trong cấu hình Galera.
Nâng cấp lên MariaDB Galera 10.4
Nếu bạn muốn dùng thử Galera 4, nó có sẵn trong ứng cử viên phát hành mới nhất cho MariaDB 10.4. Theo tài liệu của MariaDB, tại thời điểm này không có cách nào để thực hiện nâng cấp trực tiếp 10.3 Galera lên 10.4. Bạn phải dừng toàn bộ cụm 10.3, nâng cấp lên 10.4 và sau đó khởi động lại. Đây là một trình chặn nghiêm trọng và chúng tôi hy vọng hạn chế này sẽ được loại bỏ trong một trong các phiên bản tiếp theo. Điều quan trọng nhất là có tùy chọn nâng cấp trực tiếp và cả MariaDB 10.3 và MariaDB 10.4 sẽ phải cùng tồn tại trong cùng một Cụm Galera. Một tùy chọn khác, cũng có thể phù hợp, là thiết lập sao chép không đồng bộ giữa Galera Cluster cũ và mới.
Chúng tôi thực sự hy vọng bạn thích bài đánh giá ngắn này về các tính năng của MariaDB 10.4 Galera Cluster, chúng tôi rất mong được thấy bản nhân rộng phát trực tuyến trong môi trường sản xuất trực tiếp thực tế. Chúng tôi cũng hy vọng những thay đổi đó sẽ giúp tăng mức độ chấp nhận Galera hơn nữa. Rốt cuộc, sao chép trực tuyến giải quyết được nhiều vấn đề có thể ngăn mọi người di chuyển vào Galera.
