简体繁体 English

如何在 Bucardo Postgresql multi master 中处理序列

[英]How to handle sequences in Bucardo Postgresql multi master

原文 2015-06-10 09:47:41 9 1 postgresql/ replication/ database-replication/ bucardo

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.我们正在三个不同的 Postgresql 服务器上建立一个数据库（将来可能会更多），目前使用 bucardo 多主组同步所有表。

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.我们试过了，我们注意到 bucardo 使我们在同一表、不同服务器上同时写入时丢失数据。 Since they use the same keys, on sync time bucardo chooses to drop one of the duplicate rows.由于它们使用相同的键，因此在同步时间 bucardo 选择删除重复行之一。

Our current approach is to manually namespace the sequence on each instance of the database.我们当前的方法是手动命名数据库的每个实例上的序列。 Eg 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.例如，实例 1 保持原样，所有实例 2 表序列都更新为从 2^31/10 开始，实例 3 表序列将更改为从 2^31/10*2 开始 .. instance10 序列从 2^31 开始/10*9。

What is your opinion on this approach and what other advice do you have for a Bucardo multi-master setup?您对这种方法有何看法？您对 Bucardo 多主设置还有哪些其他建议？ Postgresql BDR is not an option as it is not considered a stable release yet. Postgresql BDR 不是一个选项，因为它尚未被视为稳定版本。

1 个解决方案

Sequences must not be replicated in a multi-source setup with Bucardo as conflicts will arise.不得在使用 Bucardo 的多源设置中复制序列，因为会出现冲突。

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.如果最多有九个来源，对我来说很容易推断数据将自动增量值设置为 10，并以不同的数字启动每个数据库，1、2，...所以，“第一个数据库”将生成 1 , 11, 21, ... second 2, 12, 22, ... 这种方法的一个好处是，如果您从四个源开始并且需要另一个源，则不应更改任何内容。 In your suggested strategy if you split all available space between 4 databases, and need another one split again the space is more difficult.在您建议的策略中，如果您在 4 个数据库之间拆分所有可用空间，并且需要再次拆分另一个空间，则空间会更加困难。

If you are not limited to use autoincremental primary keys, other good options is to use UUID, but for sure it have caveats .如果您不限于使用自动增量主键，其他好的选择是使用 UUID，但它肯定有警告。