W2K multi-master features

[Simon Waters]

Josh Littlefield wrote:
> 
> > I think the conflict issue applies in theory to all DDNS, as
> > there is no guarantee in the BIND model, that the primary
> > receives or distributes updates in a timely fashion, so a client
> > might ask to delete it's old record again, even though the
> > master has already done it, but the slave hasn't caught up for
> > some reason.
> 
> DNS Update provides prerequisite support and a guarantee of atomicity to
> avoid such problems.  If the client cares whether a record is present as a
> condition of an update, it can assert as much in the prerequisites of the
> update packet.  Unfortunately, AD's multi-master approach violates the
> atomicity requirements and means that such prerequisites can only be tested
> locally.  Two clients which use prerequisites to avoid performing
> conflicting actions can still get the wrong result if talking to different
> masters in AD.  This cannot happen in the single-master case, for example,
> with BIND.

Yes - I realised these occurred, although I hadn't worked out if
they were potentially a problem.

I think if you were attempting to use DDNS to fail over a
database application to a different back end server then
transactions could arrive at two different servers using ADS,
and only one using BIND. 

Thus a programmer could fall foul of ADS if he designed for
BIND, or assumed the atomicity of DDNS was guaranteed, as some
database fail-over scenario's could fail if they expected
sequential fail-over. Hopefully anyone designing failover
systems would be aware of such a possibility, but it is rope
someone will hang themselves on one day.

> > I need to think this area through as I seem to remember some
> > special cases appear in multimaster replication of relational
> > databases, and it will be interesting to see if any can apply to
> > DNS. It is just possible one applies to the SOA serial number,
> > but I'll read up.
> 
> AD is not a database.  Database instances are normally tightly coupled,
> though in single master cases slaves may run a bit behind.  AD is loosely
> coupled and non-transactional.  Replication happens infrequently (I think
> the default is once per hour, and the minimum time I recall being able to
> set was once every 15 minutes).

Yes, but Oracle (as one I've worked with) supports asynchronous
multimaster replication, which maintains the atomicity of
transactions, and so is analogous to ADS in many ways, but with
the addition of atomicity in transaction. 

Curiously Microsoft database replication technology didn't
attempt to ensure transactional integrity in similar replicated
environments. The idea of lost of transactional integrity in a
database didn't sit well with our database gurus, who left the
porting of a multimaster replication version of their product
from Oracle to MS-SQL to people less concerned about
transactional integrity.

The Oracle documentation notes that whilst you can have lots of
conflict resolution mechanisms (built-in) when you have one
master, the general case is far more restrictive, and that with
update conflict you only have (built-in) minimum, maximum,
latest timestamp and additive (probably most appropriate for
serial number), guarantee to cause convergence with multiple
masters. (It also notes you have delete and uniqueness conflicts
for which Oracle provide no general conflict resolution
mechanism as it is dependent on application logic).

I'm fairly sure there is a special multimaster replication case
that can only occur with four (or more) masters in RDBMS, but I
can't find the reference at the moment. Most other problems kick
in at three, or two masters.

Whilst the redundancy provided by ADS is nice to have, it isn't
clear it is necessarily based on sound design decisions, but
that would not exactly be a first for Microsoft.