Bug #116460 Improve the scheduling mechanism of the SQL thread to enhance the replica replay
Submitted: 23 Oct 2024 13:04 Modified: 23 Oct 2024 14:14
Reporter: Bin Wang (OCA) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Replication Severity:S5 (Performance)
Version:all versions OS:Any
Assigned to: CPU Architecture:Any

[23 Oct 2024 13:04] Bin Wang 
Description:
During MySQL secondary replay, if a later transaction depends on a preceding one that hasn't finished replaying yet, the scheduling thread will block itself. This approach is inefficient because the worker replay thread should ideally handle such waits, not the scheduling thread. The scheduling thread itself has plenty of other tasks to handle, and there's no guarantee that the subsequent transaction couldn't be replayed promptly.

How to repeat:
In a certain high-performance machine environment, using the BenchmarkSQL TPC-C testing tool, the throughput could not keep up with the primary server once it exceeded 250,000 TPMC. After improving the scheduling, even with 500,000+ TPMC, it can keep up with the primary server's pace.
[23 Oct 2024 14:14] MySQL Verification Team 
Thanks for the report.