multiple primary servers

Kevin Darcy kcd at daimlerchrysler.com
Thu Jul 6 02:14:00 UTC 2000


Dino.Chirico at ot.com.au wrote:

> Hi all,
>
> I have two primary servers located behind firewalls and the secondaries are
> exposed. I would like to know if it is possible to have multiple primaries
> be master for the same zone. It was mentioned in O'Reilly but did not
> explain how. I would like to use the second primary server as a failover if
> the first primary fails. Any suggestions????

(I'm not sure exactly how you are using the terms "primary" and "master" here.
I'll assume when you say you have "two primary servers" that you mean masters
for _different_ zones, otherwise if they are defined as master for the same
zone, your question is redundant. Or do you mean something else entirely by
"primary server"?)

What kind of "failover" do you want? If you just want the slaves to failover
to another server to get their zone transfers, then this is rather trivial:
just add the address of your "backup master" to the "masters" clause of the
slave definition.

Or, do you actually want to be able to make changes on the "backup master"
when the regular master is down, and have them propagate normally to the
(external) slaves, i.e. what Win2K-marketing-speak calls "multimaster
replication"? This can't be done with stock BIND alone, but with a little
outside help, a reasonable facsimile can be achieved...

Configure as above, but in addition you need to either 1) define the backup as
a "master" and have some sort of out-of-band mechanism transferring the zone
data and reloading the zone(s), since you'll no longer be able to exploit the
normal named/named-xfer interaction for this task (Dan Bernstein recommends
running rsync over ssh for out-of-band synchronization of zone files, but if
you aren't already running rsync and/or ssh on the box, it could be a pain to
set up from scratch), or 2) use the regular master/slave replication, and have
some "promote" script which reconfigures the backup from being a slave to
being a master in case of failure. The downsides of this approach: a) you lose
the comments, indentation, and potentially-useful directives $TTL and
$GENERATE of the master file, since named-xfer does not preserve these, and b)
you have to figure out a way to "fall forward" when the regular master comes
up again.


- Kevin







More information about the bind-users mailing list