MySQL Bugs: #41419: replication-cascade problem

Bug #41419	replication-cascade problem
Submitted:	12 Dec 2008 8:15	Modified:	26 Jan 2009 14:38
Reporter:	Rafinal Rafik	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S4 (Feature request)
Version:	5.1	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	cascade, innodb, myisam, replication

Description:
Can we avoid the replication-cascade problem? Because we want to use MyIsam on slave for performance reasons and still need to use InnoDB on master for higher consistency by implementing cascading update.

How to repeat:
Set Up Replication With:
Master: Using InnoDB tables and implementing cascading update
Slave: Using MyIsam

Try to update master by a statement which involved cascading update.
Then check if all updates affected the slave (which is not).

Suggested fix:
We want to avoid this problem.

Many thanks for writing a bug report. Did you use statement based, row based or mixed replication?

row based. The limitation issued here: http://dev.mysql.com/doc/refman/5.1/en/innodb-and-mysql-replication.html

Many thanks for your feedback. Now I understand your feature request. I will set it to verified so that our development is able to discuss this.

Replication team has discussed this internally already (in association with BUG#32506) and it requires two things:

- Providing an injector interface so that storage engines can notify
  the replication system that additional rows were changed. This was added
  as WL#4152.

- The storage engine writer has to use this interface and inform the server
  of any unexpected changes done internally.

This work is currently not planned for implementation, but since it is a relatively small and simple feature, it is likely to be included in the not too far future.