Distributed Configuration Database (DCDB)
===========================================
We want to implement a simple way to distribute small configuration
files among the cluster on top of corosync CPG.
The set of all configuration files defines the 'state'. That state is
stored persistently on all members using a backend
database. Configuration files are usually quite small, and we can even
set a limit for the file size.
* Backend Database
Each node stores the state using a backend database. That database
need to have transaction support, because we want to do atomic
updates. It must also be possible to get a copy/snapshot of the
current state.
** File Based Backend (not implemented)
Seems possible, but its hard to implement atomic update and snapshots.
** Berkeley Database Backend (not implemented)
The Berkeley DB provides full featured transaction support, including
atomic commits and snapshot isolation.
** SQLite Database Backend (currently in use)
This is simpler than BDB. All data is inside a single file. And there
is a defined way to access that data (SQL). It is also very stable.
We can use the following simple database table:
INODE PARENT NAME WRITER VERSION SIZE VALUE
We use a global 'version' number (64bit) to uniquely identify the
current version. This 'version' is incremented on any database
modification. We also use it as 'inode' number when we create a new
entry. The 'inode' is the primary key.
** RAM/File Based Backend
If the state is small enough we can hold all data in RAM. Then a
'snapshot' is a simple copy of the state in RAM. Although all data is
in RAM, a copy is written to the disk. The idea is that the state in
RAM is the 'correct' one. If any file/database operations fails the
saved state can become inconsistent, and the node must trigger a state
resync operation if that happens.
We can use the DB design from above to store data on disk.
