BUG#11760927: 53375: RBR + NO PK => HIGH LOAD ON SLAVE (TABLE
SCAN/CPU) => SLAVE FAILURE When a statement containing a large amount of ROWs to be applied on the slave, and the slave's table does not contain a PK, it can take a considerable amount of time to find and change all the rows that are to be changed. The proper slave enhancement will be implemented in WL 5597. However, in this bug we are making it clear to the user what the problem is, by printing a message to the error log if the execution time, for a given statement in RBR, takes more than LONG_FIND_ROW_THRESHOLD (set to 60 seconds). This shall help the DBA to diagnose what's happening when facing a slave server that is quiet for no apparent reason... The note is only printed to the error log if log_warnings is set to be greater than 1. sql/log_event.cc: Core of the patch. In Rows_log_event::do_apply_event, sets STMT start timestamp. In Rows_log_event::find_row, if a PK is not used, then the start timestamp is checked to see if the time spent on this STMT is enough to justify the printing of a note (only if it was not printed before). sql/log_event.h: Defining LONG_FIND_ROW_THRESHOLD. sql/rpl_rli.cc: Resets long_find_row state in rli->context_cleanup(). sql/rpl_rli.h: Two new rli properties that are necessary to control when to emit a note in the error log: 1) timestamp that states when the ROW statement started; 2) flag indicating whether the note has been emitted for the current statement or not. Also deployed accessors.
Showing
Please register or sign in to comment