Bucardo 5, async replication for PostgreSQL with true multi-master
blog.endpoint.com
blog.endpoint.com
The "_singular_" db is Bucardo's configuration store, and is otherwise uninvolved in replication.
But the FAQ says it only supports 2 masters?
> each of which can accept writes, which will be propagated to all the other nodes Bucardo knows of.
How are conflicts dealt with? Is the resolution serializable?
> The "_singular_" db is Bucardo's configuration store, and is otherwise uninvolved in replication.
If it fails does sync stop? If sync stops how is healing performed?
I appreciate the response but it doesn't really tell me anything about how I can expect the system to perform with nodes/network failures. I swept through the docs but didn't see much of anything on the topic.
I'll try briefly to answer your questions, having used Bucardo for several years, having a (woefully under-utilized) commit bit, and being a somewhat active participant on the mailing list and in #bucardo.
Conflicts are handled in one of a number of user-selectable ways ("latest" wins, "source" wins, &c). They're selectable on a per-table basis.
If the configuration DB were to stop, I don't actually know what would happen. I've never faced that scenario. AIUI, however, Bucardo only reads its configuration on startup, so it shouldn't break anything unless you were to try to change your replication configs (or restart, which doesn't typically need to happen), at which point you'd be able to address it.
If syncing stops, "deltas" (which are merely a timestamp and the pkey of the changed record) accumulate in their source databases until syncing is resumed. Healing consists of those deltas being replayed against their targets, as managed by the selected conflict resolution strategy.
I don't know but we already know it is asynchronous and is multi master from the title of the story, so it surely is an eventually consistent DB, at best AP.
Supposedly you can write a custom conflict handler (in Perl, naturally). But I find it worrying that a feature that's so critical for correctness is also entirely undocumented. I found an open issue to write some docs[2], which refers the curious to a single unit test that was deleted in 2011 with the commit message "Spelling cleanups, other maintenance" [3]. Doesn't inspire a lot of confidence.
[1]: http://bucardo.org/wiki/Swap [2]: https://github.com/bucardo/bucardo/issues/61 [3]: https://github.com/bucardo/bucardo/commit/5eeb51d5bb7dd379bb...
I would hope that that's not a problem with Bucardo or in fact any serious database system.
http://www.mysqlperformanceblog.com/2012/03/27/innodbs-gap-l... http://pooteeweet.org/blog/745
If you actually have that problem in production, it is because you are spreading the writes out to all of your Galera servers and simultaneously doing conflicting updates/transactions.
I'm uncertain what exactly you expect any database to do in this situation? Silently discard one?
See http://www.toofishes.net/blog/mysql-deadlocking-simple-inser... -- that's an old blog post but this still happens with a reasonably late mysql and mariadb. I have no reason to believe that it's not a fundamental design failure. It's of course not a Galera issue per se, but rather a more serious InnoDB issue, but it causes problems very easily when using Galera.
Perhaps there's a workaround that I don't know of yet? I'd be happy to hear of it. Perhaps it's a fundamental RDBMS problem that I don't understand yet? I'd be happy to be educated if so.
As to your last question, I'd expect the database system to accept all such inserts to all instances since they don't conflict with each other in any way.
(Note that Bucardo is mirrored to github; the official repo is on bucardo.org.)