I’ve a setup the place a single stateful Bitcoin node (with a read-only pockets) is now not enough because of being a single level of failure and the rising load of requests. Consequently, I must run a number of bitcoind server cases.
Round 6.5 years in the past, on this query, it was acknowledged that sharing a pockets.dat file between a number of bitcoind servers was not doable as a result of threat of pockets corruption and potential lack of funds. Particularly, Ava Chow famous that:
“You shouldn’t share a pockets.dat file between two servers. It might not even work and will lead to pockets corruption and lack of funds. If you’re planning on having the 2 cases open the identical pockets file, that isn’t allowed. BDB (the database system utilized by Bitcoin Core) doesn’t enable a database to be opened by a number of software program concurrently. If you’re in some way in a position to take action, you possibly can corrupt your pockets.
Moreover, even when the pockets file is just not accessed concurrently, the 2 nodes could have completely different sync states which is able to consequence within the software program being confused and probably should rescan each time you begin up one of many nodes. It might additionally produce other points.”
On condition that Bitcoin Core 26.0 Launch Notes state:
“The createwallet RPC will now not create legacy (BDB) wallets when setting descriptors=false with out additionally offering the -deprecatedrpc=create_bdb possibility. It’s because the legacy pockets is being deprecated in a future launch.”
With the change in pockets DB know-how, is it now doable to soundly share a number of pockets information between a number of bitcoind cases, making certain that modifications made on one server are mirrored on the others with out inflicting corruption? Does the brand new pockets know-how assist this use case or does it nonetheless have the identical restrictions because the legacy BDB wallets?
If sharing pockets information continues to be not allowed, what are the really useful methods to scale a stateful Bitcoin Core setup (with pockets) to deal with elevated load and keep away from a single level of failure?
Thanks on your insights.
