Hi,
You hint that you observe some issue when doing hundreds of NETCONF edit-configs to the running datastore without giving away any details besides a picture that you don’t describe. Can you describe the issue and picture in detail?
Regarding your question, CDB by default store the entire configuration in RAM as well as on disk. The configuration is persisted (written to disk) in the “WRITE” step of a write transaction. If you have the candidate enabled, it may also be stored on disk.
Here’s an example of the phases of a successful transaction to the running datastore (e.g. a NETCONF edit-config with target running):
+-------+
| START |
+-------+
|
|
v
+------+
| READ |
+------+
|
| trans lock
v
+----------+
| VALIDATE |
+----------+
|
|
v
+-------+
| WRITE |
+-------+
|
|
v
+----------+
| PREPARED |
+----------+
|
|
v
+-----------+
| COMMITTED |
+-----------+
|
| trans unlock
v
START
CDB store configuration data by default persistently in a file called “A.cdb”. This file is a journal file, i.e. each transaction (e.g. NETCONF edit-config with target running) is just appended to this file and when the transaction has been completed ConfD adds a “magic marker”.
If ConfD is killed/crash and subsequently restarted at some point during an ongoing transaction, ConfD will read the transaction that has been committed and if there is a transaction at the end of the file with a missing “magic marker”, the transaction will be considered incomplete and the transaction will be ignored.
A transaction is either committed or not. A transaction cannot be partially committed. Even though there is a power outage either the writing of the “magic marker” succeeds or fail, so just a part of a transaction cannot make it into the journal file.
Since just adding data to journal file would lead to that we eventually would run out of disk space, ConfD run an algorithm that handle compacting it automatically by default.
ConfD perform a compaction by writing the data it has stored in RAM to a file named, for example, A.cdb.tmp and then rename the file from *.cdb.tmp to *.cdb. Hence, the compaction cannot fail since, even though if there is a power outage, the renaming of the file either succeeds or fail.
After a successful compaction the journal file will contain one single transaction that can be applied in one go if ConfD is restarted.