multi-master with mysql backend
Ryan Novosielski
novosirj at umdnj.edu
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>
More information about the bind-users
mailing list