-----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....@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 - -- - ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |novos...@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-----
<<attachment: novosirj.vcf>>
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users