3 ms·

I'm a bit unclear what they mean by 'true multi-master'. The overview and FAQ lead me to believe this is a perl script with it's own _singular_ db sitting betwe

by mbell 12y ago

I'm a bit unclear what they mean by 'true multi-master'. The overview and FAQ lead me to believe this is a perl script with it's own _singular_ db sitting between multiple databases. Specifically what are the CAP guarantees for this system? At a surface level it almost seems like it's split brained by design.

rosser 12y ago
Multi-master means exactly what you'd expect: N (where N >= 2) masters, each of which can accept writes, which will be propagated to all the other nodes Bucardo knows of. The "_singular_" db is Bucardo's configuration store, and is otherwise uninvolved in replication.
- mbell 12y ago
  > Multi-master means exactly what you'd expect: N (where N >= 2) masters 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.
  - rpedela 12y ago
    I think the FAQ is out of date with this release.
  - rosser 12y ago
    The sibling comment is correct: the FAQ is out of date. Bucardo 4 supported only 2 masters; B5 is N >= 2. 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.
le_meta 12y ago
What's the deal? This is the same cutting edge technology that drives AWS.
antirez 12y ago
> Specifically what are the CAP guarantees 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.

by mbell 12y ago

rosser 12y ago

Multi-master means exactly what you'd expect: N (where N >= 2) masters, each of which can accept writes, which will be propagated to all the other nodes Bucardo knows of. The "_singular_" db is Bucardo's configuration store, and is otherwise uninvolved in replication.

mbell 12y ago
> Multi-master means exactly what you'd expect: N (where N >= 2) masters 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.
- rpedela 12y ago
  I think the FAQ is out of date with this release.
- rosser 12y ago
  The sibling comment is correct: the FAQ is out of date. Bucardo 4 supported only 2 masters; B5 is N >= 2. 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.

le_meta 12y ago

What's the deal? This is the same cutting edge technology that drives AWS.

antirez 12y ago

> Specifically what are the CAP guarantees 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.