Bug #32150 Replication fails with Falcon when when 'Delete from table' is issued
Submitted: 6 Nov 2007 19:02 Modified: 5 May 2008 18:17
Reporter: Omer Barnir (OCA) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Falcon storage engine Severity:S2 (Serious)
Version:6.0.3 OS:Any
Assigned to: Christopher Powers CPU Architecture:Any

[6 Nov 2007 19:02] Omer Barnir
Description:
Issuing a 'delete from table <table_name> on a falcon table, causes the SQL thread to abort on the slave with an "Error in Delete_rows event: error during transaction execution on table db1.tb_falcon" error. 

How to repeat:
1) Start both master and slave using:
   mysql-test-run.pl --start-and-exit --do-test=rpl_alter --mysqld=--falcon
   Note: the 'do-test' is is only used to ensure both master ans slave start;
2) Log into the slave
   a. run a 'change master to...' command to point to your master
   b. start the slave
   c. run show slave status
   >> Verify both IO and Slave threads are running
3) Log into the master and run the following sql:
   create database db1;
   use db1;
   create table tb_falcon (i int) engine=falcon;
   insert into tb_falcon values (1), (2), (3), (4);
4) Log into the slave and wait until you see the table and the values replicated 
   to the slave.
5) Log into the master, set to the db1 database and run:
   delete from tb_falcon;
6) Log onto the slave
   run 'show slave status'
   >> the SQL thread has stopped and the above error is logged
   >> The deleted rows still show in the slave tb_falcon table.
      (use tb1; select * from tb_falcon;)

Suggested fix:
Replication should not fail in the above scenario.
[13 Nov 2007 14:13] Kevin Lewis
Chris, can you figure out what causes this?
[30 Nov 2007 1:33] Christopher Powers
I reproduced the failure on linux (xeno.mysql.com, OpenSuSE 10.3) two weeks ago. Since then, we've merged with the 6.0.4 codebase and pushed many Falcon changes, and I can no longer reproduce the failure. Maybe it was a fix in Falcon, maybe the server. Don't know.

There remains a problem on Windows, however, such that "DELETE FROM t1" propagates to the slave, but no records are deleted. Debugging reveals that the server does a table scan for each record, but the scan ultimately fails because Rows_log_event::find_row() returns a record not found error, even though Falcon finds each record requested by the server. 

Interestingly, deleting individual or multiple rows works ok. I think this needs more analysis by the Replication team.
[3 Dec 2007 4:36] 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/39085

ChangeSet@1.2724, 2007-12-02 22:35:56-06:00, chris@xeno.mysql.com +2 -0
  Bug#32150, Replication fails with Falcon when 'Delete from table' is issued
  
  Replication requires a fully populated record in the binlog in order to replicate deletes and some updates.
  If the binlog is open, Falcon will return fully populated records to the server on DELETE and UPDATE operations.
[3 Dec 2007 4:55] Kevin Lewis
Reviewed code. Looks OK.  We must be willing to accept a performance hit (rumored to be about 1% on average) related to materializing the full record that is deleted or updated if the binlog is recording the change.
[3 Dec 2007 10:02] Bugs System
Pushed into 6.0.4-alpha
[21 Feb 2008 14:59] Kevin Lewis
Patch is in mysql-6.0-release version 6.0.4
[5 May 2008 18:17] Paul DuBois
Noted in 6.0.4 changelog.

DELETE FROM tbl_name (no WHERE clause) for a Falcon table caused
replication to fail on the slave.