流復制和邏輯復制的區別

Question

有人能告訴我更多關於 PostgreSQL 中物理復制和邏輯復制之間的區別嗎？

Answer 1

TL;DR ：邏輯復制發送逐行更改，物理復制發送磁盤塊更改。 邏輯復制更適合某些任務，物理復制更適合其他任務。

請注意，在 PostgreSQL 12（更新時的當前版本）中，邏輯復制穩定可靠，但非常有限。 如果您要問這個問題，請使用物理復制。

---

流式復制可以是邏輯復制。 這一切都有些復雜。

WAL 運輸與流媒體

在 PostgreSQL 中有兩種主要的方式將數據從 master 發送到 replica：

• WAL-shipping或連續歸檔，其中單獨的預寫日志文件通過運行在 master 上的archive_command從pg_xlog復制到其他位置。 在副本的recovery.conf配置的restore_command在副本上運行以獲取存檔，以便副本可以重放 WAL。

  這是用於時間點復制(PITR) 的內容，用作連續備份的方法。

  不需要到主服務器的直接網絡連接。 復制可能會有很長的延遲，尤其是在沒有設置archive_timeout情況下。 WAL 傳送不能用於同步復制。

• 流式復制，其中每個更改都會在發生時直接通過 TCP/IP 連接發送到一個或多個副本服務器。 副本必須具有主服務器在其recovery.conf的primary_conninfo選項中配置的直接網絡連接。

  只要副本足夠快以跟上，流式復制幾乎沒有延遲。 它可用於同步復制。 您不能對 PITR ¹使用流復制，因此它對連續備份沒有多大用處。 如果你在主服務器上刪除一個表，糟糕，它也會被刪除到副本上。

因此，這兩種方法具有不同的目的。

異步與同步流

最重要的是，還有同步和異步流復制：

• 在異步流復制中，當 master 更快/更忙時，允許副本及時落后於 master。 如果 master 崩潰，您可能會丟失尚未復制的數據。

  如果異步副本落后於主副本太遠，如果max_wal_size （以前稱為wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's ，主副本可能會丟棄副本所需的信息wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's如果max_wal_size太高或使用了插槽，則wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's pg_wal (was pg_xlog）可能會填滿並停止 master 的工作，直到磁盤空間被釋放為止。

• 在同步復制中，在副本確認收到事務²之前，主節點不會完成提交。 如果 master 崩潰並且您必須故障轉移到副本，您永遠不會丟失數據。 主節點永遠不會因為副本延遲而丟棄副本所需的數據或填滿其 xlog 並耗盡磁盤空間。 作為交換，如果副本出現問題，它會導致主節點變慢甚至停止工作，並且由於網絡延遲，它總是對主節點產生一些性能影響。

  當有多個副本時，一次只有一個是同步的。 請參閱synchronous_standby_names 。

您不能進行同步日志傳送。

您實際上可以將日志傳送和異步復制結合起來，以防止在落后太多時必須重新創建副本，而不會影響主服務器。 這是許多部署的理想配置，結合監控副本在主服務器后面的距離以確保其在可接受的災難恢復限制范圍內。

邏輯與物理

最重要的是，我們有邏輯與物理流復制，如 PostgreSQL 9.4 中所介紹的：

• 在物理流復制中，更改幾乎是在磁盤塊級別發送的，例如“在關系 12311 的磁盤頁 18 的偏移量 14 處，寫入了十六進制值為 0x2342beef1222....”的元組。

  物理復制發送一切：PostgreSQL 安裝中每個數據庫的內容，每個數據庫中的所有表。 它發送索引條目，在您VACUUM FULL時發送整個新表數據，發送回滾事務的數據等。因此它會產生大量“噪音”並發送大量多余數據。 它還要求副本完全相同，因此您不能執行任何需要事務的操作，例如創建臨時表或未記錄的表。 查詢副本會延遲復制，因此需要取消對副本的長時間查詢。

作為交換，在副本上應用更改既簡單又高效，並且副本與主副本可靠地完全相同。 DDL 是透明復制的，就像其他一切一樣，因此不需要特殊處理。 它還可以在大事務發生時流式傳輸，因此即使發生大的更改，在 master 上提交和在副本上提交之間也幾乎沒有延遲。

物理復制已經成熟、經過充分測試並被廣泛采用。

• 邏輯流復制是 9.4 中的新增功能，可以在更高級別和更有選擇性地發送更改。

它一次只復制一個數據庫。 它只發送行更改，並且只發送已提交的事務，而不必發送真空數據​​、索引更改等。它可以選擇性地只發送數據庫中某些表的數據。 這使得邏輯復制的帶寬效率更高。

在更高級別上操作還意味着您可以在副本數據庫上執行事務。 您可以創建臨時表和未記錄的表。 如果你願意，即使是普通的桌子。 您可以使用任何您喜歡的外部數據包裝器、視圖、創建函數。 如果查詢運行時間過長，也無需取消查詢。

邏輯復制也可以用於在 PostgreSQL 中構建多主復制，這是使用物理復制無法實現的。

但是，作為交換，它（目前）不能在發生大交易時進行流式傳輸。 它必須等到他們提交。 因此，在 master 上提交的大事務和應用於副本之間可能會有很長的延遲。

它嚴格按照提交順序重放事務，因此小的快速事務可能會卡在大事務后面並延遲很長時間。

DDL 不會自動處理。 您必須自己保持主表和副本之間的表定義同步，或者使用邏輯復制的應用程序必須有自己的工具來做到這一點。 要做到這一點可能很復雜。

應用過程本身也比“在我被告知的地方寫一些字節”更復雜。 與物理復制相比，它在副本上占用的資源也更多。

當前的邏輯復制實現並不成熟或廣泛采用，或者特別容易使用。

選擇太多，告訴我該怎么做

呼。 很復雜吧？ 我什至還沒有深入了解延遲復制、插槽、 max_wal_size 、時間線、推廣工作原理、Postgres-XL、BDR 和多主等的細節。

那么你應該怎么做？

沒有唯一的正確答案。 否則 PostgreSQL 將只支持這種方式。 但是有一些常見的用例：

對於備份和災難恢復，請使用pgbarman進行基本備份並為您保留 WAL，從而提供易於管理的連續備份。 您仍然應該將定期pg_dump備份作為額外的保險。

為了實現零數據丟失風險的高可用性，請使用流式同步復制。

為了獲得低數據丟失風險和更好性能的高可用性，您應該使用異步流復制。 要么為回退啟用 WAL 歸檔，要么使用復制槽。 使用 Icinga 等外部工具監控副本落后於主副本的距離。

參考

• 連續歸檔和 PITR
• 高可用性、負載平衡和復制
• 復制設置
• 恢復配置文件
• 酒保
• 代表
• wiki：復制、集群和連接池