背景
我们有一个应用程序，将写入在法兰克福数据中心托pipe的postgres数据库。 该应用程序被安装在我们在世界各地的8个站点，从中国，韩国，印度，德国，法国和墨西哥。
在欧洲连接到法兰克福数据库时，响应时间很好。 但从中国北方接通时，反应时间平平缓慢。 中国伟大的防火墙正在延迟响应时间，并补充说，距离是决定性的因素。
我们决定在韩国为亚洲网站build立第二个数据库。 韩国和中国的网站上的应用程序将喂养韩国的数据库。 它极大地缩短了延迟，并像魅力一样工作。
问题是没有办法在韩文数据库和德文数据库之间复制数据，因为不允许双向复制。
现在我们已经回到原点了，因为我们不确定要采取哪些步骤，因为我们只需要一个数据库，但是我们需要相当的响应时间。 我们不想重写应用程序。
问题：
不知道这是否正确的地方问这个问题。 如果不是，请留下评论，我将删除该问题。
距离和干扰中间件都会增加延迟，这是没有避免的。
可能有其他位置托pipe数据库可接受的延迟妥协。 尽pipe这么多的延迟会伤害响应时间。 继续testing。
我明白PostgreSQL存在多主复制解决scheme。 这不会在您当前的软件中，并可能不会包含在云产品中。 这将从一个有经验的DBA中受益，比一个例子更复杂和风险更大。
或者移动客户端。 通过远程桌面或本地VDI托pipe数据库。 可能当查询的加载时间大大改善时，接口缓慢是可以容忍的。
最后，改变应用程序，尽pipe如此没有吸引力。 至lessconfiguration查询的数量，以便知道networking时间的数量。 减less这些可能会赢。 更困难的是重新考虑devise，可能从副本读取查询，但写入主要。