HA cho MySQL và MariaDB - So sánh bản sao Master-Master với Galera Cluster

Bản sao Galera tương đối mới nếu so với bản sao MySQL, vốn được hỗ trợ từ MySQL v3.23. Mặc dù bản sao MySQL được thiết kế để sao chép một chiều master-slave, nó có thể được cấu hình như một thiết lập master-master hoạt động với sao chép hai chiều. Mặc dù nó dễ dàng thiết lập và một số trường hợp sử dụng có thể được hưởng lợi từ "hack" này, nhưng có một số lưu ý. Mặt khác, cụm Galera là một loại công nghệ khác để học và quản lý. Nó có đáng không?

Trong bài đăng blog này, chúng tôi sẽ so sánh bản sao tổng thể chính với cụm Galera.

Khái niệm sao chép

Trước khi chúng ta bắt đầu so sánh, hãy giải thích các khái niệm cơ bản đằng sau hai cơ chế sao chép này.

Nói chung, bất kỳ sửa đổi nào đối với cơ sở dữ liệu MySQL đều tạo ra một sự kiện ở định dạng nhị phân. Sự kiện này được chuyển đến các nút khác tùy thuộc vào phương pháp sao chép đã chọn - sao chép MySQL (bản địa) hoặc sao chép Galera (được vá bằng API wsrep).

Bản sao MySQL

Các sơ đồ sau minh họa luồng dữ liệu của một giao dịch thành công từ nút này sang nút khác khi sử dụng bản sao MySQL:

Sự kiện nhị phân được ghi vào nhật ký nhị phân của chủ. (Các) nô lệ qua slave_IO_thread sẽ kéo các sự kiện nhị phân từ nhật ký nhị phân của bậc thầy và sao chép chúng vào nhật ký chuyển tiếp của nó. slave_SQL_thread sau đó sẽ áp dụng sự kiện từ nhật ký chuyển tiếp không đồng bộ. Do tính chất không đồng bộ của sao chép, máy chủ phụ không được đảm bảo có dữ liệu khi máy chủ thực hiện thay đổi.

Lý tưởng nhất, bản sao MySQL sẽ có máy chủ được cấu hình như một máy chủ chỉ đọc bằng cách đặt read_only =ON hoặc super_read_only =ON. Đây là biện pháp phòng ngừa để bảo vệ nô lệ khỏi việc ghi ngẫu nhiên có thể dẫn đến sự không nhất quán hoặc thất bại của dữ liệu trong quá trình chuyển đổi dự phòng chính (ví dụ:các giao dịch sai sót). Tuy nhiên, trong thiết lập sao chép chủ động-chủ động, chỉ đọc phải được tắt trên bản chính khác để cho phép ghi được xử lý đồng thời. Bản chính chính phải được định cấu hình để sao chép từ bản chính phụ bằng cách sử dụng câu lệnh CHANGE MASTER để cho phép sao chép vòng tròn.

Bản sao Galera

Các sơ đồ sau minh họa luồng sao chép dữ liệu của một giao dịch thành công từ nút này sang nút khác cho Galera Cluster:

Sự kiện được gói gọn trong một bộ ghi và được phát từ nút khởi tạo đến các nút khác trong cụm bằng cách sử dụng bản sao Galera. Bộ ghi phải được chứng nhận trên mọi nút Galera và nếu nó vượt qua, các luồng ứng dụng sẽ áp dụng bộ ghi một cách không đồng bộ. Điều này có nghĩa là máy chủ nô lệ cuối cùng sẽ trở nên nhất quán, sau khi có sự đồng ý của tất cả các nút tham gia trong thứ tự tổng thể toàn cầu. Nó đồng bộ về mặt logic, nhưng việc ghi và cam kết thực tế vào không gian bảng diễn ra độc lập và do đó không đồng bộ trên mỗi nút với một đảm bảo cho sự thay đổi được truyền trên tất cả các nút.

Tránh xung đột khóa chính

Để triển khai sao chép MySQL trong thiết lập tổng thể, người ta phải điều chỉnh giá trị tăng tự động để tránh xung đột khóa chính cho INSERT giữa hai hoặc nhiều bản sao chính. Điều này cho phép giá trị khóa chính trên bản cái xen kẽ lẫn nhau và ngăn việc sử dụng cùng một số tăng tự động hai lần trên một trong hai nút. Hành vi này phải được cấu hình theo cách thủ công, tùy thuộc vào số lượng bản chính trong thiết lập sao chép. Giá trị của auto_increment_increment bằng với số lượng bản sao nhân bản và auto_increment_offset phải là duy nhất giữa chúng. Ví dụ:các dòng sau phải tồn tại bên trong my.cnf tương ứng:

Master1:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

Master2:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

Tương tự như vậy, Galera Cluster sử dụng thủ thuật tương tự này để tránh xung đột khóa chính bằng cách kiểm soát giá trị gia tăng tự động và tự động bù trừ với wsrep_auto_increment_control Biến đổi. Nếu được đặt thành 1 (mặc định), sẽ tự động điều chỉnh auto_increment_increment và auto_increment_offset các biến tùy theo kích thước của cụm và khi kích thước cụm thay đổi. Điều này tránh xung đột sao chép do auto_increment. Trong môi trường chủ-tớ, biến này có thể được đặt thành TẮT.

Hệ quả của cấu hình này là giá trị tăng tự động sẽ không theo thứ tự tuần tự, như được hiển thị trong bảng sau của Cụm Galera ba nút:

Nếu một ứng dụng thực hiện các thao tác chèn trên các nút sau theo thứ tự sau:

• Node1, Node3, Node2, Node3, Node3, Node1, Node3 ..

Sau đó, giá trị khóa chính sẽ được lưu trữ trong bảng sẽ là:

• 1, 6, 8, 9, 12, 13, 15 ..

Nói một cách đơn giản, khi sử dụng bản sao tổng thể (bản sao MySQL hoặc Galera), ứng dụng của bạn phải có khả năng chịu đựng các giá trị tăng tự động không tuần tự trong tập dữ liệu của nó.

Đối với người dùng ClusterControl, hãy lưu ý rằng nó hỗ trợ triển khai sao chép bản chính-master MySQL với giới hạn hai bản chính cho mỗi cụm sao chép, chỉ dành cho thiết lập chủ động-thụ động. Do đó, ClusterControl không cố ý định cấu hình chính với auto_increment_increment và auto_increment_offset biến.

Tính nhất quán của dữ liệu

Galera Cluster đi kèm với cơ chế kiểm soát luồng của nó, trong đó mỗi nút trong cụm phải theo kịp khi sao chép, hoặc nếu không, tất cả các nút khác sẽ phải chạy chậm lại để cho phép nút chậm nhất bắt kịp. Điều này về cơ bản giảm thiểu xác suất bị trễ nô lệ, mặc dù nó vẫn có thể xảy ra nhưng không đáng kể như trong MySQL replication. Theo mặc định, Galera cho phép các nút có ít nhất 16 giao dịch chậm hơn khi áp dụng thông qua biến gcs.fc_limit . Nếu bạn muốn thực hiện các lần đọc quan trọng (một CHỌN phải trả lại hầu hết thông tin cập nhật), bạn có thể muốn sử dụng biến phiên, wsrep_sync_wait .

Mặt khác, Galera Cluster đi kèm với một biện pháp bảo vệ chống lại sự mâu thuẫn dữ liệu, theo đó một nút sẽ bị đuổi khỏi cụm nếu nó không áp dụng bất kỳ tập ghi nào vì bất kỳ lý do gì. Ví dụ:khi một nút Galera không thể áp dụng bộ ghi do lỗi nội bộ của công cụ lưu trữ bên dưới (MySQL / MariaDB), nút sẽ tự rút ra khỏi cụm với lỗi sau:

150305 16:13:14 [ERROR] WSREP: Failed to apply trx 1 4 times
150305 16:13:14 [ERROR] WSREP: Node consistency compromized, aborting..

Để khắc phục tính nhất quán của dữ liệu, nút vi phạm phải được đồng bộ hóa lại trước khi nó được phép tham gia vào cụm. Điều này có thể được thực hiện theo cách thủ công hoặc bằng cách xóa sạch thư mục dữ liệu để kích hoạt chuyển trạng thái ảnh chụp nhanh (đồng bộ hóa đầy đủ từ một nhà tài trợ).

MySQL master-master replication không thực thi bảo vệ tính nhất quán dữ liệu và một nô lệ được phép phân kỳ, ví dụ:sao chép một tập hợp con dữ liệu hoặc bị tụt hậu, điều này làm cho nô lệ không nhất quán với chủ. Nó được thiết kế để sao chép dữ liệu trong một luồng - từ chủ xuống đến nô lệ. Kiểm tra tính nhất quán của dữ liệu phải được thực hiện theo cách thủ công hoặc thông qua các công cụ bên ngoài như Percona Toolkit pt-table-checksum hoặc mysql-replication-check.

Giải quyết xung đột

Nói chung, sao chép master-master (hoặc multi-master, hoặc hai hướng) cho phép nhiều thành viên trong cụm xử lý ghi. Với nhân bản MySQL, trong trường hợp xung đột sao chép, luồng SQL của nô lệ chỉ cần dừng áp dụng truy vấn tiếp theo cho đến khi xung đột được giải quyết, bằng cách bỏ qua sự kiện nhân bản theo cách thủ công, sửa các hàng vi phạm hoặc đồng bộ hóa lại nô lệ. Nói một cách đơn giản, không có hỗ trợ giải quyết xung đột tự động cho bản sao MySQL.

Galera Cluster cung cấp một giải pháp thay thế tốt hơn bằng cách thử lại giao dịch vi phạm trong quá trình nhân rộng. Bằng cách sử dụng wsrep_retry_autocommit biến, người ta có thể hướng dẫn Galera tự động thử lại một giao dịch không thành công do xung đột toàn cụm, trước khi trả lại lỗi cho máy khách. Nếu được đặt thành 0, sẽ không có lần thử lại nào được thử, trong khi giá trị từ 1 (giá trị mặc định) trở lên chỉ định số lần thử lại. Điều này có thể hữu ích để hỗ trợ các ứng dụng sử dụng tự động gửi để tránh bế tắc.

Đồng thuận nút và chuyển đổi dự phòng

Galera sử dụng Hệ thống liên lạc nhóm (GCS) để kiểm tra sự đồng thuận của nút và tính khả dụng giữa các thành viên trong cụm. Nếu một nút không lành mạnh, nút đó sẽ tự động bị loại bỏ khỏi cụm sau gmcast.peer_timeout giá trị, mặc định là 3 giây. Một nút Galera khỏe mạnh ở trạng thái "Đã đồng bộ hóa" được coi là một nút đáng tin cậy để phục vụ việc đọc và ghi, trong khi những nút khác thì không. Thiết kế này giúp đơn giản hóa đáng kể các quy trình kiểm tra sức khỏe từ các tầng trên (bộ cân bằng tải hoặc ứng dụng).

Trong bản sao MySQL, một chủ không quan tâm đến (các) nô lệ của nó, trong khi một nô lệ chỉ có sự đồng thuận với chủ duy nhất của nó thông qua slave_IO_thread xử lý khi sao chép các sự kiện nhị phân từ nhật ký nhị phân của bậc thầy. Nếu một trang cái gặp sự cố, điều này sẽ phá vỡ bản sao và nỗ lực thiết lập lại liên kết sẽ được thực hiện mỗi slave_net_timeout (mặc định là 60 giây). Từ quan điểm của ứng dụng hoặc bộ cân bằng tải, các thủ tục kiểm tra tình trạng của nô lệ sao chép ít nhất phải liên quan đến việc kiểm tra trạng thái sau:

• Seconds_Behind_Master
• Slave_IO_Running
• Slave_SQL_Running
• biến read_only
• biến super_read_only (MySQL 5.7.8 trở lên)

Về mặt chuyển đổi dự phòng, nói chung, bản sao tổng thể và các nút Galera là ngang nhau. Chúng giữ cùng một tập dữ liệu (mặc dù bạn có thể sao chép một tập con dữ liệu trong MySQL replication, nhưng điều đó không phổ biến đối với master-master) và chia sẻ vai trò giống như master, có khả năng xử lý đọc và ghi đồng thời. Do đó, thực tế không có chuyển đổi dự phòng từ quan điểm cơ sở dữ liệu do trạng thái cân bằng này. Chỉ từ phía ứng dụng yêu cầu chuyển đổi dự phòng mới có thể bỏ qua các nút chưa hoạt động. Hãy nhớ rằng vì bản sao MySQL là không đồng bộ, có thể không phải tất cả các thay đổi được thực hiện trên bản chính sẽ được truyền sang bản chính khác.

Cấp phép nút

Quá trình đưa một nút vào đồng bộ với cụm trước khi bắt đầu sao chép, được gọi là cấp phép. Trong sao chép MySQL, việc cung cấp một nút mới là một quá trình thủ công. Người ta phải tạo một bản sao lưu của cái chính và khôi phục nó vào nút mới trước khi thiết lập liên kết sao chép. Đối với một nút sao chép hiện có, nếu nhật ký nhị phân của cái chính đã được xoay vòng (dựa trên expire_logs_days , mặc định là 0 có nghĩa là không có loại bỏ tự động), bạn có thể phải cung cấp lại nút bằng cách sử dụng quy trình này. Ngoài ra còn có các công cụ bên ngoài như Percona Toolkit pt-table-sync và ClusterControl để giúp bạn làm điều này. ClusterControl hỗ trợ đồng bộ lại nô lệ chỉ với hai cú nhấp chuột. Bạn có các tùy chọn để đồng bộ hóa lại bằng cách sao lưu từ bản chính đang hoạt động hoặc bản sao lưu hiện có.

Trong Galera, có hai cách để thực hiện việc này - chuyển trạng thái gia tăng (IST) hoặc chuyển ảnh chụp nhanh trạng thái (SST). Quy trình IST là phương pháp được ưa thích trong đó chỉ các giao dịch bị thiếu mới chuyển từ bộ nhớ cache của nhà tài trợ. Quy trình SST tương tự như lấy một bản sao lưu đầy đủ từ nhà tài trợ, nó thường khá tốn nhiều tài nguyên. Galera sẽ tự động xác định quy trình đồng bộ hóa nào cần kích hoạt dựa trên trạng thái của trình kết hợp. Trong hầu hết các trường hợp, nếu một nút không tham gia được vào một cụm, chỉ cần xóa sạch dữ liệu MySQL của nút có vấn đề và khởi động dịch vụ MySQL. Quy trình cấp phép Galera đơn giản hơn nhiều, nó rất tiện dụng khi mở rộng cụm của bạn hoặc giới thiệu lại một nút có vấn đề vào cụm.

Khớp nối lỏng lẻo so với Khớp nối chặt chẽ

Bản sao MySQL hoạt động rất tốt ngay cả trên các kết nối chậm hơn và với các kết nối không liên tục. Nó cũng có thể được sử dụng trên các phần cứng, môi trường và hệ điều hành khác nhau. Hầu hết các công cụ lưu trữ đều hỗ trợ nó, bao gồm MyISAM, Aria, MEMORY và ARCHIVE. Thiết lập kết hợp lỏng lẻo này cho phép sao chép tổng thể MySQL hoạt động tốt trong môi trường hỗn hợp với ít hạn chế hơn.

Các nút Galera được liên kết chặt chẽ với nhau, trong đó hiệu suất sao chép nhanh như nút chậm nhất. Galera sử dụng cơ chế kiểm soát luồng để kiểm soát luồng sao chép giữa các thành viên và loại bỏ bất kỳ độ trễ nào của nô lệ. Quá trình sao chép có thể nhanh hoặc chậm trên mọi nút và được điều chỉnh tự động bởi Galera. Do đó, bạn nên sử dụng các thông số kỹ thuật phần cứng thống nhất cho tất cả các nút Galera, đặc biệt đối với CPU, RAM, hệ thống con đĩa, thẻ giao diện mạng và độ trễ mạng giữa các nút trong cụm.

Kết luận

Tóm lại, Galera Cluster vượt trội hơn nếu so sánh với MySQL master-master replication do hỗ trợ sao chép đồng bộ với tính nhất quán mạnh mẽ, cộng với các tính năng nâng cao hơn như kiểm soát thành viên tự động, cung cấp nút tự động và nô lệ đa luồng. Cuối cùng, điều này phụ thuộc vào cách ứng dụng tương tác với máy chủ cơ sở dữ liệu. Một số ứng dụng cũ được xây dựng cho một máy chủ cơ sở dữ liệu độc lập có thể không hoạt động tốt trên thiết lập theo nhóm.

Để đơn giản hóa các điểm của chúng tôi ở trên, các lý do sau đây là lý do giải thích khi nào sử dụng bản sao tổng thể chính của MySQL:

• Những thứ không được Galera hỗ trợ:
  • Sao chép cho các bảng không phải InnoDB / XtraDB như MyISAM, Aria, MEMORY hoặc ARCHIVE.
  • Giao dịch XA.
  • Sao chép dựa trên câu lệnh giữa các bản chính (ví dụ:khi băng thông rất đắt).
  • Dựa vào cách khóa rõ ràng như câu lệnh LOCK TABLES.
  • Nhật ký truy vấn chung và nhật ký truy vấn chậm phải được chuyển hướng đến một bảng, thay vì một tệp.
• Thiết lập kết hợp lỏng lẻo trong đó thông số kỹ thuật phần cứng, phiên bản phần mềm và tốc độ kết nối khác nhau đáng kể trên mọi thiết bị chính.
• Khi bạn đã có một chuỗi sao chép MySQL và bạn muốn thêm một bản chính đang hoạt động / sao lưu khác để dự phòng nhằm tăng tốc thời gian chuyển đổi dự phòng và khôi phục trong trường hợp một trong các bản chính không khả dụng.
• Nếu ứng dụng của bạn không thể sửa đổi để giải quyết các hạn chế của Galera Cluster và việc có bộ cân bằng tải nhận biết MySQL như ProxySQL hoặc MaxScale không phải là một tùy chọn.

Các lý do nên chọn Galera Cluster thay vì sao chép tổng thể-master MySQL:

• Khả năng ghi một cách an toàn lên nhiều trang cái.
• Tính nhất quán của dữ liệu được quản lý tự động (và được đảm bảo) trên các cơ sở dữ liệu.
• Các nút cơ sở dữ liệu mới dễ dàng được giới thiệu và đồng bộ hóa.
• Các lỗi hoặc sự không nhất quán tự động được phát hiện.
• Nhìn chung, các tính năng sẵn có cao hơn và mạnh mẽ hơn, nâng cao hơn.