Replication Logs

AxonServer uses Raft to replicate data across your nodes.

In the Raft consensus algorithm, replication logs are vital for maintaining consistency and fault tolerance across the distributed system. These logs ensure all nodes agree on the order of operations by using unique indices and terms (election periods). The leader node accepts client requests, appends them to its log, replicates them across followers, and commits them once a majority acknowledges having added to their logs.

Under no circumstances should an administrator manually interact with , modify or even delete replication logs.

For Axon Server, the entries in the replication log are mostly events. Other entries, like adding a user or creating a context, are also replicated using the same mechanism, but are much more rare.

Apply process

Before writing an event to the event store, an event is stored in the replication logs of a majority of nodes. Only when the nodes confirmed having written the entry, each node reads the replication log and applies the event to the event store.

This means, that at any time there may be some events in the replication logs that have not been written to the event store yet. This is by design and common practice in systems based on raft consensus. As soon as the apply process catches up, these will be applied. In most cases, this is a matter of a few milliseconds. However, this also means that if the replication logs are lost, for example because a disk was wiped by accident, the unapplied entries of that node cannot be applied. When the node recovers, it will receive these entries from the other members of the majority and will be able to continue.

Compaction

In a process called log compaction, the old and already applied log entries are cleaned up by axonserver. When running axonserver, you do not need to take care of this, as this is an automated process.

Operational considerations

Replication logs need not to be confused with application logs: Replications logs contain vital data for the system to work, while application logs merely represent a trace of information about what has happened.

Since replication logs may contain unapplied events, these need to be backed up too. For the exact procedure, refer to the backups page.