I'd keep two copies of the BIND config, one that has all the zones as "master",
and one that has all the zones as "slave". When the master dies, run a little
script on a slave that freezes the zones, edits the SOA to make that server the
MNAME and increment the serial, then thaws the zone. Swap out the config with
the "master" config, and now you have a new master.
Before the broken master comes back online, swap out its config with the
"slave" config.
No need for rsync or mysql, BIND replication does all the work for you. Just
be sure the updates go to the server listed in the MNAME field of the SOA.
Mike Mitchell
________________________________
From: bind-users-bounces+mike.mitchell=sas....@lists.isc.org
[bind-users-bounces+mike.mitchell=sas....@lists.isc.org] on behalf of Bill
Larson [wllarso....@gmail.com]
Sent: Monday, February 14, 2011 10:39 AM
To: fddi
Cc: bind-users@lists.isc.org
Subject: Re: multi-master with mysql backend
On Feb 13, 2011, at 9:06 AM, fddi wrote:
I do not know why you really don't liket this mysql solution.
OK I am talking of a DNS for HA purposes for grid computing services for
exampe, so DNS
resolution must be always working at any cost.
The David solution can be OK, but I want to be sure not to have issues with
serial numbers on the two servers
and the mysql solution looks safer to me. You do not have to rsync anything,
just have mysql properly configured.
This list is read by many people with extreme experience with DNS and DNS
operations. Using the information that you have provided, many solutions have
been provided to meet the requirements that you have stated. I would suggest
that you at least consider this other solutions and not be as adamant about
using your proposed MySQL solution.
You state that you have a "HA" requirement. Please understand that this is not
an uncommon requirement for a DNS operation. In fact, almost all DNS
operations have this same requirement. Just imagine if the root servers did
not have a require for "high availability". The same goes for the "com",
"net", "org" servers ("it" also). This is not an unusual requirement and a
standard BIND DNS server provides this very well.
Now, I would also suggest that a MySQL DNS server may not be the best solution
for a critical DNS operation. Please take a look at the benchmark work done
comparing BIND using various backend systems, including MySQL. This can be
found at http://bind-dlz.sourceforge.net/perf_tests.html, which is part of the
work that the people that developed DLZ for BIND. The standard BIND server
could provide 16,000 queries per second. The same BIND server using a MySQL
backend could handle less than 700 qps.
BIND DLZ using MySQL is NOT what I would consider to be a high performance
solution for a DNS operation. Now, granted, these results were not using a
"current" version of BIND, nor was this being run on any "high power" hardware.
Performance of BIND DLZ using a MySQL backend may have easily been improved,
but so has the performance of the base system too. A 20 to 1 performance
advantage for a straight BIND solution will be hard to overcome.
So, performance isn't something that a MySQL backend provides to a DNS
operation and high availability is something that all DNS server do provide, so
your real requirement must be something else, such as being able to update
multiple servers at the same time. But Doug Barton has identified that using
"nsupdate" to update both (all) servers also provides a solution to meet this
requirement.
So, your "the mysql solution looks safer to me", may be your viewpoint which is
not universally agreed upon. You also have stated "just have mysql properly
configured". This statement is not unique to MySQL but to BIND also. BIND
also needs to be properly configured, no different than with MySQL - nothing
unique here.
Now, my single belief for any DNS operation is to follow the KISS principle,
"keep it simple, stupid". A less complex system will be more reliable than a
more complex system, because of having less potential points of failure. This
reliability is the single most important requirement for a DNS operation. A
DNS operation that requires running both BIND and MySQL will be inherently less
reliable than one running just BIND.
The complexity of a MySQL BIND server makes for a less reliable system than one
just using BIND. The performance of a MySQL based BIND server is much less
than a standard BIND server. Managing DNS information using dynamic DNS
provides a simple solution to updating the zone information. So, what is the
actual advantage of using a MySQL backend to BIND? I'm not convinced that
there is any advantage and I am sure that there are many downsides to using
this.
Using MySQL for a backend to BIND is a fairly commonly proposed solution but
it's actual implementation is not followed up on. I looked at using MySQL, but
the performance limitations were an absolute deal killer. I set up a simple
BIND/MySQL system and benchmarked it and duplicated the performance trends from
the BIND-DLZ developers. Maybe this has been improved, but these results have
not be published so we don't know about it.
If you do implement your MySQL solution, please, please, please, keep us
informed about how it works for you. We would like to know more and are always
willing to look at new technologies but aren't too accepting of hand waving.
Bill Larson
Riccardo
On 2/12/11 11:33 PM, Doug Barton wrote:
On 02/11/2011 01:51 PM, fddi wrote:
I understand you, but the advantage of having mysql backend is that
if one of the two servers dies, the other keeps running with up to
date informations, and can also be updated wit new informations. When
the other server comes up again it will automatically sync itself
using mysql replica mechanism. if I use file backend I have to
manually sync it, and how to keep tracks of modifications ?
for this I choose mysql backend
Two questions, how often do you anticipate one of the masters failing, and how
much data are you talking about? Generally the number of times a server fails
is going to be pretty small, if it's not, you've got bigger problems.
If you're not talking about a huge amount of data here (and from what you've
described in previous posts, you're not) then you are fairly dramatically
over-architecting your solution here. Personally I think David had a great idea
in regards to using nsupdate to update both masters at the same time. If you
really think that one of them is going to fail often enough to justify an
automated solution than scripting something that utilizes rsync shouldn't be
too hard.
hth,
Doug
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
