Bug #54249 | More verbose RBR error logging | ||
---|---|---|---|
Submitted: | 5 Jun 2010 2:32 | Modified: | 6 Jun 2010 17:36 |
Reporter: | Shannon Wade | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Row Based Replication ( RBR ) | Severity: | S3 (Non-critical) |
Version: | 5.1 | OS: | Any |
Assigned to: | Assigned Account | CPU Architecture: | Any |
[5 Jun 2010 2:32]
Shannon Wade
[2 Nov 2010 15:57]
MySQL Verification Team
IDEMPOTENT will skip row changes where a row can't be found as mentioned in the docs thus allowing replication to continue, but in addition it should provide some error logging similar to: http://bugs.mysql.com/bug.php?id=43407 Seems SLAVE_SKIP_ERRORS would be preferable 1032,etc to IDEMPOTENT now that it works with RBR ( i had not noticed that fix): http://bugs.mysql.com/bug.php?id=39393 Currently nothing is printed to the error log to indicate that any row changes in an event were skipped. Though I understand we do not recommend IDEMPOTENT, however since SQL_SLAVE_SKIP_COUNTER with RBR skips full events and not rows, customers will likely choose to use IDEMPOTENT or just SLAVE_SKIP_ERRORS if they typically have large events which change many rows. Currently logging is: SQL_SLAVE_SKIP_COUNTER will log positions according to: http://bugs.mysql.com/bug.php?id=43407 But skips full events. Allows some investigation as long as the relay logs are available. SLAVE_EXEC_MODE=IDEMPOTENT Logs nothing. The error/warning should probably give enough information to provide a clue as to the pseudo INSERT,UPDATE or DELETE etc which failed and the "affected row number" and "total number of rows" in the list generated by the statement. SLAVE_SKIP_ERRORS Logs nothing. Here the error should provide some information as to what was skipped and optionally log to the error log or a table for further review. In addition or in some way with the information if available from 'Record original SQL statement in RBR log" http://bugs.mysql.com/bug.php?id=50935 Basically for large customers who typically fix replication errors until they can afford the time to resync it's important to later be able to figure out what was skipped and perhaps fix or repapply these statements partially or completely. Or simply determine if for the time being it's OK to loose those statements/events/rows. Right now with RBR it's easy to skip problems but figuring out the problem or fixing is tricky and time-consuming.