Database Log
Databases can record changes in an ordered log. Replicas use those records to reproduce the changes.
Writes are appended to a log
A database write travels to an append-only log.
database → log[offset]Replicating the log
In this simplified model, the primary records a write in its log and sends a copy of that entry to the replica. Starting from the same data, the replica records and applies each entry in order, building the same state from the same writes.
Logs are replicated across nodes
All reads and writes go to the primary.
Primary 0 · Received 0 · Applied 0 · Lag 0Reads and writes → primary only
Replication lag
Replication lag is the delay between a write committing on the primary and becoming visible to reads on a replica.
MySQL Group Replication adds coordination: the group agrees on transaction order before a write commits.
Replicas can still be catching up when a write finishes, so reads may return older data. Stronger consistency settings can make transactions wait for synchronization.
Receiving a write is not the same as making it visible to reads. The demo shows two places lag can build up: writes are still traveling, or received writes are waiting to be applied.
Replication between nodes takes time
Replica B · Online. No writes submitted.
Recovering from lag
- Slow processing: faster processing or fewer writes lets B drain its queue.
- Slow delivery: lower network latency lets writes reach B sooner.
- Brief disconnection: if B reconnects before being removed, it can retrieve missed messages still available in another member’s XCom cache.
- Long disconnection: after removal, B must rejoin and recover missing data before returning online.