ConsistentCut splits WAL on 2 global areas - Before
and After
. It guarantees that every transaction committed Before
also will be committed Before
on every other node participated in the transaction. It means that an Ignite node can safely recover itself to the Before
state without any coordination with other nodes.
The border between Before
and After
areas consists of two WAL records - ConsistentCutStartRecord
and ConsistentCutFinishRecord
. It guarantees that the Before
consists of:
ConsistentCutStartRecord
and weren't included into ConsistentCutFinishRecord#after().
ConsistentCutStartRecord
and ConsistentCutFinishRecord
and were included into ConsistentCutFinishRecord#before()
.On the picture below the Before
area consist of transactions colored to yellow, while After
is green.
/** */ public class ConsistentCutStartRecord extends WALRecord { /** Consistent Cut ID. */ private final UUID id; } /** */ public class ConsistentCutFinishRecord extends WALRecord { /** Consistent Cut ID. */ private final UUID id; /** * Collections of transactions committed BEFORE. */ private final Set<GridCacheVersion> before; /** * Collections of transactions committed AFTER. */ private final Set<GridCacheVersion> after; }
lastFinishedCutId
holds previous ConsistentCutId
, or null.DistributedProcess
with special message holds new ConsistentCutId
(goal is to notify every node in a cluster about running incremental snapshot). ConsistentCutId
by discovery.ConsistentCutId
by transaction message (Prepare, Finish)ConsistentCutId
, every node: ConsistentCut<Boolean>
future. Complete with true
if consistent, otherwise false
. committingTx
(goal is to track COMMITTING transactions, that aren't part of IgniteTxManager#activeTx
)ConsistentCutId
.IgniteTxManager#activeTx.
Set listeners on tx#finishFuture.
ConsistentCutStartRecord
to WAL with the received ConsistentCutId
.committingTxs.
Set listeners on tx#finishFuture.
committingTxs.
DistributedProcess
is alive every node signs output transaction messages:ConsistentCutId
(to trigger ConsistentCut
on remote node, if not yet).ConsistentCutId
(to trigger...) and transaction ConsistentCutId
(to notify nodes which side of cut this transaction belongs to).ConsistentCutId
on node that commits first:committingTxs
.check If transaction state is UNKNOWN or status is RECOVERY_FINISH, then complete ConsistentCut as inconsistent.
txCutId
equals to local, then transaction put into after
, otherwise it's put into before
.ConsistentCutFinishRecord
into WAL with the collections ( before
, after
). ConsistentCut
future as consistent.ConsistentCut
:lastFinishedCutId
with the current.
ConsistentCut
future becomes null.Consistent Cut is such cut that correctly finished on all baseline nodes - ConsistentCutStartRecord
and ConsistentCutFinishRecord
are written.
"Inconsistent" Cut is such a cut when one or more baseline nodes hasn't wrote ConsistentCutFinishRecord
. It's possible in cases:
tx.finalizationStatus
== RECOVERY_FINISH).Every ignite nodes tracks current ConsistentCutMarker
:
id
is just a unique ConsistentCut
ID (is assigned on the node initiator).
On the picture below on left side is a diagram of sending transaction messages. Before sending message it checks whether cut is running with cutMarker()
. If it is then wrap message, otherwise send ordinary message (PrepareRequest
in example).
Ignite transaction protocol includes multiple messages. But only some of them affects meaningful (relating to the algorithm) that change state of transactions (PREPARED, COMMITTED):
GridNearTxPrepareRequest / GridDhtTxPrepareRequest
GridNearTxPrepareResponse / GridDhtTxPrepareResponse
GridNearTxFinishRequest / GridDhtTxFinishRequest
Those messages are wrapped in MarkerMessage
that is prepared right before sending message on other node. They used the current ConsistentCutMarker
for setting the marker.
class MarkerMessage { Message msg; ConsistentCutMarker marker; }
Also some messages require to be signed with additional ConsistentCutMarker
to check it them on primary/backup node.
GridNearTxFinishRequest / GridDhtTxFinishRequest
GridNearTxPrepareResponse / GridDhtTxPrepareResponse
(for 1PC algorithm).Those messages are wrapped in TransactionFinishMarkerMessage
that is prepared right before transaction starts committing on first committing node. They used the current ConsistentCutMarker
for setting the txMarker
. txMarker
can be null, if transaction starts committing before ConsistentCut starts.
class TransactionFinishMarkerMessage extends MarkerMessage { @Nullable ConsistentCutMarker txMarker; }