Re: Comments on replication consistency models

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

(The first part of this, I know, is just preaching to the choir...
the second part might be of more interest to developers.)

I note that my I-D focuses on the lost of ACID properties at the
master and with directory updaters, but does say:
 It is noted that X.500 replication (shadowing) model allows for      
 transient inconsistencies to exist between the master and shadow
 copies of directory information.  As applications which update       
 information operate upon the master copy, any inconsistencies in
 shadow copies are not evident to these applications.

I said "master copy" not "directly with the master".  That is,
the application can specify dontUseCopy to ensure it reads
its (and any subsequent) updates.

In LDAP, the application can simply read its updates through
use of the post-read entry control (RFC 4527).  And soon, the
LDAP dontUseCopy control mechanism will be standardized.

Now, if a client reads without using one of these two mechanisms,
then, of course, it risks getting an old entry.  That's X.500
(and LDAP).

The service can try to prevent an updater from getting
an old entry using one (or a combination) of approaches...


>We can guarantee "read your writes" consistency with the help of a tweaked chaining overlay. I.e.,
>1) the client issues a write request to a slave
>2) the slave chains the request to the master
>3) when the chained write succeeds, the slave performs the write locally
>4) the response is returned to the client

There is a problem with this approach.  The write at
the master could succeed but fail at the slave because of
inconsistencies between the slave and the master (as measured
at the times each update is to be applied) caused by
replication lag (or other issues).  Another approach would
be to include a post-read control to the chained operation
and just sync the entry to that.   But replication lag
can causes problems in this approach as well (consider
renamed entries).   One possible approach for dealing with
replication lag issues is to use an assertion control to
ensure modify is being applied to proper entry.

Another approach is to simply chain reads of any updater.
This approach suffers from disconnect issues (unless the
service has a long memory).

-- Kurt