Nhân rộng trong MySQL đã có từ lâu và đang được cải thiện đều đặn trong những năm qua. Nó giống như sự tiến hóa hơn là cuộc cách mạng. Điều này là hoàn toàn dễ hiểu, vì sao chép là một tính năng quan trọng mà nhiều người phụ thuộc vào - nó phải hoạt động.
Trong các phiên bản MySQL gần đây nhất, chúng tôi đã thấy những cải thiện về hiệu suất sao chép thông qua hỗ trợ áp dụng các giao dịch song song. Trong MySQL 5.6, quá trình song song hóa được thực hiện ở cấp độ lược đồ - tất cả các giao dịch đã được thực hiện trong các lược đồ riêng biệt có thể được thực hiện cùng một lúc. Đây là một cải tiến tuyệt vời đối với những khối lượng công việc có nhiều lược đồ trên một máy chủ duy nhất và tải được phân bổ ít nhiều đồng đều trên các lược đồ.
Trong MySQL 5.7, một phương pháp song song khác đã được thêm vào, được gọi là “đồng hồ logic”. Nó cho phép nhận được một số mức đồng thời trên một nô lệ, ngay cả khi tất cả dữ liệu của bạn đã được lưu trữ trong một lược đồ duy nhất. Tóm lại, nó dựa trên thực tế là một số giao dịch sẽ cam kết với nhau do độ trễ do phần cứng thêm vào. Bạn thậm chí có thể thêm độ trễ đó theo cách thủ công, để đạt được khả năng song song tốt hơn trên các nô lệ bằng cách sử dụng binlog_group_commit_sync_delay.
Giải pháp này thực sự tốt nhưng không phải không có nhược điểm. Mọi sự chậm trễ trong việc thực hiện một giao dịch cuối cùng có thể ảnh hưởng đến các phần giao diện người dùng của ứng dụng. Chắc chắn, bạn có thể đặt độ trễ trong phạm vi vài mili giây, nhưng ngay cả sau đó, độ trễ bổ sung sẽ làm chậm ứng dụng.
Cải tiến hiệu suất sao chép trong MySQL 8.0
MySQL 8.0, tính đến thời điểm hiện tại (tháng 8 năm 2017) vẫn ở trạng thái beta, mang lại một số cải tiến tốt cho việc nhân rộng. Ban đầu, nó được phát triển cho Group Replication (GR), nhưng vì GR sử dụng tính năng nhân rộng thường xuyên, nên việc nhân rộng MySQL “bình thường” được hưởng lợi từ nó. Cải tiến mà chúng tôi đã đề cập là thông tin theo dõi phụ thuộc được lưu trữ trong nhật ký nhị phân. Điều xảy ra là MySQL 8.0 hiện có một cách để lưu trữ thông tin về những hàng nào bị ảnh hưởng bởi một giao dịch nhất định (được gọi là tập viết) và nó so sánh các tập ghi từ các giao dịch khác nhau. Điều này giúp bạn có thể xác định những giao dịch không hoạt động trên cùng một tập hợp con của các hàng và do đó, những giao dịch này có thể được áp dụng song song. Điều này có thể cho phép tăng mức độ song song hóa lên nhiều lần so với việc triển khai từ MySQL 5.7. Điều bạn cần ghi nhớ là cuối cùng, một nô lệ sẽ thấy một chế độ xem khác của dữ liệu, một chế độ xem chưa bao giờ xuất hiện trên chủ. Điều này là do các giao dịch có thể được áp dụng theo một thứ tự khác với trên giao dịch chính. Đây không phải là một vấn đề mặc dù. Việc triển khai bản sao đa luồng hiện tại trong MySQL 5.7 cũng có thể gây ra sự cố này trừ khi bạn bật chế độ nô lệ-bảo tồn-cam kết một cách rõ ràng.
Để kiểm soát hành vi mới này, một biến binlog_transaction_dependency_tracking đã được giới thiệu. Nó có thể nhận ba giá trị:
- COMMIT_ORDER:đây là cái mặc định, nó sử dụng cơ chế mặc định có sẵn trong MySQL 5.7.
- WRITESET:Nó cho phép song song tốt hơn và thiết bị chính bắt đầu lưu trữ dữ liệu tập ghi trong nhật ký nhị phân.
- WRITESET_SESSION:Điều này đảm bảo rằng các giao dịch sẽ được thực hiện trên máy chủ theo thứ tự và vấn đề với máy phụ có trạng thái cơ sở dữ liệu chưa từng thấy trên máy chủ sẽ được loại bỏ. Nó làm giảm khả năng song song hóa nhưng vẫn có thể cung cấp thông lượng tốt hơn so với cài đặt mặc định.
Điểm chuẩn
Vào tháng 7, trên mysqlhighavailable.com, Vitor Oliveira đã viết một bài đăng trong đó anh cố gắng đo lường hiệu suất của các chế độ mới. Anh ấy đã sử dụng tình huống tốt nhất - không có độ bền, để thể hiện sự khác biệt giữa chế độ cũ và mới. Chúng tôi quyết định sử dụng cùng một cách tiếp cận, lần này là trong một thiết lập thế giới thực hơn:nhật ký nhị phân được bật với log_slave_updates. Cài đặt độ bền được để mặc định (vì vậy, sync_binlog =1 - đó là mặc định mới trong MySQL 8.0, bộ đệm ghi kép được bật, bật tổng kiểm tra InnoDB, v.v.) Chỉ có ngoại lệ về độ bền là innodb_flush_log_at_trx_commit được đặt thành 2.
Chúng tôi đã sử dụng các phiên bản m4.2xl, 32G, 8 lõi (vì vậy slave_parallel_workers được đặt thành 8). Chúng tôi cũng đã sử dụng tập lệnh sysbench, oltp_read_write.lua. 16 triệu hàng trong 32 bảng được lưu trữ trên khối lượng 1000GB gp2 (đó là 3000 IOPS). Chúng tôi đã kiểm tra hiệu suất của tất cả các chế độ cho 1, 2, 4, 8, 16 và 32 kết nối sysbench đồng thời. Quy trình như sau:dừng nô lệ, thực hiện 100 nghìn giao dịch, bắt đầu nô lệ và tính toán thời gian để xóa lỗi nô lệ.
Trước hết, chúng tôi không thực sự biết điều gì đã xảy ra khi sysbench được thực thi chỉ bằng 1 luồng. Mỗi bài kiểm tra được thực hiện năm lần sau khi chạy khởi động. Cấu hình cụ thể này đã được thử nghiệm hai lần - kết quả ổn định:khối lượng công việc đơn luồng là nhanh nhất. Chúng tôi sẽ xem xét kỹ hơn để hiểu điều gì đã xảy ra.
Ngoài ra, phần còn lại của kết quả phù hợp với những gì chúng tôi mong đợi. COMMIT_ORDER là chậm nhất, đặc biệt là đối với lưu lượng truy cập thấp, 2-8 luồng. WRITESET_SESSION thường hoạt động tốt hơn COMMIT_ORDER nhưng chậm hơn WRITESET đối với lưu lượng truy cập đồng thời thấp.
Nó có thể giúp tôi như thế nào?
Ưu điểm đầu tiên là rõ ràng:nếu khối lượng công việc của bạn đang ở mức chậm nhưng các nô lệ của bạn có xu hướng quay trở lại quá trình sao chép, họ có thể hưởng lợi từ hiệu suất sao chép được cải thiện ngay khi bản chính được nâng cấp lên 8.0. Hai lưu ý ở đây:thứ nhất - tính năng này tương thích ngược và 5,7 nô lệ cũng có thể hưởng lợi từ nó. Thứ hai - xin nhắc lại rằng 8.0 vẫn ở trạng thái beta, chúng tôi không khuyến khích bạn sử dụng phần mềm beta khi sản xuất, mặc dù rất cần, đây là một tùy chọn để kiểm tra. Tính năng này có thể giúp bạn không chỉ khi nô lệ của bạn bị tụt hậu. Chúng có thể được bắt kịp hoàn toàn nhưng khi bạn tạo một nô lệ mới hoặc điều chỉnh lại một nô lệ hiện có, nô lệ đó sẽ bị tụt hậu. Có khả năng sử dụng chế độ “WRITESET” sẽ giúp quá trình cấp phép máy chủ mới nhanh hơn nhiều.
Nhìn chung, tính năng này sẽ có tác động lớn hơn nhiều mà bạn có thể nghĩ. Với tất cả các điểm chuẩn hiển thị hồi quy về hiệu suất khi MySQL xử lý lưu lượng truy cập có mức đồng thời thấp, bất kỳ thứ gì có thể giúp tăng tốc độ sao chép trong các môi trường như vậy đều là một cải tiến rất lớn.
Nếu bạn sử dụng trình độ thạc sĩ trung cấp, đây cũng là một tính năng cần tìm. Bất kỳ trình chủ trung gian nào cũng bổ sung một số tuần tự hóa vào cách xử lý và thực hiện các giao dịch - trong thế giới thực, khối lượng công việc trên trình chủ trung gian hầu như sẽ luôn ít song song hơn trên giao dịch chính. Việc sử dụng các bộ ghi để cho phép song song tốt hơn không chỉ cải thiện khả năng song song trên bản chính trung gian mà còn có thể cải thiện khả năng song song trên tất cả các nô lệ của nó. Thậm chí có thể (mặc dù sẽ yêu cầu thử nghiệm nghiêm túc để xác minh tất cả các phần sẽ khớp chính xác) sử dụng một bản chính trung gian 8.0 để cải thiện hiệu suất nhân bản của các nô lệ của bạn (xin lưu ý rằng MySQL 5.7 slave có thể hiểu dữ liệu writeet và sử dụng nó ngay cả khi nó không thể tự tạo ra nó). Tất nhiên, việc sao chép từ 8,0 lên 5,7 nghe có vẻ khá phức tạp (và không chỉ vì 8.0 vẫn là phiên bản beta). Trong một số trường hợp, điều này có thể hoạt động và có thể tăng tốc độ sử dụng CPU trên 5.7 nô lệ của bạn.
Các thay đổi khác trong bản sao MySQL
Giới thiệu các bộ ghi, mặc dù nó là thú vị nhất, nhưng nó không phải là thay đổi duy nhất xảy ra với việc sao chép MySQL trong MySQL 8.0. Hãy xem qua một số thay đổi quan trọng khác. Nếu bạn tình cờ sử dụng một cái chính cũ hơn MySQL 5.0, 8.0 sẽ không hỗ trợ định dạng nhật ký nhị phân của nó. Chúng tôi không mong đợi sẽ thấy nhiều thiết lập như vậy, nhưng nếu bạn sử dụng một số MySQL rất cũ với tính năng sao chép, thì đây chắc chắn là thời điểm để nâng cấp.
Các giá trị mặc định đã thay đổi để đảm bảo sao chép an toàn với sự cố nhất có thể: master_info_repository và relay_log_info_repository được đặt thành TABLE. Expire_log_days cũng đã được thay đổi - bây giờ giá trị mặc định là 30. Ngoài expire_log_days , một biến mới đã được thêm vào, binlog_expire_log_seconds , cho phép chính sách xoay vòng binlog chi tiết hơn. Một số dấu thời gian bổ sung đã được thêm vào nhật ký nhị phân để cải thiện khả năng quan sát về độ trễ sao chép, giới thiệu độ chi tiết micro giây.
Bằng mọi cách, đây không phải là danh sách đầy đủ các thay đổi và tính năng liên quan đến nhân bản MySQL. Nếu bạn muốn tìm hiểu thêm, bạn có thể kiểm tra các thay đổi của MySQL. Đảm bảo rằng bạn đã xem xét tất cả chúng - cho đến nay, các tính năng đã được thêm vào tất cả các phiên bản 8.0.
Như bạn có thể thấy, MySQL replication vẫn đang thay đổi và trở nên tốt hơn. Như chúng tôi đã nói ở phần đầu, đó phải là một quá trình có nhịp độ chậm nhưng thực sự tuyệt vời khi xem những gì phía trước. Thật tuyệt khi thấy công việc cho Nhân bản nhóm nhỏ giọt và được sử dụng lại trong bản sao MySQL “thông thường”.
