Managing Manual Multi-master

Automatic multi-primary is really hard to do; just ask anyone that does database replication. However, manual multi-primary is easier as you have a human in the loop deciding which machine is primary.

In BIND 9, it is relatively simple to switch a server from secondary to primary in real time, if the secondary stores the zone data in a file. Simply redefine the zone type, change type secondary; to type primary; and remove the primaries statement. For example:

Server with a secondary zone

zone "example.com" {
   type secondary;
   file "db.example.com";
   primaries {192.168.1.1;};
};

Converted to a primary zone

zone "example.com" {
   type primary;
   file "db.example.com";
};

However, if you have many thousands of zone files in your primary, modifying these zone blocks sequentially and then reloading BIND 9 will take a lot of time.

Switching a server from standby primary to active primary can be a simple as:

cp /etc/named.active.conf /etc/named.conf
rndc reload

and returning the active primary to a standby primary:

cp /etc/named.standby.conf /etc/named.conf
rndc reload

if you keep /etc/named.active.conf and /etc/named.standby.conf preconfigured for the two modes of operation.

Since you are using dynamic update:

active:

zone example.com {
		type master;
		masterfile-format raw;
		update-policy {};
		...
	};

standby:

	zone example.com {
		type slave;
		masterfile-format raw;
		masters { other-master; all-the-machines-that-transfer-from-one-of-these-masters; };
		update-forward { … };
		...
	};

then you use rsync to keep /etc/named.active.conf and /etc/named.standby.conf up-to-date.

When you use all the secondaries as primaries to the standby primary, you have a very low probability of a lost update due to the active primary dying before the update makes it onto one of the secondaries. named will almost certainly be up-to-date on the standby primary by the time it is promoted to active primary. This can be checked by verifying all the serial numbers for the zones.

You also need to be able to detect whether the second primary is in active or standby mode when you reboot the server. If you can’t determine this, put the server into standby mode, using the following commands and cross-checking:

zone standby-mode {
   type master;
   file "active.db";
};

zone standby-mode {
   type master;
   file "standby.db";
};

If you do not keep secondary zones in files, this solution will not work for you.

Why do I need a second primary?

Imagine this scenario: One primary may send a notify packet unsuccessfully with the increment of secondary DNS. You need one group of secondary servers to connect the first primary, and the other group of secondary servers to connect to the second primary. So these two primary zones must be fully consistent.

Or this one: If one primary goes down, you need to switch to another primary right away, so the second primary needs to have the same zone and configuration as the first.

Note that secondaries can be secondaries to multiple servers, and servers can have multiple roles. One server can fetch one zone from its primary, but be a primary to another server for the same zone.

Multi-master is an extremely complex topic, so this article cannot possibly answer all questions about it. Please feel free to post other questions on the bind-users mailing list, or visit our website to find out more about our support options.