MySQL Bugs: #55040: Robust alternative for Cluster GCP stop

Bug #55040	Robust alternative for Cluster GCP stop
Submitted:	7 Jul 2010 1:53	Modified:	9 Jan 2015 10:26
Reporter:	Mikiya Okuno	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S4 (Feature request)
Version:	mysql-5.1-telco-7.1	OS:	Any
Assigned to:	Bernd Ocklin	CPU Architecture:	Any

Description:
When using MySQL Cluster under high load, people are very likely to face a problem called "GCP Stop". When a commit timeouts, the only choice is "GCP Stop" now. However, GCP Stop is though choice because time taken to recovery gets longer and longer as amount of data gets bigger. While keeping real-time characteristics is important, keeping a system running important as well. Rolling back only certain transactions would be a good alternative for GCP Stop.

How to repeat:
n/a

Suggested fix:
Please introduce a new parameter which controls a behavior when a commit timeouts whether:

- Shutdown an entire data node
- Rollback all ongoing transactions and keep a data node alive

Hi Mikiya,

GCP(commit) waits for ongoing commits to complete.

Once this has started, there is no way to abort certain transactions.
This as one or more operation might already have been committed,
  and then locks are released, and before-image released.

So any solution based on aborting transaction must
  identify a "bad" transaction and abort it *before* it
  commits.

I think that this is not a bug.

/Jonas

Hi Jonas,

What about aborting all on-going transactions? Is it impossible too?

IMHO, aborting all transactions during a certain period of time is much better than crashing a certain data node.

Otherwise, allowing larger TimeBetweenEpochsTimeout may increase a stability instead of lower performance.

Kind regards,
--
Mikiya