Details
-
Type:
Task
-
Status: Closed
-
Priority:
Major
-
Resolution: Not a Bug
-
Fix Version/s: N/A
-
Component/s: None
-
Labels:None
Description
Please refer to: https://mariadb.atlassian.net/browse/MDEV-5648
I have the same error and wonder if I can ignore/skip this sort of replication errors (Could not execute Update_rows_v1 event on table tableName; Can't find record in 'tableName', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.***, end_log_pos ***).
Relay bin log extractions:
# at 394 #140813 15:20:53 server id 1 end_log_pos 858286845 Query thread_id=2375878105 exec_time=0 error_code=0 SET TIMESTAMP=1407939653/*!*/; SET @@session.pseudo_thread_id=2375878105/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=0/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C latin1 *//*!*/; SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/; SET @@session.time_zone='SYSTEM'/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; BEGIN /*!*/; # at 474 # at 560 # at 703 # at 773 # at 836 #140813 15:20:53 server id 1 end_log_pos 858286931 Table_map: `Easycall`.`calls` mapped to number 7589 #140813 15:20:53 server id 1 end_log_pos 858287074 Table_map: `Easycall`.`agents` mapped to number 678383 #140813 15:20:53 server id 1 end_log_pos 858287144 Table_map: `Easycall`.`calls_extra` mapped to number 381731 #140813 15:20:53 server id 1 end_log_pos 858287207 Table_map: `Easycall`.`status_log` mapped to number 7604 #140813 15:20:53 server id 1 end_log_pos 858287471 Update_rows: table id 7589 flags: STMT_END_F # at 1100 #140813 15:20:53 server id 1 end_log_pos 858287498 Xid = 251749261622
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Technically you can ignore/skip the errors, see the description of slave_skip_errors variable https://mariadb.com/kb/en/mariadb/documentation/replication-cluster-multi-master/replication/replication-and-binary-log-server-system-variables/#slave_skip_errors .
But you should only do so if you understand why the error happens, and it is not a problem for you.
Otherwise, you should find the root cause.
Sergei's comment from
MDEV-5648mostly applies to your case too, apart from the statement-based part. With mixed/row-based replication, the most usual reason of such failures is running some updates directly on the slave – e.g. you delete some records by running a query on the slave, and then when the same records are deleted on the master, replication breaks because it cannot find the records.The second most frequent is misconfigured replication.
There can be other reasons as well, including possibly a real bug. If you are sure it is not an operational/configuration error but a real bug, please provide more information which you base your conclusion upon.
Thanks.