Bug #25140 replication / binlog with view breaks
Submitted: 18 Dec 2006 12:53 Modified: 18 Dec 2006 13:35
Reporter: Martin Friebe (Gold Quality Contributor) (OCA) Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.0.30 OS:FreeBSD (freebsd)
Assigned to: CPU Architecture:Any
Tags: binlog, replication, VIEW

[18 Dec 2006 12:53] Martin Friebe
Description:
When dropping or altering a view, while executing an insert or update on it, the binlog will contain the statements in the wrong order.

The drop or alter view will be first in the binlog, followed by the update or insert.
Therefore replication of the statements is not possible

In the examples, open 2 mysql sessions. The user log is only used for timing.

How to repeat:
#prepare:
drop table if exists b1; create table b1 (a int, b int);
drop table if exists b2; create table b2 (a int, b int);
drop view if exists v1; create view v1 as select * from b1;

# mysql 1
select get_lock('a',1);
reset master;

# mysql 2 (will wait)
insert into v1 values (11,  get__lock('a',200) );

# mysql 1
alter view v1 as select * from b1;
do release_lock('a');

# wait for mysql 2 to execute...

flush logs;
drop table if exists b1;

### same with update and alter

drop table if exists b1; create table b1 (a int, b int);
insert into b1 values(1,2);
drop view if exists v1; create view v1 as select * from b1;

# mysql 1
select get_lock('a',1);
reset master;

# mysql 2
update v1 set a=1 where b = get_lock('a',200);

# mysql 1
drop view v1;
do release_lock('a');

flush logs;
drop table if exists b1;

Suggested fix:
Either make "drop view" / "alter view" waiting for any insert/update query on the view to finish
OR include the masters definition of the view in the binlog. (as special comment, or as rewrite)

The last option (bin log contains rewritten sql) will affect do-replicate config.
[18 Dec 2006 13:35] Martin Friebe
sorry, I overlooked a line in the binlog