Durable Domain Configuration

The durable domain configuration contains domain configuration information that is stored consistently on each admin service process in the domain. It ensures safety under failure for database creation and cold start of databases. The information in the durable domain configuration includes:

  • Whether there is an admin service quorum

  • Which admin service process is the leader

  • Which admin service processes are followers

  • Database metadata

  • Domain state machine — The DSM contains the last known information about Transaction Engines (TEs) and Storage Managers (SMs), including the database and host that each TE and SM is associated with.

Domain State Replication

The durable domain configuration is implemented using the Raft Consensus Algorithm. Raft writes to a file system log for durability. Each admin service process has a Raft log.

NuoDB Admin uses the Raft consensus algorithm to replicate state among Admin Processes (APs). A particular AP is elected as leader by consensus and becomes responsible for replicating all state changes, in order, to all followers in the form of Raft commands. A command is committed once it has been replicated to a majority of APs. When a process finds out that a Raft command has been committed, it applies the state change to its local state.

Most of the state exposed by the admin layer via REST APIs is state that is replicated using Raft. Because a state change must be replicated to a majority before it can be applied, as described above, it is possible for the actual state of the system to diverge from what is reported by the admin layer for some time. For example, if there are two APs, and the two APs become unable to communicate with each other, any state change occurring during this time (such as a database process dying) will not be reported by the APs servers until communication between them is restored.