Database replication process
Only transactions (stored procedures (sprocs) and their arguments) are replicated over to other nodes:
The sprocs and arguments are sent to and queued on all db nodes at the time they happen on the node of origin.
During auto discovery some bulk data is replicated as well: diffsets.
If changes are made out-of-band directly to the databases (delete, insert or update table rows), those changes have to be applied separately to all nodes’ databases, because the normal replication process described below will not send such changes over to other databases. This positive side effect ensures that if some disastrous out-of-band process affects one database, the data in the other replicated databases will not be affected.
When an operation is performed on one node (requested from the web-based interface or some automation), the sprocs triggered by various utilities, interface modules and services are sent from other binaries to the iddb service, that places them in a local queue, and sends them to all other node’s iddb services, which in turn place them in their local queues and execute them in the order they are received.
Those replication queues, both "send" (sq) and "receive" (rq), are kept in the instance’s db\replication directory of every node engaged in database replication.
The settings for those queues are recorded in a node’s service\iddb.cfg and can be changed in the web-based interface from Manage the system > Maintenance > Database replication and click the node's Configuration tab.
The queues are not deleted when replication is suspended or disabled or nodes are removed, so if they are not empty when replication is re-enabled, iddb will continue to play back their content.
There are several ways that these transactions will not be replicated, thus leaving the databases in desynchronized states; see below.