Chào mừng bạn đến với bài viết kỹ thuật từ cộng đồng GreatSQL. Nếu bạn có bất kỳ câu hỏi nào hoặc muốn tìm hiểu thêm về chủ đề này, hãy để lại bình luận bên dưới, chúng tôi sẽ phản hồi khi có thể.

Bài viết này là nội dung độc quyền của cộng đồng GreatSQL, vui lòng không sao chép hoặc phân phối mà không được sự cho phép. Nếu muốn sử dụng, xin vui lòng liên hệ quản trị viên và ghi rõ nguồn.

Kết quả thực nghiệm cho thấy hiệu suất của MGR trên MySQL 8.0.26 như thế nào? Hãy cùng xem qua các số liệu đo đạc cụ thể.

Ngoài ra, phiên bản MySQL 8.0.26 còn chứa một lỗi nghiêm trọng cần được lưu ý.

Đã hơn hai tháng kể từ khi MySQL 8.0.26 được phát hành, nhưng chưa có thời gian đánh giá kỹ lưỡng. Trong bản ghi nhật ký phát hành (release notes), có ghi nhận một số lỗi liên quan đến MGR đã được sửa chữa. Dưới đây là kết quả thử nghiệm đơn giản nhất.

Bài viết sẽ giới thiệu thêm một lỗi nghiêm trọng trong MySQL 8.0.26 ở phần cuối.

Phương pháp kiểm tra sử dụng kịch bản mix-load từ sysbench (cảm ơn thầy Lầu Phương Tân đã chia sẻ):

require("oltp_common")

local runtype = 0;

function prepare_statements()
   -- Sử dụng 1 truy vấn mỗi sự kiện thay vì mặc định là 10 như các kịch bản OLTP khác
   sysbench.opt.point_selects=1

   runtype = (10 * sysbench.tid + 10) / sysbench.opt.threads

   if runtype <= 6 then
     prepare_point_selects()
   else
     prepare_non_index_updates()
   end
end

function event(thread_id)
   if runtype <= 6 then
     execute_point_selects()
   else
     execute_non_index_updates()
   end
end

Các chỉ số quan trọng trong quá trình kiểm tra:

• --tables=10
• --table_size=100000
• --threads=16
• --report-interval=1

Một số cấu hình chính liên quan đến InnoDB và MGR:

innodb_buffer_pool_size = 256M

slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 64
binlog_transaction_dependency_tracking = WRITESET
slave_preserve_commit_order = 1
slave_checkpoint_period = 2

group_replication_flow_control_mode = "DISABLED"

Lưu ý: Máy kiểm tra có cấu hình phổ thông nên dữ liệu và tải công việc không cao.

Tiếp theo, so sánh các giá trị khác nhau của group_replication_consistency giữa GreatSQL 8.0.25-15 và MySQL 8.0.26, tập trung vào chỉ số TPS và độ trễ (latency).

1. group_replication_consistency=EVENTUAL

Dựa trên các kết quả thử nghiệm, có thể thấy:

1. TPS trên MySQL 8.0.26 vẫn rất biến động.
2. Độ trễ (latency) cũng dao động lớn.

Ngoài ra, từ trải nghiệm thực tế, một số vấn đề từng tồn tại trong các phiên bản trước đã được cải thiện nhẹ:

1. Sau khi tiến trình SECONDARY bị tắt, việc khôi phục lại nhóm diễn ra nhanh hơn (khoảng 20-30 giây), thay vì mất vài phút trước đó.
2. Thời gian phản ứng khi tắt một node SECONDARY giảm xuống còn khoảng 10-20 giây (trước đây là 20-30 giây).
3. Việc loại bỏ node SECONDARY khỏi nhóm vẫn mất khoảng 20 giây, chưa được cải thiện.
4. Khi không gian ổ đĩa đầy, giao dịch MGR bị chặn. Trong MySQL 8.0.26, điều này vẫn xảy ra, nếu xử lý chậm có thể dẫn đến tiến trình mysqld bị OOM KILL do tích tụ giao dịch chờ xác nhận (BUG#104979). Vấn đề này sẽ được phân tích kỹ hơn trong bài viết sau.

Giới thiệu lỗi nghiêm trọng trong MySQL 8.0.26 (BUG#104980)

Cách tái tạo lỗi:

1. Đặt group_replication_consistency thành BEFORE_AND_AFTER hoặc AFTER (chỉ hai chế độ này gặp lỗi).
2. Khởi động sysbench kiểm tra liên tục trên nhóm MGR.
3. Trong quá trình kiểm tra, ngẫu nhiên tắt một node SECONDARY.
4. Qua nhiều lần thử, có khả năng cao sẽ gặp lỗi không thể thêm lại node SECONDARY vào nhóm. Thông báo lỗi tương tự như sau:

[ERROR] [MY-013309] [Repl] Plugin group_replication reported: 'Transaction '2:39976870' does not exist on Group Replication consistency manager while receiving remote transaction prepare.'
[ERROR] [MY-011452] [Repl] Plugin group_replication reported: 'Fatal error during execution on the Applier process of Group Replication. The server will now leave the group.'
[ERROR] [MY-011712] [Repl] Plugin group_replication reported: 'The server was automatically set into read only mode after an error was detected.'

Cùng kịch bản kiểm tra, GreatSQL 8.0.25 không gặp lỗi này – vẫn rất ổn định.

May mắn rằng, các chế độ AFTER và BEFORE_AND_AFTER hiếm khi được sử dụng, nên số người gặp lỗi này sẽ ít.

Phát hiện thêm một lỗi nhỏ (BUG#104974): Khi thiết lập trực tiếp giá trị group_replication_consistency, nếu chọn BEFORE, bắt buộc phải đặt trong dấu nháy đơn, nếu không sẽ báo lỗi cú pháp. Các chế độ khác thì không có vấn đề:

mysql>set global group_replication_consistency=EVENTUAL;
Query OK, 0 rows affected (0.00 sec)

mysql>set global group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER;
Query OK, 0 rows affected (0.00 sec)

mysql>set global group_replication_consistency=BEFORE;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'BEFORE' at line 1

mysql>set global group_replication_consistency='BEFORE';
Query OK, 0 rows affected (0.00 sec)

mysql>set global group_replication_consistency=AFTER;
Query OK, 0 rows affected (0.00 sec)

mysql>set global group_replication_consistency= BEFORE_AND_AFTER;
Query OK, 0 rows affected (0.00 sec)

Hãy tận hưởng GreatSQL nhé! 😃

Bài viết liên quan

• Câu hỏi thường gặp về GreatSQL MGR
• Khi toàn bộ nhóm MGR bị hỏng, làm thế nào để chọn chủ động mà không cần can thiệp thủ công?
• MySQL High Availability Architecture Evolution and Practice
• Phân tích nguyên nhân gây chậm cho một câu lệnh SQL
• Những trường hợp nào có thể khiến MGR không khởi động được?
• Tại sao không khuyến nghị sử dụng chế độ CONSISTENCY AFTERS trong MGR

Giới thiệu về GreatSQL

GreatSQL là một nhánh của MySQL do万里数据库 duy trì, tập trung nâng cao độ tin cậy và hiệu suất của MGR, hỗ trợ tính năng truy vấn song song InnoDB, phù hợp cho các ứng dụng yêu cầu cao về độ ổn định như tài chính.

• Gitee
• GitHub
• Bilibili
• Gruppen WeChat & QQ: Tìm kiếm "GreatSQL社区助手" để thêm bạn bè, gửi tin nhắn "加群" để tham gia nhóm trò chuyện WeChat về GreatSQL/MGR
  QQ Group: 533341697
  WeChat Assistant: wanlidbc

Bài viết được đăng tải bởi nền tảng OpenWrite - Bài viết đa nền tảng