MySQL Bugs: #12403: rpl_row_del_all Causes inconsistant results on the slave using RBR

Bug #12403	rpl_row_del_all Causes inconsistant results on the slave using RBR
Submitted:	5 Aug 2005 17:29	Modified:	6 Aug 2005 21:30
Reporter:	Jonathan Miller	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Documentation	Severity:	S3 (Non-critical)
Version:	5.0-wl1012	OS:	Linux (Linux)
Assigned to:	Stefan Hinz	CPU Architecture:	Any

Description:
This is a classic case of what will not work with row based replication. I am submitting it for the Docs team to have if they wish to include it into the 5.0 replication docs.

Use the rpl_delete_all.test and change 
-- source include/have_binlog_format_statement.inc
to 
-- source include/have_binlog_format_row.inc

and start with --mysqld=--binlog-format=row

How to repeat:
master> create table t1 (a int);
or (it does not matter)
master> create table t1 (a int, primary key (a));

slave> show tables;
+----------------+
| Tables_in_test |
+----------------+
| t1             |
+----------------+
1 row in set (0.00 sec)

slave> insert into t1 values(1);

master> delete from t1;

slave> select * from t1;
+------+
| a    |
+------+
|    1 |
+------+
1 row in set (0.00 sec)

row is still present

master> insert into t1 values(2);
Query OK, 1 row affected (0.00 sec)

master> update t1 set a=2;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0

master> select * from t1;
+------+
| a    |
+------+
|    2 |
+------+
1 row in set (0.00 sec)

slave> select * from t1;
+---+
| a |
+---+
| 1 |
| 2 |
+---+
2 rows in set (0.00 sec)

Suggested fix:
Document for customer education on RBR

Added note and example demonstrating how replication might break with RBR when you have data-changing operations on the slave server (a scenario that won't cause problems with SBR). Still commented out until we have RBR in place.