我有两个postgres数据库，必须在这些数据库之间同步相同的表（不是所有数据库，只是其中的几个）。
这会产生同步问题，如果我有表A和表B（相同的结构，只是在不同的数据库中），如果有人插入表A，pk id可能是5，但是，有人可能会在表上插入B，得到的PK也是5。
在同步两个表时，我可能会发现两个具有相同pk但具有不同内容的寄存器。
我很确定必须有解决方案，必须有一种智能方法来保持ID同步。
到目前为止，我一直在考虑创建一个简单的web服务，它将提供一个新的有效pk id，但这是有问题的，因为
1 - 它会减慢这个过程 2 - 它只是将问题移到web服务，web服务将如何找到哪个是下一个有效的id？
过去有没有人遇到过类似的问题？
环境是postgres 9.1
答案 0 :(得分：2)
是的，人们已经面对这么多了。你需要问的问题不是“我该怎么做”，而是“哪种现有的易于理解和已建立的方法最符合我的需要”。
查看用于在分片和分布式数据库中生成密钥的解决方案。
选项包括：
为每台计算机分配不重叠的ID范围。一种常见的方法是将序列设置为以（例如）100的块递增并为每台机器提供唯一的偏移，因此机器A生成101,201,301,401等，并且机器B生成102,202,302,402 ，......在您需要添加＃101机器之前，很好。您可以使用bigint键并为10,000台机器留出空间;当你达到这个限制时，无论如何你将重新设计整个系统三次。
（在您说“我将用完钥匙”之前... ...最大bigint是9223372036854775807所以在10,000机器范围内，您正在查看大约10 15 或2每台每台机器上有 50 个密钥，大约是一个21 PB的表，每个记录25个字节，包括开销，即真正非常小的记录）。
使用像(machine_id, locally_generated_sequence_id)这样的复合主键。除非你正在处理坚持使用单值主键的脑死亡ORM，否则这是理想的。
将huge random primary keys (UUIDs)与uuid数据类型一起使用，提供128位空间和极小的碰撞概率。在大多数情况下工作正常，尽管birthday paradox碰撞是非常不寻常的。偏执狂可以制定计划来应对碰撞。
使用公共服务生成大块密钥。不经常调用它并在本地存储可用的密钥。由于密钥表上的锁争用，这往往会妨碍每个节点上的并发写入性能，所以我不推荐它。
...可能更多我没有记住或从未听说过。
最简单的选择通常是分配不重叠的ID。这很容易，它是透明的，它只是起作用。