2. Primary & Replica Databases

Primary and replica databases

Each database definition may include read and write priorities. A value of 0 disables that kind of query. Positive values enable it, with lower numbers preferred over higher numbers.

A primary commonly accepts both reads and writes:

'write' => 1,
'read'  => 1,

A replica normally accepts reads only:

'write' => 0,
'read'  => 1,

On a busy cluster, the primary can be kept out of the normal read pool:

'write' => 1,
'read'  => 0,

Read-after-write consistency

During a request, LudicrousDB remembers the tables it successfully wrote to. A later read from one of those tables is sent to the same connection, even when that server normally has read => 0. This avoids immediately reading stale data from a replica.

This tracking is local to the current PHP request. It is not a substitute for monitoring replication lag between requests.

Failover boundaries

LudicrousDB can try another eligible server when a connection fails. Every server eligible for the same dataset must actually contain the same current data and be safe for the queries it may receive.

In particular, setting write on more than one server does not create writer failover by itself. Use database-native replication, clustering, or another tested failover system to keep writable servers synchronized. LudicrousDB does not replicate data, elect a primary, or repair divergence.

See Replication Lag for keeping lagged replicas out of the preferred read pool.