> So it can be done then? Use NOTIFY and not have data loss on the slaves?
A packet lost in transit is not "data loss on slave". If the data
never gets there, slave can't lose it. Inconsistency would be more
of a correct term here.
Such inconsistencies can be monitored for very well, and if you
> If you are afraid of losing a notify, you are free to force your Supermaster
> to periodically notify all Superslaves about *all* zones. If Superslave hasn't
> yet heard of a zone due to a missed NOTIFY, it'll pull it from the master.
So it can be done then? Use NOTIFY and not have data loss on
> > Many protocols for distribution of data have a certain ordering and an
> > acknowledgement
> > mechanism. NOTIFY does have an acknowledgement mechanism (but PowerDNS
> > masters don't
> > do a lot with it) but no ordering. It's easier to lose things with NOTIFY
> > than with
> > other rep
> Many protocols for distribution of data have a certain ordering and an
> acknowledgement mechanism. NOTIFY does have an acknowledgement mechanism (but
> PowerDNS masters don't do a lot with it) but no ordering. It's easier to lose
> things with NOTIFY than with other replication protocols.
T
On 08.11.2012 22:48, a b wrote:
> Using purely DNS for zone replication (supermaster) is nice and sounds
> great, but also has disadvantages, e.g. it is not reliable: If the
> NOTIFY could not be delivered to the slave, then the slave is
> inconsistent. So, you need another mechanism to ver
