Replication is meant to transpose a modification done on one server into the associated servers. We should also insure that a modification done on an entry in more than one server does not lead to inconsistencies.
As the remote servers may not be available, due to network conditions, we also have to wait for the synchronization to be done before we can validate a full replication for an entry. For instance, if we delete an entry on server A, it can be deleted for real only when all the remote servers has confirmed that the deletion was successful.
We will use two tags, stored within each entry, to manage the replication. The CSN (Change Sequence Number) stores when and where (which server) the entry was last modified. A replicated entry on 3 servers will have the same CSN. Before replication they may be different. The UUID (Universal Unique Identifier) is associated with an entry, and only one. So if we have an entry replicated on 3 servers, it will have one CSN (as the entry is at the same version for all servers) and only one UUID (as it's the same entry). The UUID is not currently used. The CSN stored in the entry is used to prevent older modifications overwriting newer ones. Unfortunately this leads to inconsistent servers (see DIRSERVER-894) - we need to check the CSN for each attribute instead. Once this is fixed the CSN stored on each entry will no longer be used.
The replication system is a Multi-Master replication, ie, each server can update any server it is connected to. The way you tell a server to replicate to others is simple :
<replicationInterceptor> <configuration> <replicationConfiguration logMaxAge="5" replicaId="instance_a" replicationInterval="2" responseTimeout="10" serverPort="10390"> <s:property name="peerReplicas"> <s:set> <s:value>instance_b@localhost:1234</s:value> <s:value>instance_c@localhost:1234</s:value> </s:set> </s:property> </replicationConfiguration> </configuration> </replicationInterceptor>
Here, for the server instance_a" we have associated two replicas : *instance_b and instance_c. Basically, you just give the list of remote server you want to be connected to.
The MITOSIS service is implemented as an interceptor in the current version (1.5.4). The following operations are handled :
The hasEntry, list, lookup and search operations are only handled to prevent tombstoned (deleted) entries being returned.
We are using Operation objects to manage replications inside the interceptor. Here is the Operation classes hierarchy :
Each of the interceptor's method handling an entry modification will use one of those classes to store the resulting modification.
It creates a AddEntryOperation object, with a ADD_ENTRY operation type (how useful is it, considering that we are already defined a specific class for such an operation ???), an entry and a CSN.
The newly created entry will contain two new AttributeType :
If the added entry already exists in the current server, then we should consider that the entry can't be added.
It creates a CompositeOperation object, which contains a ReplaceAttributeOperation, as the entry is not deleted, but instead a entryDeleted AttributeType is added to the entry, and a ReplaceAttributeOperation containing the injection of a entryCSN AttributeType, with a newly created CSN.
So here are the operation content :