| Bug #22742 | extraneous table_map events with insert delayed | ||
|---|---|---|---|
| Submitted: | 27 Sep 2006 15:24 | Modified: | 29 Jun 2011 13:36 |
| Reporter: | Andrei Elkin | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server: Row Based Replication ( RBR ) | Severity: | S2 (Serious) |
| Version: | 5.1.12,5.1.40 | OS: | Linux (linux) |
| Assigned to: | Mats Kindahl | CPU Architecture: | Any |
[28 Sep 2006 1:56]
MySQL Verification Team
Thank you for the bug report.
[13 Nov 2009 14:07]
MySQL Verification Team
the fact that insert delayed totally breaks replication means that anybody using binlog_format=row and does insert delayed will have an unusable slave. Testing: setup a working master/slave with RBR and run on master: drop table if exists t1; create table t1(a int,primary key(a))engine=myisam; insert delayed into t1 values (3),(4),(5); insert delayed into t1 values (6),(7),(8); delete from t1 where a>7; update t1 set a=a*10 where a<4; Slave breaks and gets totally out of sync: 91113 16:03:28 [ERROR] Slave SQL: Could not execute Delete_rows event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log xp64-bin.000001, end_log_pos 448, Error_code: 1032 91113 16:03:28 [Warning] Slave: Can't find record in 't1' Error_code: 1032 91113 16:03:28 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'xp64-bin.000001' position 305
[29 Jun 2011 13:36]
Jon Stephens
Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.mysql.com/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to 'Open'. Thank you for your interest in MySQL.
Description: execution of binlog_row_binlog -> extra/binlog_tests/ binlog -> binlog_insert_delayed results with the number of table_map events does not match to the number of insert delayed queries. It also impossible to predict how many table maps are come out on different platforms even though the number of inserted rows remain the same and there is no concurrent connections. This is as least suboptimal, and makes SHOW BINLOG indeterministic useless for replication tests. How to repeat: # just to show table_maps do not match the inserts one-by-one This a part of extra/binlog_tests/binlog_insert_delayed.test create table t1 (a int not null auto_increment, primary key (a)) engine=myisam; insert delayed into t1 values (null),(null); show binlog events from 102; # two table maps generated => | dsl-hkigw8-feb9fb00-191-bin.000001 | 487 | Table_map | 1 | 526 | table_id: 15 (test.t1) | | dsl-hkigw8-feb9fb00-191-bin.000001 | 526 | Write_rows | 1 | 560 | table_id: 15 flags: STMT_END_F | | dsl-hkigw8-feb9fb00-191-bin.000001 | 560 | Table_map | 1 | 599 | table_id: 15 (test.t1) | | dsl-hkigw8-feb9fb00-191-bin.000001 | 599 | Write_rows | 1 | 633 | table_id: 15 flags: STMT_END_F Suggested fix: examine the stack responsible for extra table_map to find out what makes the code to think that the statement ends. THD::binlog_write_table_map (anonymous namespace)::write_locked_table_maps (anonymous namespace)::binlog_log_row<Write_rows_log_event> handler::ha_write_row