• Print
  • Share
  • Dark
    Light

Managing Manual Multi-master

  • Updated on 21 Jan 2019
  • 2 minutes to read
  • Contributors

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

In BIND 9, it is relatively simple to switch a server from slave to master in real time: if you store the data in a file, simply redefine the zone type and change type master; to type slave;. (Note that we have added the aliases primary for master and secondary for slave in general, although we use the original terms here.)

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

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

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

and returning the active master to a standby master:

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 slaves as masters to the standby master, you have a very low probability of a lost update due to the active master dying before the update makes it onto one of the slaves. named will almost certainly be up-to-date on the standby master by the time it is promoted to active master. This can be checked by verifying all the serial numbers for the zones.

You also need to be able to detect whether the second master 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 slave zones in files, this solution will not work for you.

Why do I need a second master?

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

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

Note that slaves can be slaves to multiple servers, and servers can have multiple roles. One server can fetch one zone from its master, but be a master 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.

Was this article helpful?