Consistency

Consistency refers to the state in which both, the transaction log and the store, describe the same result (i.e. the transaction logs contain every mutation needed to replicate). Consistency is critical and enforced. A master service member cannot go Up if inconsistent.

Consistency checks

The consistency state is verified when a master service member tries to transition from Down to Up. In the case of a slave replica, the check is performed before the replication session is initiated. If the consistency check fails, the service member is considered inconsistent (error state), and an attempt to recover consistency is made through a recovery procedure If the recovery attempt is successful, it means consistency was restored and the service member will eventually be allowed to transition to Up status. Otherwise the service member stays Down and more recovery attempts are made afterwards. Attempts to switch to Up status are made periodically. And each status transition attempt will trigger the recovery procedure, until it succeeds and no more status switching attempts are made.

Inconsistencies at runtime

In some cases, a service member can become inconsistent while the service member is Up. In this situation, the service member is immediately put Down. From there, the service member will constantly try to go Up, thus periodically triggering the consistency recovery procedure.

A service member becomes inconsistent if:

• An append operation to the transaction log fails
• No store transaction execution response is returned in time. The timeout delay is defined as the consistent store service default timeout value, padded with a small extra value.
• An attempt to append to the transaction log a transaction with a timestamp older than the current consistent timestamp.