How can I switch Slave Server to Primary ?

Kevin Darcy kcd at daimlerchrysler.com
Mon Dec 4 20:28:30 UTC 2000


Joseph S D Yao wrote:

> On Mon, Dec 04, 2000 at 07:00:05PM +0900, Rahul Parasnis wrote:
> > Hello All,
> > How can I switch Slave Server to Primary in-case Primary is down .
> > I know that it depends on expire Value, but how can make the Slave server as Primary , if I can not receover Primary at all?
> >
> > I have to write a procedure for this, I was wondering if anyone has this procedure already ?
> >
> > Thanking you ...
> >
> > - Rahul
>
> In /etc/named.conf, change the slaves to point to the new master, and
> change the master to declare itself a master.  Force them all to
> re-read their configurations.

Actually, none of this is immediately necessary if you *already* have the "backup master" in the "masters" list of all the
slaves. For instance, the way I have things structured here, there's an "inner circle" of slaves and all of these slaves have the
regular master and at least 2 other "inner circle" slaves in their "masters" lists. That way, if the master croaks, any changes
that were replicated to at least one of these "inner circle" slaves will eventually get to all of them. Also, it means I can
reconfigure any of them to be the master temporarily without reconfiguring any of the others (although propagation will slow down
if I leave things like that).

> You might also want to restore the master's "named.conf", since a
> slave's version is nowhere near as readable.

Speak for your own slave configurations! :-)

My slave configs are maintained automatically by a script. They may not be as chatty with comments as the master's config, but
they are quite readable, from a strictly functional point of view. In fact, the script goes to great lengths to *sort* the slave
definitions hierarchically and numerically ("arpa" comes before "com", for instance, but "53.in-addr.arpa" comes before
"129.in-addr.arpa"), so that it's easy to locate a particular zone definition when necessary.


- Kevin




More information about the bind-users mailing list