3

We are setting up a database on three different Postgresql servers (and maybe on more in the future), currently syncing all tables using bucardo multi-master groups.

We are not syncing sequences; we tried that, and we noticed bucardo is making us lose data when simultaneous writes occur in the same table, on different servers. Since they use the same keys, on sync time bucardo chooses to drop one of the duplicate rows.

Our current approach is to manually namespace the sequence on each instance of the database. E.g. instance 1 is left as it is, all instance2 table sequences are updated to start from 2^31/10, instances3 table sequences will be altered to start from 2^31/10*2 .. instance10 sequences to start from 2^31/10*9.

What is your opinion on this approach and what other advice do you have for a Bucardo multi-master setup? Postgresql BDR is not an option as it is not considered a stable release yet.

Mihnea Simian
  • 1,093
  • 1
  • 7
  • 13

1 Answers1

0

Sequences must not be replicated in a multi-source setup with Bucardo as conflicts will arise.

Start the sequences in different big numbers is a common, valid, approach. For me is a question about:

  • If you apply "semantic meaning" to the auto incremental primary key, like "insertion order"
  • How do you reason about the data
  • The expected amount of rows that will be generated in each database. For example if most of your rows will be generated from only one of the sources, maybe put the same number of available autoincrements in all the sources is not the best strategy.

If there are only two sources involved in the sync my preferred strategy is use odd numbers for one, and even for the other.

If there are up to nine sources, for me is easy to reason about the data setting up the autoincrement value to 10, and start each db in a different number, 1, 2, ... so, "first database" will generate 1, 11, 21, ... second 2, 12, 22, ... A good thing of this approach is that if you start with four sources and need another one, nothing should be changed. In your suggested strategy if you split all available space between 4 databases, and need another one split again the space is more difficult.

If you are not limited to use autoincremental primary keys, other good options is to use UUID, but for sure it have caveats.

Francisco Puga
  • 23,869
  • 5
  • 48
  • 64