我正在使用 libpq C 库来测试 PG + BDR 副本集。我想确认 CRUD 操作的复制。我的目的是以毫秒或如果可能的话以微秒为单位制作我自己的复制时间日志。
程序：
启动 10-20 个线程独立连接，每个线程在三个表上进行 1000-5000 个基本 CRUD 操作周期。
哪个是最好的方法？
如果它们具有带有时间戳的正确数据或在我的 C api 中解析一些高详细日志，我应该在每个 CRUD 操作之后启动 N 个线程（N = {节点数} - {我连接到的主服务器}）。并查询数据的节点。
您无法轻松获得单个 xact 的重播确认。系统跟踪对等节点重放的日志序列号，但不跟踪对应的事务 ID，因为它不关心。
您似乎想要的是接近同步或半同步的复制。9.6 的一些工作有望及时使 BDR 受益，但这在未来很好。
同时，您可以在 中看到日志序列restart_lsn号pg_replication_slots。这不是副本重播到的位置，但它是崩溃后可能必须重新开始重播的最旧点。
您可以看到其他 LSN 字段，例如replay_location仅当副本连接到时pg_stat_replication。不幸的是，在 9.4 中没有简单的方法来查看哪个插槽pg_replication_slots与哪个活动连接相关联pg_stat_replication（在 9.5 中已修复，但 BDR 仍然基于 9.4）。因此，application_name如果您想挑选出单个节点，则必须使用 BDR 的集合，而且解析起来很“有趣”。也经常被截断。
您可以在提交 xact 后通过调用SELECT pg_current_xlog_location();which 将返回类似0/19E0F060或其他值的值来获取您提交 xact 的服务器的当前 LSN。然后，您可以在对等节点中查找该值，pg_stat_replication直到您看到replay_location您提交的节点已达到或通过您在提交后立即捕获的 LSN。
这并不完美。在您提交和捕获服务器的当前 LSN 之间可能还有其他工作要做。没有办法解决这个问题，但最坏的情况是你等待的时间太长了。如果您使用 BDR，则无论如何都不应该关心微秒甚至毫秒，因为它是一种异步复制解决方案。
这些原理与测量普通物理备用服务器的复制延迟非常相似，所以我建议阅读一些关于此的文档。除了这pg_last_xact_replay_timestamp()不适用于逻辑复制，因此您不能使用它来延迟，您必须使用 LSN 并在客户端进行自己的计时。