Bug #19958 RBR idempotency issue for UPDATE and DELETE
Submitted: 19 May 2006 21:52 Modified: 28 Nov 2007 10:50
Reporter: Jonathan Miller Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Row Based Replication ( RBR ) Severity:S2 (Serious)
Version:5.1.11 OS:Linux (Linux 32 Bit OS)
Assigned to: Mats Kindahl CPU Architecture:Any
Tags: bfsm_2007_10_18

[19 May 2006 21:52] Jonathan Miller 
Description:
0001' position: 4
060520  0:44:30 [ERROR] Slave: Error in Update_rows event: row application failed, Error_code: 137
060520  0:44:30 [ERROR] Slave: Error in Update_rows event: error during transaction execution on table test.t110, Error_code: 137
060520  0:44:30 [ERROR] Slave (additional info): Unknown error Error_code: 1105
060520  0:44:30 [Warning] Slave: Unknown error Error_code: 1105
060520  0:44:30 [Warning] Slave: Unknown error Error_code: 1105
060520  0:44:30 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'master-bin.000001' position 5397

How to repeat:
comment out -- source include/have_binlog_format_statement.inc in rpl_trigger.test

./mysql-test-run.pl --do-test=rpl_trigger --mysqld=--binlog-format=row
[25 Oct 2007 19:06] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/36367

ChangeSet@1.2582, 2007-10-25 21:05:37+02:00, mats@kindahl-laptop.dnsalias.net +1 -0
  BUG#19958 (rpl_trigger.test causes Error in Update_rows event when used with RBR):
  
  The rpl_trigger test case indicated a problem with idempotency support when run
  under row-based replication, which this patch fixes.
  
  However, despite this, the test is not designed for execution under row-based
  replication and hence rpl_trigger.test is not executed under row-based
  replication.
  
  The problem is that the test expects triggers to be executed when the slave
  updates rows on the slave, and this is (deliberately) not done with row-based
  replication.
[26 Oct 2007 7:33] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/36407

ChangeSet@1.2582, 2007-10-26 09:32:25+02:00, mats@kindahl-laptop.dnsalias.net +3 -0
  BUG#19958 (rpl_trigger.test causes Error in Update_rows event when used with RBR):
  
  The rpl_trigger test case indicated a problem with idempotency support when run
  under row-based replication, which this patch fixes.
  
  However, despite this, the test is not designed for execution under row-based
  replication and hence rpl_trigger.test is not executed under row-based
  replication.
  
  The problem is that the test expects triggers to be executed when the slave
  updates rows on the slave, and this is (deliberately) not done with row-based
  replication.
[30 Oct 2007 20:17] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/36700

ChangeSet@1.2582, 2007-10-30 21:17:19+01:00, mats@kindahl-laptop.dnsalias.net +3 -0
  BUG#19958 (RBR idempotency issue for UPDATE and DELETE):
  
  The rpl_trigger test case indicated a problem with idempotency support when run
  under row-based replication, which this patch fixes.
  
  However, despite this, the test is not designed for execution under row-based
  replication and hence rpl_trigger.test is not executed under row-based
  replication.
  
  The problem is that the test expects triggers to be executed when the slave
  updates rows on the slave, and this is (deliberately) not done with row-based
  replication.
[27 Nov 2007 10:51] Bugs System 
Pushed into 5.1.23-rc
[27 Nov 2007 10:54] Bugs System 
Pushed into 6.0.4-alpha
[28 Nov 2007 10:50] Jon Stephens 
Documented bugfix in 5.1.23 and 6.0.4 changelogs as follows:

        A replication slave sometimes stopped for changes that were
        idempotent (that is, such changes should have been considered
        safe), even though it should have simply noted
        that the change was already done, and continued operation.