Cân nhắc về tính toàn vẹn và hiệu suất của dữ liệu trong sao chép bán đồng bộ MySQL

Sao chép bán đồng bộ MySQL cung cấp tính toàn vẹn của dữ liệu được cải thiện vì khi một cam kết trả về thành công, dữ liệu tồn tại ở ít nhất hai nơi - chính và phụ của nó. Trong bài đăng trên blog này, chúng tôi xem xét một số cấu hình lưu trữ MySQL ảnh hưởng đến tính toàn vẹn dữ liệu và các khía cạnh hiệu suất của sao chép bán đồng bộ. Chúng tôi sẽ sử dụng công cụ lưu trữ InnoDB và sao chép dựa trên GTID trong tập hợp bản sao 3 nút (chính và 2 nô lệ), điều này sẽ đảm bảo có dự phòng trong các nô lệ. Điều này có nghĩa là nếu có vấn đề với một nô lệ, chúng tôi có thể giải quyết vấn đề với người khác.

Cấu hình áp dụng cho cả nút chính và nút nô lệ

• innodb_flust_log_at_trx_commit =1
• sync_binlog =1

Những cấu hình này đảm bảo cài đặt độ bền và tính nhất quán cao cho dữ liệu. Có nghĩa là, mỗi giao dịch đã cam kết được đảm bảo có mặt trong các bản ghi nhị phân và các bản ghi này cũng được lưu vào đĩa. Do đó, trong trường hợp mất điện hoặc sự cố hệ điều hành, tính nhất quán dữ liệu của MySQL luôn được bảo toàn.

Cấu hình trên Master Node.

• rpl_semi_sync_master_wait_for_slave_count:

Tùy chọn này được sử dụng để định cấu hình số lượng nô lệ phải gửi xác nhận trước khi một tổng thể bán đồng bộ có thể thực hiện giao dịch. Trong bộ bản sao 3 nút, chúng tôi khuyên bạn nên đặt giá trị này thành 1, để chúng tôi luôn đảm bảo rằng dữ liệu có sẵn trong ít nhất một nút phụ trong khi tránh bất kỳ tác động hiệu suất nào liên quan đến việc chờ xác nhận từ cả hai nút.

• rpl_semi_sync_master_timeout:

Tùy chọn này được sử dụng để định cấu hình khoảng thời gian mà một tổng thể bán đồng bộ chờ xác nhận phụ trước khi chuyển trở lại chế độ không đồng bộ. Chúng tôi khuyên bạn nên đặt giá trị này thành một số lớn để không có chế độ dự phòng cho chế độ không đồng bộ, điều này sau đó đánh bại mục tiêu toàn vẹn dữ liệu của chúng tôi. Vì chúng tôi đang hoạt động với 2 nô lệ và rpl_semi_sync_master_wait_for_slave_count được đặt thành 1, chúng tôi có thể giả định rằng ít nhất một trong số các nô lệ xác nhận trong một khoảng thời gian hợp lý, do đó giảm thiểu tác động đến hiệu suất của cài đặt này.

Cấu hình trên các nút Nô lệ

Trong nô lệ, điều quan trọng là phải theo dõi hai vị trí rất chính xác:vị trí được thực thi hiện tại của luồng SQL trong nhật ký chuyển tiếp và vị trí hiện tại của luồng IO cho biết khoảng cách tập tin nhị phân cũ được đọc và sao chép sang nô lệ. Hậu quả của việc không duy trì các vị trí này là khá rõ ràng. Nếu có sự cố nô lệ và khởi động lại, chuỗi SQL có thể bắt đầu xử lý các giao dịch từ một điểm bù sai hoặc chuỗi IO có thể bắt đầu lấy dữ liệu từ một vị trí sai trong nhật ký nhị phân chính. Cả hai trường hợp này sẽ dẫn đến hỏng dữ liệu.

điều quan trọng là đảm bảo an toàn khi va chạm cho nô lệ thông qua các cấu hình sau:

• relay_log_info_repository =TABLE
• relay_log_recovery =BẬT

Đặt relay_log_info_repository thành TABLE sẽ đảm bảo vị trí của luồng SQL được cập nhật cùng với mỗi cam kết giao dịch trên máy chủ. Tuy nhiên, rất khó để duy trì vị trí chính xác của luồng IO và xả vào đĩa. Điều này là do việc đọc nhật ký nhị phân chính và ghi vào nhật ký chuyển tiếp nô lệ không dựa trên các giao dịch. Tác động đến hiệu suất là rất cao nếu vị trí luồng IO phải được cập nhật và chuyển vào đĩa sau mỗi lần ghi vào nhật ký chuyển tiếp nô lệ. Một giải pháp thanh lịch hơn sẽ là đặt relay_log_recovery =ON, trong trường hợp này, nếu có khởi động lại MySQL, các bản ghi chuyển tiếp hiện tại sẽ được cho là bị hỏng và sẽ được lấy mới từ bản chính dựa trên vị trí chuỗi SQL.

Cuối cùng nhưng không kém phần quan trọng, điều quan trọng cần lưu ý là sao chép bán đồng bộ đảm bảo rằng dữ liệu vừa 'tiếp cận' một trong các nô lệ trước khi chủ thực hiện giao dịch và không có nghĩa là các giao dịch được cam kết trên nô lệ. Do đó, sẽ rất tốt nếu đảm bảo rằng chuỗi SQL hoạt động với hiệu suất tốt. Trong trường hợp lý tưởng, luồng SQL di chuyển song song với luồng IO để chúng ta có thể có lợi ích của việc nô lệ không chỉ nhận các giao dịch mà còn cam kết chúng. Bạn nên sử dụng cấu hình phụ đa luồng để chúng tôi có thể tăng hiệu suất luồng SQL phụ. Các cấu hình quan trọng cho nô lệ đa luồng là:

• slave_parallel_workers:Đặt giá trị này thành> 1 để bật nhiều nhân viên luồng SQL nô lệ. Dựa trên số lượng luồng ghi trên cái chính, chúng tôi có thể quyết định một con số tối ưu cho việc này để máy chủ không bị trễ.
• nô lệ-song song-loại =LOGICAL_CLOCK
• nô lệ-bảo tồn-cam kết-đặt hàng =1

Các cấu hình trên sẽ hứa hẹn tính song song trong máy chủ, đồng thời duy trì thứ tự giao dịch như đã thấy trên cấu hình chính.

Tóm lại, bằng cách sử dụng các cấu hình trên trên bộ bản sao MySQL của chúng tôi, chúng tôi có thể duy trì tính toàn vẹn của dữ liệu cao cùng với hiệu suất tối ưu.

Như thường lệ, nếu bạn có bất kỳ câu hỏi nào, hãy để lại nhận xét cho chúng tôi, liên hệ với chúng tôi theo địa chỉ @scalegridio trên Twitter hoặc gửi email cho chúng tôi theo địa chỉ hỗ trợ @ scalegrid.io.