Mẹo để chuyển từ MySQL Replication sang MySQL Galera Cluster 4.0

Trước đây chúng tôi đã viết blog về Tính năng mới trong MySQL Galera Cluster 4.0, Xử lý các giao dịch lớn với tính năng Sao chép trực tuyến và MariaDB 10.4 và đã trình bày một số hướng dẫn về cách sử dụng tính năng Nhân bản phát trực tuyến mới trong loạt bài phần 1 &phần 2.

Chuyển công nghệ cơ sở dữ liệu của bạn từ MySQL Replication sang MySQL Galera Cluster đòi hỏi bạn phải có các kỹ năng phù hợp và hiểu biết về những gì bạn đang làm để thành công. Trong blog này, chúng tôi sẽ chia sẻ một số mẹo để chuyển từ thiết lập MySQL Replication sang MySQL Galera Cluster 4.0.

Sự khác biệt giữa Bản sao MySQL và Cụm Galera

Nếu bạn chưa quen với Galera, chúng tôi khuyên bạn nên xem qua Nhóm Galera của chúng tôi cho Hướng dẫn sử dụng MySQL. Galera Cluster sử dụng một mức nhân bản hoàn toàn khác dựa trên bản sao đồng bộ, trái ngược với MySQL Replication sử dụng bản sao không đồng bộ (nhưng cũng có thể được cấu hình để đạt được bản sao bán đồng bộ).

Galera Cluster cũng hỗ trợ sao chép nhiều chủ. Nó có khả năng áp dụng song song không bị giới hạn (tức là “sao chép song song”), sao chép đa hướng và cung cấp nút tự động.

Trọng tâm chính của Galera Cluster là tính nhất quán của dữ liệu, trong khi với MySQL Replication, nó dễ xảy ra tình trạng không nhất quán dữ liệu (có thể tránh được bằng các phương pháp hay nhất và cấu hình phù hợp, chẳng hạn như thực thi chỉ đọc trên các nô lệ để tránh ghi không mong muốn trong các nô lệ).

Mặc dù các giao dịch mà Galera nhận được hoặc được áp dụng cho mọi nút hoặc không phải ở tất cả các nút, mỗi nút này xác nhận bộ ghi được sao chép trong hàng đợi applier (các cam kết giao dịch) cũng bao gồm thông tin về tất cả các khóa đã được giữ bởi cơ sở dữ liệu trong quá trình giao dịch. Bộ ghi này, sau khi không có khóa xung đột nào được xác định, sẽ được áp dụng. Cho đến thời điểm này, các giao dịch được coi là đã cam kết và tiếp tục áp dụng nó cho không gian bảng. Không giống như trong sao chép không đồng bộ, cách tiếp cận này còn được gọi là sao chép hầu như đồng bộ vì quá trình ghi và cam kết xảy ra ở chế độ đồng bộ 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à không đồng bộ trên mỗi nút.

Không giống như MySQL Replication, Galera Cluster là một nô lệ đa luồng, đa luồng thực sự, một chế độ chờ nóng thuần túy, không cần chuyển đổi dự phòng chính hoặc phân tách đọc-ghi. Tuy nhiên, di chuyển sang Galera Cluster không có nghĩa là một câu trả lời tự động cho các vấn đề của bạn. Galera Cluster chỉ hỗ trợ InnoDB, vì vậy có thể có các sửa đổi thiết kế nếu bạn đang sử dụng MyISAM hoặc các công cụ lưu trữ Bộ nhớ.

Chuyển đổi các bảng không phải InnoDB thành InnoDB

Galera Cluster cho phép bạn sử dụng MyISAM, nhưng đây không phải là những gì Galera Cluster được thiết kế cho. Galera Cluster được thiết kế để thực hiện nghiêm ngặt tính nhất quán dữ liệu trong tất cả các nút trong Cluster và điều này yêu cầu một công cụ cơ sở dữ liệu tuân thủ ACID mạnh mẽ. InnoDB là một công cụ có khả năng mạnh mẽ trong lĩnh vực này và bạn nên sử dụng InnoDB; đặc biệt là khi xử lý các giao dịch.

Nếu bạn đang sử dụng ClusterControl, bạn có thể dễ dàng xác định (các) phiên bản cơ sở dữ liệu của mình cho bất kỳ bảng MyISAM nào do Nhà tư vấn Hiệu suất cung cấp. Bạn có thể tìm thấy điều này trong tab Hiệu suất → Cố vấn. Ví dụ,

Nếu bạn yêu cầu bảng MyISAM và MEMORY, bạn vẫn có thể sử dụng nó nhưng đảm bảo dữ liệu của bạn không cần được sao chép. Bạn có thể sử dụng dữ liệu được lưu trữ ở chế độ chỉ đọc và sử dụng "BẮT ĐẦU GIAO DỊCH SN SÀNG" bất cứ khi nào thích hợp.

Thêm khóa chính vào bảng InnoDB của bạn

Vì Galera Cluster chỉ hỗ trợ InnoDB, nên điều rất quan trọng là tất cả các bảng của bạn phải có chỉ mục được phân nhóm, (còn được gọi là khóa chính hoặc khóa duy nhất). Để có được hiệu suất tốt nhất từ các truy vấn, chèn và các hoạt động cơ sở dữ liệu khác, điều rất quan trọng là bạn phải xác định mọi bảng bằng (các) khóa duy nhất vì InnoDB sử dụng chỉ mục được phân cụm để tối ưu hóa các thao tác tra cứu và DML phổ biến nhất cho mỗi bảng. . Điều này giúp tránh các truy vấn chạy dài trong cụm và có thể làm chậm hoạt động ghi / đọc trong cụm.

Trong ClusterControl, có các cố vấn có thể thông báo cho bạn về điều này. Ví dụ, trong cụm chủ / nô lệ MySQL Replication của bạn, bạn sẽ nhận được cảnh báo từ hoặc chế độ xem từ danh sách cố vấn. Ảnh chụp màn hình ví dụ bên dưới cho thấy rằng bạn không có bảng nào không có khóa chính:

Xác định Nút Chính (hoặc Người viết Hoạt động)

Galera Cluster hoàn toàn là một bản sao nhiều chủ thực sự. Tuy nhiên, điều đó không có nghĩa là bạn có thể tự do viết bất kỳ nút nào bạn muốn nhắm mục tiêu. Một điều cần xác định là, khi viết trên một nút khác và một giao dịch xung đột sẽ được phát hiện, bạn sẽ gặp phải sự cố bế tắc giống như bên dưới:

2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:

TRANSACTION 728431, ACTIVE 0 sec starting index read

mysql tables in use 1, locked 1

MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)

2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:

TRANSACTION 728426, ACTIVE 3 sec updating or deleting

mysql tables in use 1, locked 1

, undo log entries 11409

MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating

update sbtest1_success set k=k+1 where id > 1000 and id < 100000

2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X

Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0

 0: len 8; hex 73757072656d756d; asc supremum;;

Vấn đề với nhiều nút đang viết mà không xác định được nút ghi hoạt động hiện tại, bạn sẽ gặp phải những vấn đề này, đây là những vấn đề rất phổ biến mà tôi đã gặp khi sử dụng Galera Cluster khi viết trên nhiều nút tại cùng lúc. Để tránh điều này, bạn có thể sử dụng phương pháp thiết lập một cái chính:

Từ tài liệu,

Để thư giãn kiểm soát luồng, bạn có thể sử dụng các cài đặt bên dưới:

wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"

Ở trên yêu cầu khởi động lại máy chủ vì fc_master_slave không động.

Bật Chế độ gỡ lỗi cho xung đột hoặc bế tắc ghi nhật ký

Gỡ lỗi hoặc truy tìm sự cố với Cụm Galera của bạn là rất quan trọng. Các khóa trong Galera được thực hiện khác với MySQL Replication. Nó sử dụng khóa lạc quan khi xử lý các giao dịch trên toàn bộ cụm. Không giống như MySQL Replication, nó chỉ có khóa bi quan mà không biết liệu có giao dịch tương tự hoặc xung đột như vậy đang được thực hiện trong một đồng chủ trên thiết lập đa chủ hay không. Galera vẫn sử dụng khóa bi quan nhưng trên nút cục bộ vì nó được quản lý bởi InnoDB, công cụ lưu trữ được hỗ trợ. Galera sử dụng khóa lạc quan khi nó đi đến các nút khác. Điều này có nghĩa là không có kiểm tra nào được thực hiện với các nút khác trên cụm khi đạt được khóa cục bộ (khóa bi quan). Galera giả định rằng, khi giao dịch vượt qua giai đoạn cam kết trong công cụ lưu trữ và các nút khác được thông báo, mọi thứ sẽ ổn và không có xung đột nào phát sinh.

Trong thực tế, tốt nhất bạn nên bật wsrep_logs_conflicts. Điều này sẽ ghi lại các chi tiết của MDL xung đột cũng như các khóa InnoDB trong cụm. Việc bật biến này có thể được đặt động nhưng hãy lưu ý sau khi bật biến này. Nó sẽ điền đầy đủ vào tệp nhật ký lỗi của bạn và có thể làm đầy ổ đĩa của bạn khi kích thước tệp nhật ký lỗi của bạn quá lớn.

Hãy cẩn thận với các truy vấn DDL của bạn

Không giống như MySQL Replication, việc chạy câu lệnh ALTER chỉ có thể ảnh hưởng đến các kết nối đến yêu cầu truy cập hoặc tham chiếu bảng đó được nhắm mục tiêu bởi câu lệnh ALTER của bạn. Nó cũng có thể ảnh hưởng đến nô lệ nếu bảng lớn và có thể gây ra độ trễ của nô lệ. Tuy nhiên, việc ghi vào bản chính của bạn sẽ không bị chặn miễn là các truy vấn của bạn không xung đột với ALTER hiện tại. Tuy nhiên, điều này hoàn toàn không xảy ra khi chạy các câu lệnh DDL của bạn chẳng hạn như ALTER với Galera Cluster. Các câu lệnh ALTER có thể gây ra các vấn đề như Cụm Galera bị kẹt do khóa toàn cụm hoặc điều khiển luồng bắt đầu làm giãn quá trình sao chép trong khi một số nút đang khôi phục sau các lần ghi lớn.

Trong một số trường hợp, bạn có thể gặp phải thời gian chết đối với Cụm Galera nếu bảng đó quá lớn và là bảng chính và quan trọng đối với ứng dụng của bạn. Tuy nhiên, nó có thể đạt được mà không cần thời gian chết. Như Rick James đã chỉ ra trong blog của mình, bạn có thể làm theo các đề xuất bên dưới:

RSU so với TOI

Rolling Schema Upgrade =thực hiện thủ công một nút (ngoại tuyến) tại một thời điểm
Total Order Isolation =Galera đồng bộ hóa để nó được thực hiện cùng một lúc (trong chuỗi sao chép) trên tất cả các nút. RSU và TOI

Thận trọng:Vì không có cách nào để đồng bộ hóa máy khách với DDL, bạn phải đảm bảo rằng máy khách hài lòng với lược đồ cũ hoặc mới. Nếu không, bạn có thể sẽ cần gỡ bỏ toàn bộ cụm trong khi chuyển đổi đồng thời cả lược đồ và mã máy khách.

DDL "nhanh" cũng có thể được thực hiện thông qua TOI. Đây là danh sách dự kiến như vậy:

TẠO / DROP / RENAME DATABASE / BẢNG
ALTER để thay đổi DEFAULT
ALTER để thay đổi định nghĩa của ENUM hoặc SET (xem lưu ý trong sách hướng dẫn)
MỘT SỐ ĐỐI TƯỢNG ĐỐI TƯỢNG nhanh chóng.
DROP INDEX (không phải là PRIMARY KEY)
THÊM CHỈ SỐ?
ALTER khác trên bảng 'nhỏ'.
Với 5,6 và đặc biệt là 5,7 có rất nhiều trường hợp ALTER ALGORITHM =INPLACE, hãy kiểm tra xem ALTERs nào nên được thực hiện theo cách nào.

Nếu không, hãy sử dụng RSU. Thực hiện các bước sau riêng biệt cho từng nút:

SET GLOBAL wsrep_OSU_method='RSU';

Điều này cũng đưa nút ra khỏi cụm.

ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';

Đăng nhập lại, dẫn đến đồng bộ hóa lại (hy vọng là IST nhanh chứ không phải SST chậm)

Duy trì tính nhất quán của cụm của bạn

Galera Cluster không hỗ trợ các bộ lọc sao chép như binlog_do_db hoặc binlog_ignore_db vì Galera không dựa vào ghi nhật ký nhị phân. Nó dựa vào tệp bộ đệm vòng còn được gọi là GCache, nơi lưu trữ các bộ ghi được sao chép dọc theo cụm. Bạn không thể áp dụng bất kỳ hành vi hoặc trạng thái không nhất quán nào của các nút cơ sở dữ liệu đó.

Mặt khác,

Galera thực hiện nghiêm ngặt tính nhất quán dữ liệu trong cụm. Vẫn có thể có sự không nhất quán trong đó không thể tìm thấy các hàng hoặc bản ghi. Ví dụ:đặt biến wsrep_OSU_method của bạn là RSU hoặc TOI cho các câu lệnh DDL ALTER của bạn có thể mang lại hành vi không nhất quán. Kiểm tra blog bên ngoài này từ Percona thảo luận về sự không nhất quán với Galera với TOI và RSU.

Đặt wsrep_on =OFF và sau đó chạy các truy vấn DML hoặc DDL có thể nguy hiểm cho cụm của bạn. Bạn cũng phải xem lại các thủ tục, trình kích hoạt, chức năng, sự kiện hoặc dạng xem được lưu trữ của mình nếu kết quả không phụ thuộc vào trạng thái hoặc môi trường của nút. Khi một (các) nút nhất định có thể không nhất quán, nó có thể khiến toàn bộ cụm đó đi xuống. Một khi Galera phát hiện ra một hành vi không nhất quán, Galera sẽ cố gắng rời khỏi cụm và chấm dứt nút đó. Do đó, có thể tất cả các nút có thể không nhất quán khiến bạn rơi vào tình trạng tiến thoái lưỡng nan.

Nếu một nút Galera Cluster cũng gặp phải sự cố đặc biệt là trong khoảng thời gian có lưu lượng truy cập cao, tốt hơn hết bạn không nên bắt đầu ngay nút đó. Thay vào đó, hãy thực hiện một SST đầy đủ hoặc mang một phiên bản mới càng sớm càng tốt hoặc khi lưu lượng truy cập thấp. Có thể nút có thể mang lại hành vi không nhất quán có thể có dữ liệu bị hỏng.

Tách biệt các Giao dịch lớn và xác định xem có nên sử dụng tính năng sao chép truyền trực tuyến hay không

Hãy đi thẳng vào vấn đề này. Một trong những tính năng thay đổi lớn nhất đặc biệt là trên Galera Cluster 4.0 là tính năng sao chép trực tuyến. Các phiên bản trước đây của Galera Cluster 4.0, nó giới hạn các giao dịch <2GiB thường được kiểm soát bởi các biến wsrep_max_ws_rows và wsrep_max_ws_size. Kể từ Galera Cluster 4.0, bạn có thể gửi> 2GiB giao dịch nhưng bạn phải xác định mức độ lớn các phân đoạn phải được xử lý trong quá trình nhân rộng. Nó phải được đặt theo phiên và các biến duy nhất bạn cần quan tâm là wsrep_trx_fragment_unit và wsrep_trx_fragment_size. Việc tắt tính năng Sao chép truyền trực tuyến cũng đơn giản như việc thiết lập wsrep_trx_fragment_size =0 sẽ thực hiện được. Lưu ý rằng, sao chép một giao dịch lớn cũng có chi phí trên các nút phụ (các nút đang sao chép chống lại nút chủ / người viết hoạt động hiện tại) vì nhật ký sẽ được ghi vào bảng wsrep_streaming_log trong cơ sở dữ liệu MySQL.

Một điều khác cần bổ sung, vì bạn đang xử lý giao dịch lớn, điều đáng kể là giao dịch của bạn có thể mất một khoảng thời gian để hoàn thành, vì vậy việc đặt biến innodb_lock_wait_timeout cao phải được tính đến. Đặt điều này qua phiên tùy thuộc vào thời gian bạn ước tính nhưng lớn hơn thời gian bạn ước tính để kết thúc, nếu không sẽ tăng thời gian chờ.

Chúng tôi khuyên bạn nên đọc blog trước này về hoạt động sao chép trực tuyến.

Sao chép Tuyên bố GRANTs

Nếu bạn đang sử dụng GRANT và các thao tác liên quan sẽ thực hiện trên bảng MyISAM / Aria trong cơ sở dữ liệu `mysql`. Các câu lệnh GRANT sẽ được sao chép, nhưng các bảng bên dưới thì không. Vì vậy, điều này có nghĩa là, CHÈN VÀO mysql.user ... sẽ không được sao chép vì bảng là MyISAM.

Tuy nhiên, điều trên có thể không còn đúng nữa vì Percona XtraDB Cluster (PXC) 8.0 (hiện đang thử nghiệm) vì các bảng giản đồ mysql đã được chuyển đổi thành InnoDB, trong khi trong MariaDB 10.4, một số bảng vẫn còn ở định dạng Aria nhưng những cái khác ở định dạng CSV hoặc InnoDB. Bạn nên xác định phiên bản và nhà cung cấp Galera mà bạn có nhưng tốt nhất nên tránh sử dụng các câu lệnh DML tham chiếu đến lược đồ mysql. Nếu không, bạn có thể nhận được kết quả không mong muốn trừ khi bạn chắc chắn rằng đây là PXC 8.0.

Giao dịch XA, BẢNG KHÓA / MỞ KHÓA, GET_LOCK / RELEASE_LOCK không được hỗ trợ

Galera Cluster không hỗ trợ Giao dịch XA vì Giao dịch XA xử lý quá trình khôi phục và cam kết theo cách khác. Các câu lệnh LOCK / UNLOCK hoặc GET_LOCK / RELEASE_LOCK rất nguy hiểm khi được áp dụng hoặc sử dụng với Galera. Bạn có thể gặp sự cố hoặc ổ khóa không thể giết được và luôn bị khóa. Ví dụ,

---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec

mysql tables in use 2, locked 2

3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5

MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)

insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5

Giao dịch này đã được mở khóa và thậm chí đã bị giết nhưng vô ích. Chúng tôi khuyên bạn nên thiết kế lại ứng dụng khách của mình và loại bỏ các chức năng này khi di chuyển sang Galera Cluster.

Ổn định mạng là điều PHẢI CÓ !!!

Galera Cluster có thể hoạt động ngay cả với cấu trúc liên mạng WAN hoặc cấu trúc liên kết địa lý mà không gặp bất kỳ sự cố nào (hãy xem blog này về cách triển khai cấu trúc liên kết địa lý với Galera). Tuy nhiên, nếu kết nối mạng của bạn giữa mỗi nút không ổn định hoặc liên tục bị gián đoạn trong một thời gian không đáng ngờ, nó có thể có vấn đề đối với cụm. Tốt nhất bạn nên có một cụm đang chạy trong mạng riêng và mạng cục bộ nơi mỗi nút này được kết nối. Khi thiết kế một nút làm nơi phục hồi sau thảm họa, hãy lập kế hoạch tạo một cụm nếu chúng nằm trên một khu vực hoặc vị trí địa lý khác nhau. Bạn có thể bắt đầu đọc blog trước của chúng tôi, Sử dụng sao chép cụm MySQL Galera để tạo cụm phân tán theo địa lý:Phần thứ nhất vì điều này có thể giúp bạn tốt nhất để quyết định cấu trúc liên kết Cụm Galera của mình.

Một điều nữa cần bổ sung khi đầu tư phần cứng mạng của bạn, sẽ có vấn đề nếu tốc độ truyền mạng của bạn cung cấp cho bạn tốc độ thấp hơn trong quá trình xây dựng lại một phiên bản trong IST hoặc tệ hơn ở SST, đặc biệt nếu tập dữ liệu của bạn lớn . Có thể mất nhiều giờ chuyển mạng và điều đó có thể ảnh hưởng đến sự ổn định của cụm của bạn, đặc biệt nếu bạn có cụm 3 nút trong khi 2 nút không có sẵn trong đó 2 nút này là nhà tài trợ và người tham gia. Lưu ý rằng, trong giai đoạn SST, không thể sử dụng các nút DONOR / JOINER cho đến khi nó cuối cùng có thể đồng bộ hóa với cụm chính.

Trong phiên bản trước của Galera, khi nói đến lựa chọn nút của nhà tài trợ, nhà tài trợ của State Snapshot Transfer (SST) đã được chọn ngẫu nhiên. Trong Glera 4, nó đã cải tiến hơn nhiều và có khả năng chọn đúng nhà tài trợ trong nhóm, vì nó sẽ ưu tiên một nhà tài trợ có thể cung cấp Chuyển giao trạng thái tăng dần (IST) hoặc chọn một nhà tài trợ trong cùng một phân khúc. Ngoài ra, bạn có thể đặt biến wsrep_sst_donor thành đúng nhà tài trợ mà bạn muốn luôn chọn.

Sao lưu dữ liệu của bạn và thực hiện kiểm tra nghiêm ngặt trong quá trình di chuyển và trước khi sản xuất

Khi bạn đã phù hợp và quyết định thử di chuyển dữ liệu của mình sang Galera Cluster 4.0, hãy đảm bảo rằng bạn luôn chuẩn bị sẵn bản sao lưu. Nếu bạn đã thử ClusterControl, thì việc sao lưu sẽ dễ dàng hơn để thực hiện việc này.

Đảm bảo rằng bạn đang chuyển sang đúng phiên bản InnoDB và đừng quên luôn áp dụng và chạy mysql_upgrade trước khi thực hiện kiểm tra. Đảm bảo rằng tất cả các bài kiểm tra của bạn đều đạt kết quả mong muốn mà MySQL Replication có thể cung cấp cho bạn. Rất có thể, không có sự khác biệt nào giữa công cụ lưu trữ InnoDB mà bạn đang sử dụng trong Cụm sao chép MySQL so với Cụm MySQL Galera miễn là các đề xuất và mẹo đã được áp dụng và chuẩn bị trước.

Kết luận

Di chuyển sang Galera Cluster 4.0 có thể không phải là giải pháp công nghệ cơ sở dữ liệu mong muốn của bạn. Tuy nhiên, việc sử dụng Galera Cluster 4.0 sẽ không kéo bạn đi miễn là có thể chuẩn bị, thiết lập và cung cấp các yêu cầu cụ thể của nó. Galera Cluster 4.0 hiện đã trở thành một lựa chọn và lựa chọn khả thi rất mạnh mẽ, đặc biệt là trên một nền tảng và giải pháp có tính khả dụng cao. Chúng tôi cũng khuyên bạn nên đọc các blog bên ngoài này về Galera Caveats hoặc Giới hạn của Galera Cluster hoặc hướng dẫn này từ MariaDB.