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:
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
Triage: Needs Triage: D5 (Feature request)

[12 Dec 2008 8:15] Rafinal Rafik
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.
[16 Jan 2009 16:35] Susanne Ebrecht
Many thanks for writing a bug report. Did you use statement based, row based or mixed replication?
[21 Jan 2009 9:34] Rafinal Rafik
row based. The limitation issued here: http://dev.mysql.com/doc/refman/5.1/en/innodb-and-mysql-replication.html
[26 Jan 2009 14:38] Susanne Ebrecht
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.
[27 Jan 2009 8:14] Mats Kindahl
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.