<div dir="ltr"><div dir="ltr">On Tue, Nov 17, 2020 at 7:04 PM Steven Garner via Pdns-users <<a href="mailto:pdns-users@mailman.powerdns.com">pdns-users@mailman.powerdns.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">What is the accepted best practice with Primary and Secondary (multiple) PowerDNS Servers?<br><br>Assume PowerDNS server is set up with a MySQL (or other) database back-end. With at least 2 servers each on different networks, should the master instance of PowerDNS and each slave instance query the same MySQL DB, or should each one have its own local MySQL DB?<div></div></div><br></blockquote><div><br></div><div>My 2 cents: Don't know if it's best practice, but we run local dbs on all replicas (and pretty sure that's very common). It's DNS, so it's nice to avoid the extra latency of talking to a remote database, and for us, the concurrency would be too high (we're web hosting, so it's a very random, only mildly cacheable dataset). It's certainly extra administrative overhead to run dbs on every replica, but you get horizontal scaling out of the bargain. If you have a small dataset (i.e. very very high cache hit rate, in which case you're hardly hitting the db), then a central db might work for you. We run dnsdist in front of pdns auth too (love it btw). If your dataset is smallish (again, very cacheable), you might even consider running a bunch of frontend dnsdist instances talking to a small set of pdns auth backends (or a frontend recursor, but I like dnsdist better), to keep your mysql infrastructure smaller/tidier.</div><div><br></div><div>What does your DNS dataset look like? How many domains, how many records, how many dns reqs/sec?</div></div></div>