Một số nút có thể gặp sự cố giao dịch, khiến chúng không thể tham gia vào cụm MGR. Làm thế nào để giải quyết vấn đề này?

1. Mô tả tình huống vấn đề

Khi một nút bị ngoại lệ ra khỏi cụm MGR do các vấn đề mạng như phân vùng mạng, nó có thể chưa kịp gửi tất cả các giao dịch đã thực hiện cho các nút khác. Hoặc do lỗi người dùng vô tình ghi dữ liệu trên nút đó. Khi nút này muốn trở lại cụm MGR, nó sẽ báo lỗi tương tự sau:

[ERROR] [MY-011526] ... Nút này có nhiều giao dịch thực hiện hơn so với cụm. Giao dịch cục bộ: xx:1-300917674 > Giao dịch cụm: xx:1-300917669
[ERROR] [MY-011522] ... Nút chứa các giao dịch không tồn tại trong cụm. Nút này sẽ ngay lập tức rời khỏi cụm.'

Đây là thông báo lỗi nghĩa là nút cục bộ có GTID giao dịch là 1-300917674, trong khi cụm MGR muốn tham gia có GTID giao dịch là 1-300917669. Nút cục bộ có 5 giao dịch vượt quá, vì vậy nó không thể tham gia đúng cách.

2. Cách khắc phục

Trong trường hợp gặp lỗi này, đừng lo lắng. Chúng ta cùng tìm hiểu cách xử lý. Có thể chia thành các bước như sau:

2.1 Tìm điểm khác biệt về giao dịch

Đầu tiên, dựa trên thông báo lỗi, hãy xác định những giao dịch khác biệt hoặc thiếu ở nút cục bộ so với cụm MGR. Trong trường hợp này, nút cục bộ có 5 giao dịch thêm. Sử dụng mysqlbinlog để xem những giao dịch này liên quan đến những đối tượng dữ liệu nào:

# -vvv,   In thông tin dư thừa hơn, giúp phân tích
# --base64-output=decode-rows, Giải mã base64
# --include-gtids=, Chỉ định phạm vi GTID cần bao gồm
$ mysqlbinlog -vvv --base64-output=decode-rows --include-gtids="0d432272-bddf-11ec-82a9-d08e7908bcb1:300917669-300917674" mgr03.000003 > diff-trxs.sql

Sau đó, bạn có thể kiểm tra file SQL đã phân tích để xác định những đối tượng dữ liệu nào bị ảnh hưởng và những gì cụ thể đã thay đổi.

Nếu MySQL đã bật tùy chọn binlog_rows_query_log_events = ON (tùy chọn mặc định là OFF, nên khuyến nghị mở), thì binlog vẫn sẽ ghi lại các câu lệnh SQL gốc, giúp phân tích dễ dàng hơn, ví dụ như sau:

SET @@SESSION.GTID_NEXT= '0d432272-bddf-11ec-82a9-d08e7908bcb1:300917669'/*!*/;
# tại 1412
#220419 16:43:37 server id 3308  end_log_pos 1494 CRC32 0xe0bed25b      Query   thread_id=93    exec_time=0     error_code=0
SET TIMESTAMP=1650357817/*!*/;
BEGIN
/*!*/;
# tại 1494
#220419 16:43:37 server id 3308  end_log_pos 1541 CRC32 0xc3635e5d      Rows_query
# insert into t1 select 4   <-- Đây là câu lệnh SQL gốc
# tại 1541
#220419 16:43:37 server id 3308  end_log_pos 1591 CRC32 0x3e190d83      Table_map: `sbtest`.`t1` ánh xạ đến số 129
# tại 1591
#220419 16:43:37 server id 3308  end_log_pos 1631 CRC32 0x890bd335      Write_rows: bảng id 129 cờ hiệu: STMT_END_F
### INSERT INTO `sbtest`.`t1`
### SET
###   @1=4 /* INT meta=0 nullable=0 is_null=0 */
# tại 1631
#220419 16:43:37 server id 3308  end_log_pos 1662 CRC32 0x53c6a05a      Xid = 267
COMMIT/*!*/;

2.2 Lựa chọn cách xử lý

Bạn đã biết rằng nút cục bộ và cụm MGR khác biệt về những giao dịch nào, giờ cần đưa ra quyết định, xem có bỏ qua các giao dịch khác biệt hay điền đầy đủ.

Nếu lựa chọn bỏ qua các giao dịch khác biệt, bạn cần phải thực hiện rollback cho các dữ liệu khác biệt ở nút cục bộ. Nếu trước đây có INSERT thì chuyển thành DELETE, nếu có DELETE thì chuyển thành INSERT, cập nhật giá trị mới thành giá trị cũ. Bạn cũng có thể sử dụng công cụ flashback thứ ba để phục hồi.

Sau khi hoàn tất việc rollback giao dịch, chạy lệnh sau trên một nút cụm MGR bất kỳ để xem thông tin GTID hiện tại:

mysql> SHOW MASTER STATUS\G
*************************** 1. hàng ***************************
             File: mgr01.000716
         Position: 6561
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set: 277e7e5e-b711-11ec-9928-d08e7908bcb1:1-46399285:47399284,
277e807f-b711-11ec-9928-d08e7908bcb1:1-31,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-26442019,
aaaaaaaa-bbbb-bbbb-aaaa-aaaaaaaaaaa1:1-1853

Sao chép thông tin GTID trên vào nút muốn tái tham gia vào cụm MGR và chạy lệnh sau:

# Đặt lại master
mysql> RESET MASTER;

# Đặt lại GTID_PURGED
mysql> SET GLOBAL GTID_PURGED = '277e7e5e-b711-11ec-9928-d08e7908bcb1:1-46399285:47399284,
277e807f-b711-11ec-9928-d08e7908bcb1:1-31,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-26442019,
aaaaaaaa-bbbb-bbbb-aaaa-aaaaaaaaaaa1:1-1853';

Thứ hai, bạn có thể bắt đầu khởi động dịch vụ MGR và tái tham gia vào cụm MGR.

Nếu lựa chọnđiền đầy đủ các giao dịch khác biệt, bạn cũng cần làm như trên để phân tích binlog và xác định giao dịch cần điền đầy đủ. Sau đó, chạy lệnh sau để áp dụng giao dịch từ nút cục bộ lên Primary node của cụm MGR, ví dụ như sau:

# Phân tích binlog từ nút cục bộ, bao gồm phần giao dịch khác biệt
# Sau đó áp dụng trực tiếp vào Primary node của cụm MGR
$ mysqlbinlog -vvv --base64-output=decode-rows --include-gtids="0d432272-bddf-11ec-82a9-d08e7908bcb1:300917669-300917674" mgr03.000003 | mysql -hmgr01 -uGreatSQL -pGreatSQL

Sau khi điền đầy đủ giao dịch, hãy kiểm tra sự khác biệt GTID giữa hai bên và làm tương tự như việc đặt lại master và sửa GTID_PURGED. Cuối cùng, bắt đầu khởi động dịch vụ MGR.

Tuy nhiên, sau khi điền đầy đủ dữ liệu, bạn có thể sử dụng clone để xây dựng lại Secondary instance và tham gia vào cụm MGR, tránh phải làm thủ công chỉnh sửa GTID và các thao tác phức tạp và dễ sai lầm. Trong quá trình clone, nếu dữ liệu lớn, hãy lưu ý thiết lập tùy chọn clone_max_data_bandwidth và clone_max_network_bandwidth để tránh chiếm toàn bộ băng thông nội bộ.

3. Kết luận

Bài viết này giới thiệu cách tìm điểm khác biệt về giao dịch khi một nút trong cụm MGR có sự xung đột và cách khắc phục vấn đề.

Nếu lo ngại về sự nhất quán dữ liệu, bạn cũng có thể sử dụng chức năng clone để xây dựng lại Secondary node, rất tiện lợi.

Ngoài ra, trong môi trường sản xuất online, tốt nhất là không nên thiết lập slave-skip-errors. Mặc dù có thể tự động bỏ qua và tiếp tục khi gặp lỗi như xung đột dữ liệu, dữ liệu không tồn tại v.v., nhưng thời gian dài, sự không nhất quán dữ liệu càng ngày càng nghiêm trọng. Đến lúc nào đó, khi buộc phải chuyển đổi chủ node, thậm chí còn không dám chuyển, đó sẽ rất tiếc.

Rất vui được đọc bài viết này!

Đề xuất bài viết:

===

GreatSQL chính thức mở rộng cho ứng dụng cấp tài chính

https://mp.weixin.qq.com/s/cI_wPKQJuXItVWpOx_yNTg

Thay đổi trong GreatSQL 8.0.25 (2021-8-18)

https://mp.weixin.qq.com/s/qcn0lmsMoLtaGO9hbpnhVg

Tổng hợp tài nguyên về MGR và GreatSQL

https://mp.weixin.qq.com/s/qXMct_pOVN5FGoLsXSD0MA

FAQ về GreatSQL MGR

https://mp.weixin.qq.com/s/J6wkUpGXw3YkyEUJXiZ9xA

Phân phối mã nguồn GreatSQL / MySQL dưới Linux

https://mp.weixin.qq.com/s/WZZOWKqSaGSy-mpD2GdNcA

Về GreatSQL

GreatSQL là nhánh MySQL được bảo trì bởi Wilard Database, tập trung cải thiện tính đáng tin cậy và hiệu suất của MGR, hỗ trợ tính năng truy vấn song song InnoDB, là phiên bản nhánh MySQL phù hợp cho ứng dụng cấp tài chính.

Gitee:

https://gitee.com/GreatSQL/GreatSQL

GitHub:

https://github.com/GreatSQL/GreatSQL

Bilibili:

https://space.bilibili.com/1363850082/video

WeChat & QQ Group:

Tìm kiếm và thêm WeChat của trợ lý cộng đồng GreatSQL, gửi thông tin "Join Group" để tham gia vào nhóm chat GreatSQL/MGR

QQ Group: 533341697

WeChat Assistant: wanlidbc