maria-developers team mailing list archive

[worklog-noreply@xxxxxxxxxxxx]

-----------------------------------------------------------------------
                              WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...........: Transaction coordinator plugin
CREATION DATE..: Tue, 24 Aug 2010, 14:06
SUPERVISOR.....: 
IMPLEMENTOR....: Knielsen
COPIES TO......: 
CATEGORY.......: Server-Sprint
TASK ID........: 132 (http://askmonty.org/worklog/?tid=132)
VERSION........: Server-9.x
STATUS.........: Assigned
PRIORITY.......: 60
WORKED HOURS...: 0
ESTIMATE.......: 0 (hours remain)
ORIG. ESTIMATE.: 0

PROGRESS NOTES:



DESCRIPTION:

This worklog describes an API that allows a replication plugin to hook deep
into the commit mechanism of transactions in mysqld and implement its own
transaction coordinator (TC).

The existing binary log already implements a TC. This is used to make writes
to the binary log happen in 2-phase commit with transactional engines. It is
also used during crash recovery to get the list of prepared-but-not-committed
transactions from the binary log and ensure that those transactions are
committed (and any others rolled back), to avoid inconsistencies between the
contents of binary log and engines.

Thus the TC needs to be part of a replication API that allows the existing
binary log implementation to be written as a plugin, or to allow the
implementation of a replacement binary log.

In addition, something like Galera synchronous replication needs more control
over the commit process. In particular, it needs to be able to control the
order in which transactions are committed. This worklog extends the TC
interface to also allow TC to control commit order. This part of the worklog
builds on the work in MWL#116, in particular on the prepare_ordered() and
commit_ordered() extensions to the storage engine API.


ESTIMATED WORK TIME

ESTIMATED COMPLETION DATE
-----------------------------------------------------------------------
WorkLog (v4.0.0)