Bug #27077 ndb->extra(HA_EXTRA_IGNORE_NO_KEY) becomes repeatedl ineffectiv once was reset
Submitted: 13 Mar 2007 10:46 Modified: 11 Jun 2009 17:07
Reporter: Andrei Elkin Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Cluster: Replication Severity:S3 (Non-critical)
Version:mysql-5.1 OS:Any
Assigned to: CPU Architecture:Any
Tags: 5.1.17

[13 Mar 2007 10:46] Andrei Elkin
Description:
HA_EXTRA_NO_IGNORE_NO_KEY.

There is a patch for Bug#27044 that essentially completes execution of
   table->file->write_row()
with resetting of
   table->file->extra(no-sematics-argument)-s 
in generic replication code (log_even.cc). Resetting is done because 
before write_row is called there were table->file->extra(yes-sematics-argument).

The patched replication code looks as
   table->file->extra(yes-sematics-argument)
   table->file->write_row()
   table->file->extra(no-sematics-argument)  // added by the patch

This code sustains basically all tests except rpl_ndb_idempotent.test where
ndb handler reports an error that was not supposed to happen.

Note, that other engines like myisam, heap, innodb do not create a situation
described in How-2-repeat.

How to repeat:
apply patch for Bug #27044 and execute
mysql-test-run.pl --mysqld=--binlog-format=row t/rpl_ndb_idempotent.test

to find out that the final update from master 
     UPDATE t1 SET c2="does not exist" WHERE c3=1;
triggered the error and that is NOT supposed to happen.

Finer simpler test is just to execute the final part of the test, in which
synch won't happen because slave must hang due to UPDATE

--connection master
CREATE TABLE t1 (c1 CHAR(15) NOT NULL, c2 CHAR(15) NOT NULL, c3 INT NOT NULL, PRIMARY KEY (c3)) ENGINE = NDB ;
INSERT INTO t1 VALUES ("row1","remove on slave",1);

--sync_slave_with_master
--connection slave
DELETE FROM t1;

--connection master
BEGIN;
UPDATE t1 SET c2="does not exist" WHERE c3=1;
INSERT INTO t1 VALUES ("row2","new on slave",2);
COMMIT;

--sync_slave_with_master
[14 Mar 2007 6:49] Andrei Elkin
Taking on myself to analyze the case better.
[15 Mar 2007 18:45] Andrei Elkin
Closing it though smells bad.
What remains wondering me is that 
an attempt to set ndb's mood in  Write_rows_log_event::do_before_row_operations with
  table->file->extra(HA_EXTRA_IGNORE_NO_KEY);
and reset at Write_rows_log_event::do_after_row_operations with
  table->file->extra(HA_EXTRA_NO_IGNORE_NO_KEY);

creates a side effect: slave stops with 
                 Last_Errno: 839
                 Last_Error: Error in Write_rows event: error during transaction execution on table test.t1

when executing the reported piece of rpl_ndb_idempotent
Needs discussing with cluster team.
[2 May 2007 14:25] Andrei Elkin
Tested how possibly fix for Bug #27320 ndb handler does not reset extra flags on reset() could affect the current case.

The reported test still fails if 
int Write_rows_log_event::do_after_row_operations()
executed the matching (to do_before_row_operations

    table->file->extra(HA_EXTRA_NO_IGNORE_NO_KEY); 

rpl_ndb_idempotent             [ fail ]

Errors are (from /tmp/andrei/mysql-5.1-new-rpl/mysql-test/var/log/mysqltest-time) :
mysqltest: At line 106: could not sync with master ('select master_pos_wait('master-bin.000001', 1007)' returned NULL)

slave.err:

070502 17:17:28 [ERROR] Slave: Error in Write_rows event: error during transaction execution on table test.t1, Error_code: 839
070502 17:17:28 [ERROR] Slave (additional info): Unknown error Error_code: 1105
070502 17:17:28 [Warning] Slave: Got error 839 'Illegal null attribute' from NDB Error_code: 1296
070502 17:17:28 [Warning] Slave: Unknown error Error_code: 1105
070502 17:17:28 [ERROR] Error running query, slave SQL thread aborted.
[1 Jun 2007 19:23] Bugs System
Pushed into 5.1.20-beta
[25 Jun 2007 11:17] Andrei Elkin
"Pushed" should be ignored - a mistake of pushbuild buglist generator.
[19 May 2009 12:49] Jonathan Miller
Still and issues?