maria-developers team mailing list archive

[worklog-noreply@xxxxxxxxxxxx]

-----------------------------------------------------------------------
                              WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...........: Promotion of new master in "full independence" parallel
		replication.
CREATION DATE..: Mon, 13 Dec 2010, 13:55
SUPERVISOR.....: 
IMPLEMENTOR....: 
COPIES TO......: 
CATEGORY.......: Server-RawIdeaBin
TASK ID........: 170 (http://askmonty.org/worklog/?tid=170)
VERSION........: Server-9.x
STATUS.........: Un-Assigned
PRIORITY.......: 60
WORKED HOURS...: 0
ESTIMATE.......: 0 (hours remain)
ORIG. ESTIMATE.: 0

PROGRESS NOTES:



DESCRIPTION:

MWL#169: "Parallel replication of transactions in distinct databases" allows
replication events and transactions to be applied on the slave in parallel,
and potentially out-of-order (in "full independence").

This makes it more complex to promote a new master in case the old master dies
or needs to be taken offline. The issue is that the states of any two slaves
may not be commensurable, meaning that either slave may have a transaction
applied that is missing on the other.

This is more complicated that with old single-threaded replication, where
there is a single ordered replication stream; then between any two slaves one
will be ahead (or equal) to the other, and the one ahead can serve immediately
as a master for the other. So with single-threaded replication, the problem is
merely to find a slave that is maximally progressed.

This worklog proposes an algorithm that allows to keep track of the states on
slaves and a way to use this information to promote a new master reliably and
potentially automated.

This assumes that some kind of *global transaction ID* is implemented, along
the lines of the Google patch for this [1]. A global transaction ID uniquely
identifies the event(s) of a transaction (or event group in the case of
non-transactional statements) across the entire replication topology. Global
transaction IDs are monotonic, so E1 occurs before E2 if and only if the ID of
E1 is less that the ID of E2.

Note that we do not require all IDs to be comparable; in the case of two
independent masters, events from different masters will be incomparable. (A
common implementation is to use (server_id, incrementing_64bit_int) as the
ID).

Also note that we do not require ID sequences to be without holes, just that
they are increasing. So it is permissible that IDs (server1,10) and
(server1,12) exist, yet that there never existed any event with ID
(server1,11).

[1] http://code.google.com/p/google-mysql-tools/wiki/GlobalTransactionIds


ESTIMATED WORK TIME

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