通过触发器或复制或外部数据包装器将数据从多个数据库插入到远程数据库表中

Question

我需要一些关于以下场景的建议。

我有多个支持 PostgreSQL 数据库的嵌入式系统在不同的地方运行，并且我们有一个在 CentOS 上运行的服务器。

每个系统都在远程位置运行，并且在其数据库中有多个表。这些表与服务器的表名相同，但每个系统的表名都与其他系统不同，例如：

系统 1 有表：

• sys1_table1
• sys1_table2

系统 2 有表

• sys2_table1
• sys2_table2

我想在系统 1 和系统 2 上执行的每次插入操作时更新服务器上的表 sys1_table1、sys1_table2、sys2_table1 和 sys2_table2。

一种解决方案是在每个表上编写一个触发器，该触发器将在两个系统表的每次插入时运行，并在服务器的表中插入相同的数据。将数据插入服务器后，此触发器还将删除系统中的记录。此解决方案的问题在于，如果由于网络问题而未建立与服务器的连接，则该触发器将不会执行，否则插入将被浪费。我已经为此检查了以下解决方案 Trigger to insert rows in remote database after deletion

第二种解决方案是将表从系统 1 和系统 2 复制到服务器的表。复制的问题在于，如果我们从系统中删除数据，它也会删除服务器上的记录。我可以在服务器表上添加备用触发器，该触发器将在重复表上更新，因此复制表可能会变空并且不会影响数据，但如果我们有超过 200 个系统，它将生成一个长表列表.

第三种方案是用postgres_fdw或者dblink写一个外表，更新服务器表里面的数据，但是我们删除系统表里面的数据会不会影响到服务器里面的数据，对吧？如果与服务器没有连接会发生什么？

第四个解决方案是在每个系统中用python编写一个应用程序，它将连接到服务器的数据库并实时写入数据，如果没有连接到服务器，它将把数据存储在@987654330中@ 或sys2.table2 或数据所属的任何表，重新连接后，代码会将表数据发送到服务器的表中。

根据这种情况，哪个选项最好？我最喜欢触发解决方案，但是有没有办法避免在与服务器断开连接的情况下丢失数据？

Answer 1

我会采用第四种解决方案，或者可能采用第三种解决方案，只要它是从数据库外部触发的。这样您就可以轻松应对连接中断。

第一个带有触发器的解决方案存在您已经检测到的问题。在数据库事务中开始潜在的长时间操作也是一个坏主意，例如跨质量不确定的网络的数据复制。长事务意味着长锁和低效的自动清理。

如果您有支持logical replication 的最新 PostgreSQL 版本，第二个解决方案实际上也可能是一个选项。您可以使用publicationWITH (publish = 'insert,update')，这样DELETE 和TRUNCATE 就不会被复制。复制可以很好地处理丢失的连接（一段时间），但如果您希望在复制后删除源中的数据，则不能选择。