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