multi-master with mysql backend

Mon Feb 14 15:39:37 UTC 2011

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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110214/5aa8e95b/attachment.html>