Atha, Indeed I must not have understood you quite properly. Why would you need even need slave updates and/or master-master replication? The various PDNS servers in this setup are all acting independently without any knowledge of each other. They are all neither masters nor slaves, depending only on their local MySQL slave backend and not all talking to the same master backend. Could you explain further why you think you would need PowerDNS slave updates or master-master replication?
Thanks, Nick On Nov 10, 2010, at 9:14 AM, Atha Kouroussis wrote: > Hi Nick, > thank you for your quick answer! > > Obviously I didn't make myself clear in my email, since the second scenario > we are contemplating, is very similar to what you described: one master > backend, and then each pdns server each with its own slave backend. And I do > see the advantages in robustness and performance of this type of scenario. > MySQL replication (master-slave) is not an issue for us. We are battle > seasoned on that front. > > What I can't really fit in this scenario is slave updates, unless having a > dedicated pdns server talking to the master backend just for this purpose. > Multiple slaves would require either master-master replication (not something > we want to pursue) or multiple instances of pdns talking to the same master > backend. Thanks for your help. > > Cheers, > Atha > > On Nov 10, 2010, at 12:01 PM, Nick Williams wrote: > >> Atha, >> >> Let me share with you what we did at the company I used to work for (and >> this is an identical configuration to what I have setup for myself). We >> don't have master and slave PDNS servers. We have "workers" of sorts. Our >> master and slaves are the MySQL backends. >> >> We have a master MySQL server which is the server that we perform all writes >> against. It serves as the master backend, and no PDNS installations connect >> to it directly. In fact, PDNS isn't even installed on the server that hosts >> the master backend. Then, on each physical (or virtual) DNS server, we have >> MySQL server and PDNS installed. The MySQL server, which is a slave backend, >> replicates off of the master backend. Then, PDNS connects to the local MySQL >> server for its backend. >> >> There are many advantages to setting it up this way: >> >> - Performance: Our PDNS servers are able to more quickly serve out answers >> to questions since they are connecting to a local MySQL instance instead of >> a remote MySQL instance, and we don't have multiple PDNS servers querying >> the same MySQL database, which also decreases response time. >> - Robustness: If our master backend goes down, all PDNS servers can continue >> to answer questions because they are oblivious to this downtime. This is >> very convenient for maintenance periods, also. If one of the "worker" >> servers goes down, again, this is transparent to the master backend and to >> the other workers, which continue to operate as if nothing had happened. We >> don't use master-master replication and, in fact, this increases redundancy, >> it doesn't decrease it. >> >> This is a pretty standard way of configuring PowerDNS, and it has worked >> very well for us. We have had 0% DNS-answer downtime in the last three >> years, even when our master backend crashed due to a hardware failure six >> months ago. It's hard to find any problems with that kind of result. >> >> This is likely a good fit with your organization's needs, as well. I >> encourage you to look into it. As always, when using MySQL replication, make >> sure you have a DBA who understands (or at least is willing to devote >> serious time to understanding beforehand) MySQL replication before >> implementing this system. MySQL replication is very powerful, but it is also >> a challenging system to set up. If you do it right, it will work great for >> you. If you tune something wrong, you could experience some hard-to-diagnose >> replication issues (which, fortunately, will not affect the uptime of your >> PowerDNS services). >> >> One more thing, which I believe you will find very helpful. The nature of >> MySQL replication is that it can go down temporarily to account for minor >> network fluctuations and recover gracefully. However, problems can arise if >> it's down for long periods of time; say, over 48 hours. What we did is set >> up a very small, PHP-based Cron job that runs on every worker server every >> ten minutes, connects to the local MySQL slave backend, and executes the >> query "SHOW SLAVE STATUS;". It then looks at the columns "Slave_IO_Running" >> and "Slave_SQL_Running" in the result set. If they aren't BOTH "Yes", it >> sends us an alert email, and we know there's an issue that needs to be >> addressed. I highly recommend you do something similar. >> >> Feel free to ask me any questions you may have. >> >> Nick >> >> On Nov 10, 2010, at 8:29 AM, Atha Kouroussis wrote: >> >>> Hi all, >>> we are looking to migrate from bind to PowerDNS with MySQL backend. Our >>> initial tests have gone really well and we are now looking into finalizing >>> the architecture for the final deployment and migration. In that respect we >>> have a couple of doubts. >>> >>> Since we are going to be using the MySQL backend, and we are going to have >>> multiple PowerDNS servers deployed, is it possible to have several >>> instances of pdns share the same backend? How does that affect slave >>> updates in case a master has more than one slave configured and both slaves >>> use the same backend? >>> >>> If its not possible to use the same backend, we are thinking of using MySQL >>> replication, master-slave, and have only one pdns instance listed as slave. >>> What we don't like about this setup is the lack of redundancy since in >>> order to have more than one slave listed we would have to use master-master >>> replication, which we are trying to avoid. >>> >>> What are your thoughts on this? Are there any best >>> practices/recommendations for large deployments? Thanks in advance for all >>> your help. >>> >>> Cheers, >>> Atha >>> _______________________________________________ >>> Pdns-users mailing list >>> [email protected] >>> http://mailman.powerdns.com/mailman/listinfo/pdns-users >> > _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
