Bug #43217 delayed slave stop for transactional replication
Submitted: 26 Feb 2009 9:45 Modified: 6 Mar 2009 19:13
Reporter: Susanne Ebrecht Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Row Based Replication ( RBR ) Severity:S2 (Serious)
Version:5.0 OS:Any
Assigned to: Assigned Account CPU Architecture:Any

[26 Feb 2009 9:45] Susanne Ebrecht 
Description:
This is related to bug #319

PROBLEMS

1. When slave is stopped *by a user*, the transactional changes
   are not rolled back on the slave.  This causes the changes to
   be re-applied on the slave at later startup causing errors.

ANALYSIS
========

1. Can be solved by a delayed stop as Monty suggested.

This is a great solution but it should be possible to disable delayed stop. Because you won't need a delayed stop for only none transactional replication.

So there should be a variable with which the user has the possibility to enable/disable delayed slave stop.

Because in sum we think there are more users using transactional databases/replications as default the delayed stop should be enabled.

How to repeat:
...

Suggested fix:
See above
[26 Feb 2009 23:11] James Day 
Probably going to be fixed by the fix for bug #38205.
[3 Mar 2009 16:09] Lars Thalmann 
This probably needs to be implemented so that the user can choose what
type of stop should be done.

E.g. by adding a FORCE option to STOP SLAVE that will stop replication
even if there is an ongoing transaction (as it works today).
[6 Mar 2009 19:13] Andrei Elkin 
In fact this one is a dup of Bug #38205 (in row-based part) and
Bug#319 (in statement-based part).
Will be fixed along bug#38205.