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