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