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

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

Probably going to be fixed by the fix for bug #38205.

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).

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.

Page generated in 0.060 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.