Some more about replication.
I will use a real use case to illustrate the way replication would work
wrt the previous post. Suppose that we have 2 servers, A and B,
synchronized at t0. At t1, they get disconnected (at this point, they
hold the same set of entries). A's admin add a new entry at t2, and
tells B's admin to do so, as it's an important entry to have on both
servers, until the servers get connected back. So does B's admin, at t3,
using the most excellent Apache Directory Stuio, of course :).
Now, both servers have the added entry. Sadly, B's admin is leaving in a
freezing country, and because of his frozen fingers, have made a mistake
in the entry. Never mind, it's 8 pm, and the connection will be
re-establish back in one hour, as told by the local bloody ISP... So B's
admin simply delete the added entry at t4
At this Point, A contains the added entry, and B does not. A's change
log contains the addition of E and B's change log contains the addition
_and_ the deletion of this entry. T5: the servers get connected back and
have to replicate. We rebuild the list of changes to apply on both
servers, using the change logs.
This is where we have different cases, depending on what are the local
times on those machines. We will assume that machine A is the reference,
and machine B is having a lag of T unit of times (ie, A's time + T = B's
time). Note that we aren't talking about time zone, just about a small
difference of time as if the two machines were located on the same building.
So what cases are we considering ?
t1 : servers disconnected
t2 : entry added on A
t3 : entry added on B
t4 : entry deleted on B
t5 : servers reconnected
t1 and t5 are always the first and last events. All the other events can
be mixed, keeping the order when operations are done on the same server,
like :
1) t1, t2, t3, t4, t5
2) t1, t3, t2, t4, t5
3) t1, t3, t4, t2, t5
( we can't have t4 before t3, because those operation sboth occurs on B)
What are the consequences when applying those modifications on A and B?
1) On A, applying op[t3], we get an error, because the entry already
exists. op[t4] removes the entry. On B, op[t2] creates the entry, op[t3]
creates it (error), and op[t4] deletes it. At the end, both servers are
synchronized, but the entry is not present anymore
2) On A, the entry is added by op[t3], added by op[t2] (error) and
deleted by op[t4]. On B, the very same. We end with the same state as on (1)
3) On A, the entry is added, deleted and added. On B, the entry is
added, deleted and added. We end with an existing entry.
We can see that, depending on which operations are done first, we may
end with a different state. It's all depending on the date the
operations are played.
Or, we may want that server A is the reference, and that any
modification made on A superseed modifications made on B. We can do that
but that mean we never apply a modification on an entry already modified
by another server. It also implies that we have defined an order on the
servers priority.
Last point : we see that the only difference might be the time it takes
to propagate modifications from a server to another. As communications
are done through the network, and as there is a latency, we should
consider that all servers are permanently disconnected for a very short
period of time (generally ms, but it can be hundred of ms, even if the
connections are still up). So a fully connected network of LDAP servers
is a bit like a fully disconnected network servers, replicating each
others every time :).
From the scenario we just have seen, we must as much as possible have
all the server sharing the same time (almost), using NTP for instance.
Of course, this perfect synchronization is not reachable (AFAIR, NTP
synced servers have a variable accuracy, which can be under a ms, or
above,de pending on many parameters). But as we won't have millions of
modifications done per second, and as ADS is not able to absorb more
than a few hundreds of modifications per second (atm :), this is not
really important.
More to come later, but in the mean time, thanks for your insights !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
