I have two docker hosts, each running their own Pihole containers, and both have read/write volumes to the same nfs mount shared on both docker host.
Both Pi-hole instances' have been running as expected, but I'm trying to gauge if this is going to fail eventually (synchronous writes?) or suffer some type of corruption. My assumption is this isn't a standard practice based on the sync projects.
I know there are options and other ways to do this, the question is more of a gee whiz and 'why not' kind of question to increase my knowledge base.
To start with, Pi-hole wasn't designed to work with a shared database.
It works assuming it is the only process accessing and writing to the database.
But more importantly, SQLite3 (Pi-hole's database backend) is not designed for write concurrency at all: Only one process is ever allowed to write to the database.
In busy environments, multiple different origin write requests may cause write attempts to starve.
What's more, SQLite3's write locking is based on locking database files, and as such is depending on file locking routines of the underlying OS.
Unfortunately, OS level file locking is known to be somewhat buggy across all OSs when it comes to network shares, which means you are bound to provoke database corruption when storing SQLite3 database file on NFS shares.
Complementing Bucking_Horn's answer, you shouldn't do that because each Pi-hole will write to the same database, but the records will be completely scrambled.
Pi-hole initially stores all queries in an in-memory database.
Then, from time to time, this in-memory database is saved to the disk.
The issue is:
each Pi-hole will receive queries from different devices and for different domains. One Pi-hole will log you phone as device ID=1, but probably the other Pi-hole will log another client with this ID. The same happens with the domains. Each domain has its ID and the IDs will be different in both Pi-holes (in-memory).
When this different records are saved to the "shared" database, they will be completely useless and meaningless. The IDs will be useless.
Thank you for the responses. It's crazy how long both have 'worked' configured this way based on what's mentioned above. I've moved them to their own local fs. Good case of not all 'simplification' ideas are good ones
We try to make Pi-hole as robust as possible against all kinds of strange things and while your shared volume configuration will affect the saved statistics in the way described above, this should not* have an impact on the actual blocking or in general DNS processing.
*) Else than the mentioned possible file locking issues which could indeed stop one of the two to work either intermediately or even permanent in rare cases