On my experience, push is never a good mechanism to ’synchronize’ what we can call ‘distributed’ databases (which in this case are not if we strictly embrace the term).
In our case, we run multiple databases in this schema you mention cloud and no-cloud but with no way to use a direct replication or sync mechanism within the database engine. If it helps, what works for me is to delegate the sync to a middleware as you mentioned, but never pushing, pulling, always pulling and always using an extra layer (the most important for me) the extra layer for us is Kafka, and I think this could work with a queue like rabbitmq too (never tested but it could). How we do this? Think “primary side” and “secondary side”, primary side will run a kafka broker where the provisioning part, whenever inserts a new record for primary site, also produces an entry to kafka. Secondary site is connected to kafka as consumer and will see the new record and will insert it locally in secondary site and … 1. If you loose connection between secondary and primary kafka will hold the updates (for the time you configure retention time in the topic) so when connection is restored, secondary site (consumer) will receive from where it left. 2. You can use the same kafka to connect multiple secondary sites 3. It doesn’t differs on your approach (of a middleware) 4. You can grow in the future holding more topics in the same kafka for other purposes without disrupting existing 5. You can replay topics whenever you want to test integrity Again, this is what we do, from small databases (in K order of records) to important ones (in G order of records) and have no problem in terms of syncing (we also run multiple scripts to verify integrity in a crontab way) regards > On Jan 24, 2025, at 11:41 AM, Laura Smith via Pdns-users > <pdns-users@mailman.powerdns.com> wrote: > > I am looking at building in some multi-cloud resilience to a deployment, was > considering my options and would appreciate any thoughts ! > > So far, my ideas are: > > 1) > Run both clouds completely independently and have some middleware that pushes > the same API command to both PowerDNS instances. I know this is popular in > some circles and indeed there are one or two middleware tools already out > there, e.g. DNSControl. > > Clearly this probably has the best resilience options given the complete > independence of both sides. But it does require the middleware bit to be > bulletproof. > > 2) > My existing PowerDNS is simple, two region backed by PostgreSQL which > replicates to standby Postgres in the other region. So theoretically this > should be robust for 99.9% of issues apart from complete cloud failure. > > I am therefore thinking perhaps on the second cloud I should use the PowerDNS > Lighning Stream backend (to keep costs down and also to provide resilience > against any possible issues with Postgres by using a different backend at the > different cloud). > > And so the question here is if there is an easy way to pull the data in ? > Clearly I can give the PowerDNS server read-only permissions to the > PostgreSQL backend in the other cloud, but can then automagically pull that > data across into Lighning Stream ? Clearly I could build some API scripts > but I'm looking for a more "built-in" way, since home-made scripts mean > maintenance and debugging. :) > > 3) > Other option I might have missed ? > > Thanks in advance ! > > Laura > > _______________________________________________ > Pdns-users mailing list > Pdns-users@mailman.powerdns.com > https://mailman.powerdns.com/mailman/listinfo/pdns-users _______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
