Establishing a backup primary-master

[Robert Spangler]

On Tuesday 13 January 2009 19:40, Baird, Josh wrote:

>  I am in the process of developing a DR (disaster recovery) plan for my
> primary masters.  Could someone please confirm (or correct me) that a
> second server in the "masters {}" statement of a slave zone will only be
> used in the event that the first master cannot be reached?  Example:
>
>  zone "example.com"{
>    type slave;
>    masters {
>      1.1.1.1; // primary-master
>       2.2.2.2; // primary-master backup
>    }
>
>  I only want 2.2.2.2 to be used when 1.1.1.1 is not available.

I can understand all to well what you are trying to do and can only tell you 
what my tests have shown when doing this while thinking outside the box.

My test lab was setup as follows:

Primary Master
Backup Master

Slave 1
Slave 2
Slave 3
Slave 4

I setup each master to be a slave of the other (primary was a slave to backup 
and backup was a slave to primary) so that when one would be removed from the 
network if changes were made when the one that was removed was placed back on 
the network it would update automatically.  This worked great!  This kept my 
masters in sync at all times while they were on line.

What was able to find out about this setup was the slaves were order aware.  
If the primary master in the listing was removed and the backup was updated 
the slaves would not update right away.  They would wait 'x' amount of time 
before updating.  I believe this is some sort of wait timer so that if you 
have more then one Master they both would not be trying to update the same 
zone file at the same time.  Not sure if there was an "option' flag I should 
have set or not to make this work differently but I believe this to be the 
best way for this operation.

>  I plan on writing a script to add the primary-master backup's IP address
> to the masters statement of all slave zones as well as replacing "type:
> slave;" with "type: master;" and removing the masters {} statement from the
> primary-master backup zones (which are currently slave zones) which will
> become master zones in the event of a failure.

If you are not worried about timing and can wait, I believe it wasn't very 
long, the slave will update the slaves without a config change.

>  All servers are running the most current EL5 BIND package.

I will say this setup was tested on an older version of bind and using 
CentOS4.


-- 

Regards
Robert

Linux User #296285
http://counter.li.org