How to Optimize PostgreSQL Logical Replication

邏輯複製（ Logical Replication ）或 Pglogical 是表級別的複製。兩者都是基於 WAL 的複製機制，允許在兩個例項之間複製指定表的 WAL 。這兩個看起來讓人迷惑，到底有什麼區別呢？ Logical Replication 是 PostgreSQL10.0 引入的內建新特性，而 pglogical 則是一個外掛。 PG10 版本之前可以使用該外掛進行邏輯複製，透過持續發展， pglogical 的所有特性都整合到了 Logical Replication 中。換句話說， pglogical 外掛變成了 Logical Replication 。 Logical Replication 最基本的優勢在於不用安裝任何外掛，安裝外掛受限的環境中，可以推薦使用該邏輯複製。

本部落格關注最佳化 Logical Replication 。這意味著，最佳化方法可以同時應用於 pglogical 以及 Logical Replication 。

作為 DBA ，這種複製機制和其他基於觸發器的複製機制來說更加可靠，效能更改。邏輯複製的表，發生變化的資料透過 WAL 記錄可以實時複製，這樣更加高效並且也沒那麼複雜。所有其他複製機制都是基於觸發器的，這可能會帶來效能和維護方面的調整，隨著邏輯複製的出現，對基於觸發器複製的依賴幾乎消失了。

其他部落格詳細描述瞭如何配置邏輯複製： https://severalnines.com/blog/overview-logical-replication-postgresql ， 本部落格關注如何最佳化。

最佳化邏輯複製

首先， Logical Replication 的行為和流複製非常像，唯一不同的是流複製對整個 database 進行復制，而 Logical Replication 僅複製指定的表。使用邏輯複製時，需要預見一些挑戰。

下面我們看下影響邏輯複製的因素。

影響邏輯複製效能的因素

最佳化邏輯複製時保證無縫複製不會中斷非常重要，在搭建前需要注意幾個問題：

1） 複製表中資料型別

2） 複製表或者部分複製表上寫事務的頻繁性

3） 基礎設施的容量

4） 引數的配置必須最優

以上因素對邏輯複製有較大影響，下面我們詳細說明。

邏輯複製資料型別

理解邏輯複製表的資料型別非常重要。如果表儲存的是 large text 或二進位制物件，並且又遇到大規模事務，那麼由於基礎設施資源的限制，複製就會被拖慢。基礎設施的容量必須滿足處理如此規模的資料。

複製表的活躍性

在複製非常活躍的表時，可能由於 IO 效能問題、死鎖等導致複製落後於同步。這肯能使資料庫看起來不太健康。如果需要複製的表比較多並且資料需要複製到多個階段，那麼可能需要很高的 CPU 使用率，並需要更過的 CPU 。

基礎設施的容量

當使用邏輯複製時，首先需要考慮基礎設定的容量。如果需要複製大量表，那麼需要充足的 CPU 。

當需要複製大量表時，可以進行分組並使用並行複製。此時也需要多個 CPU 用於並行複製。如果資料變化比較頻繁，也會影響複製的效能。

最佳化配置引數

使用邏輯複製功能，需要調優配置引數：

wal_level= ’ logical ’

max_wal_senders=10            # greater than number of subscribers (or replicas)

max_replication_slots=10         # greater than number of subscribers (or replicas)

max_worker_processes=10        # greater than number of subscribers (or replicas)

max_logical_replication_workers    # greater than number of subscribers (or replicas)

max_sync_workers_per_subscription  # depends on number of tables being replicated

max_wal_senders

max_wal_senders 配置值需要大於備機個數。如果資料需要複製到多個節點，那麼 max_wal_senders 就開始起作用，因此這個引數調整到最優很重要。

max_replication_slots

通常，資料的變化會寫入到 WAL 檔案中，被稱為 WAL 記錄。 WAL sender 程式會將這些 WAL 日誌傳送到備機，備機的 wal receiver 程式接收這些 WAL ，然後訂閱節點回放這些 WAL 。

Checkpoint 後，可以將 pg_xlog/pg_wal 中不需要的 wal 檔案刪除。如果這些 WAL 沒有在訂閱節點回放完時，將這些主機上的檔案刪除，那麼複製就會中斷。提供複製槽，可以確保當訂閱節點還需要時，主機上的檔案不被刪除。建議對於每個訂閱節點都配置一個複製槽。

max_worker_processes

配置最優的 worker 程式數也很重要。這依賴於服務最大能夠擁有多少程式。在多 CPU 的環境中才會有效。 max_worker_processes 透過使用多個 CPU 核，促使程式以更快的方式完成任務。當使用邏輯複製時，這個引數可以幫助 worker 程式複製更快。還有一個 max_logical_worker_processes 引數，指定使用多少 worker 程式複製資料。

max_logical_worker_processes

這個引數指定最多需要多少 logical worker 程式複製資料。 max_logical_worker_processes 的程式隸屬於 max_worker_processes ，比 max_worker_processes 小。多 CPU 的環境，複製到多個訂閱節點，這個引數才有意義。預設值是 4 ，最大值依賴於系統支援最多 worker 程式數。

max_sync_workers_per_subscription

這個引數指定每個訂閱最多需要多少同步程式。初始資料同步期間，同步程式開始工作，使用整個從那時候可以確保同步更快。目前，一個表只能配置一個同步程式，這意味著多個表可以並行同步。預設值是 2 ，這個值隸屬於 max_logical_worker_processes 。

其他引數包括： wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval ，當然這幾個引數不會影響釋出節點。

結論

     在複雜的大規模資料庫系統中，複製指定表是常見的需求。邏輯複製可以用於業務報告和資料倉儲。作為一個 DBA ，我認為由於邏輯複製部署簡單，非常適合這樣的場景。配置調優邏輯複製，需要大量的計劃、架構、測試。為了確保複製系統的有效性和可用性，使用邏輯複製時需要評估實時複製的資料量。綜上所述， PG10 及其之後的版本可以使用邏輯複製，而之前的版本可以使用 pglogical 。

原文

https://severalnines.com/blog/how-optimize-postgresql-logical-replication