multi-master with mysql backend

Mon Feb 14 16:52:36 UTC 2011

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is precisely how I'd do it but actually haven't bothered to do the
work of setting up config files in advance. I should, because while it
is an easy task, if I need to do it, I'm probably not in the mood to
figure it out.

Having multiple masters sounds interesting, but considering how close
the slave configuration is to a master configuration (when you take into
account the zone data which is really the important part), it just
doesn't seem necessary.

On 02/14/2011 10:52 AM, Mike Mitchell wrote:
> 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.com at lists.isc.org
> [bind-users-bounces+mike.mitchell=sas.com at lists.isc.org] on behalf of
> Bill Larson [wllarso.dns at gmail.com]
> *Sent:* Monday, February 14, 2011 10:39 AM
> *To:* fddi
> *Cc:* bind-users at 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 at lists.isc.org <mailto:bind-users at lists.isc.org>
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

- -- 
- ---- _  _ _  _ ___  _  _  _
|Y#| |  | |\/| |  \ |\ |  | |Ryan Novosielski - Sr. Systems Programmer
|$&| |__| |  | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/CST-Academic Svcs. - ADMC 450, Newark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1ZXdQACgkQmb+gadEcsb4s5ACg4vyRIG9nYVGByv7pxH0lv7yc
NvUAn1mwDirxMRsmiD6zt5wU6a34q+Fh
=DCpw
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: novosirj.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110214/1c3dc78f/attachment.vcf>