PostgreSQL + BDR中的複製確認

Question

我正在使用libpq C庫來測試PG + BDR副本集。我希望得到CRUD操作複製的確認。我的目的是以毫秒爲單位創建自己的複製時間日誌，或者如果可能的話，以毫秒爲單位。

程序：
啓動10-20個線程獨立連接，每個線程在三個表上執行1000-5000個基本CRUD操作週期。

這將是最好的方式？
解析一些高度冗長的日誌，如果他們有適當的數據與時間戳或在我的C API我應該開始N線程（N = {節點數量} {{我連接到主人}）在每個CRUD操作。並查詢數據的節點。

Answer 1

您無法輕鬆獲得單個xacts的重播確認。系統跟蹤對等節點重播的日誌序列號，但不記錄那些對應的事務ID，因爲它不關心。

你似乎想要的是近似同步或半同步複製。有一些工作要達到9.6，希望能夠及時使BDR受益，但這在未來會很好。

與此同時，您可以在pg_replication_slots中看到日誌序列號爲restart_lsn。這不是副本重播的位置，但它是在崩潰後重啓重播的最老點。

只有在pg_stat_replication中連接了副本時，才能看到其他LSN字段，如replay_location。不幸的是，在9.4中，沒有簡單的方法可以看到pg_replication_slots中的哪個插槽與pg_stat_replication（固定爲9.5，但BDR基於9.4仍）的哪個活動連接相關聯。所以如果你想挑選出單獨的節點，你必須使用由BDR設置的application_name，並且它是......「有趣」的解析。也經常被截斷。

你可以通過調用SELECT pg_current_xlog_location();將返回像0/19E0F060或任何一個值犯下的XACT提交它後，服務器的當前LSN。然後，您可以在對等節點的pg_stat_replication中查看該值，直到您看到您提交的節點的replay_location已達到或通過提交後立即捕獲的LSN。

這並不完美。當你提交和捕獲服務器當前的LSN時，可能還有其他工作要做。這是沒有辦法的，但最糟糕的是你稍等一會兒。如果你使用BDR，你不應該關心微秒甚至毫秒，因爲它是一個異步複製解決方案。

原理與測量正常物理備用服務器的複製延遲非常相似，所以我建議閱讀一些文檔。除了pg_last_xact_replay_timestamp()不適用於邏輯複製，所以你不能使用它的滯後，你必須使用LSN，並做你自己的時間客戶端。