我们有一个在生产中运行的PostgreSQL服务器和一个具有独立开发环境的大量工作站.每个都有自己的本地PostgreSQL服务器(没有与生产服务器复制).开发人员需要定期接收存储在生产服务器中的更新.

我试图弄清楚如何从服务器转储几个选定的表的内容,以更新开发工作站上的表.最大的挑战是我试图同步的表可能会分歧(开发人员可能会通过Django ORM添加 – 但不会删除 – 表中的新字段,而生产数据库的模式在很长一段时间内保持不变).

因此,必须保留存储在工作站上的表的更新记录和新字段以防止覆盖.

我想直接转储(例如pg_dump -U remote_user -h remote_server -t table_to_copy source_db | psql target_db)不适用于此处.

UPD：如果可能的话,我还希望在将数据从生产数据库传输到工作站时避免使用第三个(中间)数据库.

最佳答案 我会推荐以下方法.

我将概述基于单个表客户的示例.

>我们希望从生产中复制此表中的一些条目.显然,全表转储会破坏开发环境中存在的新东西;
>因此,创建一个具有相似结构的表,但名称不同,比如customer_ $.另一种方法是为这种“复制”表创建专用模式.您可能还想在其中包含一些额外的列,例如copy_id和/或copy_stamp;
>现在您可以INSERT INTO customer_ $SELECT …用所需数据填充复制表.但是,您可能需要考虑如何执行此操作的方式.在我们使用的工具中,我们可以通过-w开关提供谓词数据,如-w“customer_id IN(SELECT id FROM cust2copy)”;
>填充复制表后,可以转储它们.确保使用以下开关到pg_dump：

> –column-inserts显式列出目标列,对于on development env复制表可能已经改变了它的结构.虽然这对于大卷来说可能“缓慢”;
> –table / -t指定要转储的表.

>在目标环境中,确保(1)清空复制表和(2)防止类似性质的并行活动;
>将日期加载到复制表中;
>最有趣的部分是：您需要检查,您要回到主表中的数据不会与表中定义的任何约束冲突.你可能有：

> PRIMARY KEY违规.您可以(1)替换现有条目或(2)将条目合并在一起或(3)从复制表中跳过条目或(4)选择在复制表中分配不同的ID;
> UNIQUE KEY违规,很可能你必须更新复制表中的一些列;
> FOREIGN KEY违规行为,您要么放弃这些条目,要么复制生产中缺失的东西;
>检查违规行为,您必须手动调查这些违规行为.

>完成检查并修复复制表中的数据后,可以将其复制到主表中.

这是对该方法的非常正式的描述.比方说,对于第7步,我们有大量额外的工具来进行ID或ID范围重映射,操作复制表中的数据,调整安全设置,所有权,某些默认值等.

此外,我们有一个所谓的此工具目录,它允许我们在通用名称下对逻辑上绑定的表进行分组.比如说,要从生产中复制客户,我们必须检查50个表,以满足所有可能的依赖关系.

到目前为止,我还没有在野外见过类似的工具.