48.3. 流復制協議 · PostgreSQL 中文文檔 9.3

# 48.3\. 流復制協議為了初始化流復制，前端需要發送帶`replication`參數的startup消息。這告訴后端進入walsender模式，在這個模式下可以發送數量不多的復制命令集而不是通常的SQL命令。并且在walsender模式下，只能使用簡單查詢協議。 walsender模式下可以接受的命令如下: IDENTIFY_SYSTEM 請求服務端標識自己。服務端會應答一個只有一行的結果集，包含3個字段。 systemid 標識數據庫集群的唯一的系統標識符。這個可以用于檢查初始化備機用的基礎備份來自同一個數據庫集群。 timeline 當前的時間線ID(TimelineID)。同樣可用于檢查備機和主機的一致性。 xlogpos 當前的xlog的寫入位置。可用于獲得在事務日志中流從哪而開始的已知的位置信息。 TIMELINE_HISTORY `_tli_` 請求服務端為時間線`_tli_`發送時間線歷史文件。服務端會應答一個只有一行的結果集，包含3個字段。 filename 時間線歷史文件的文件名，比如00000002.history。 content 時間線歷史文件的內容。 START_REPLICATION `_XXX/XXX_` TIMELINE `_tli_` 指示服務端從時間線`_tli_`上的WAL位置`_XXX/XXX_`開始WAL流。服務端可能會回應一個錯誤，比如，如果在請求的WAL段已經被回收的情況下。如果成功，服務端響應一個CopyBothResponse消息，然后開啟到前端的WAL流。如果客戶端請求的時間線不是最新的，但是是服務端歷史的一部分，服務端將會傳送從請求的開始點開始直到服務端切換到另一個時間線為止這個時間線上的所有WAL。如果客戶端請求的流正好在舊時間線的終點上，服務端會立即響應一個CommandComplete而不進入COPY模式。傳送完這個非最新的時間線上的所有WAL后，服務端退出COPY模式結束流。當客戶端也以退出COPY模式作為應答，服務端發送一個只有一行的結果集，包含2的字段，指示在這個服務器上的下一個時間線。第一列是下一個時間線的ID，第二列是發生切換的XLOG位置。通常切換點是已經傳送的WAL流的終點，但是在極端的情況下，服務端發送的WAL可能來自自己升級前還沒有回放的舊的時間線。最終服務端發送CommandComplete消息并準備接收新的命令。 WAL數據作為一系列的CopyData消息發送。（這允許混合其它信息，具體而言服務端在開始流之后發生了失敗可以發送ErrorResponse消息。）每個從服務端到客戶端的CopyData消息的裝載數據中包含下面的格式的消息： XLogData (B) Byte1('w') 標識消息是一個WAL數據。 Int64 消息內的WAL數據開始點。 Int64 當前服務端上的WAL終點。 Int64 傳送時服務端上的系統時間，是從2000-01-01午夜開始的微秒數。 Byte`_n_` WAL數據流的片段。單個的WAL記錄一定不會被分割成2個XLogData消息。當一個WAL記錄跨越WAL頁的邊界，并且因此已經被連續的記錄分割了，可以在頁邊界上分割。換句話說，第一個主要的WAL記錄和它后續的記錄可能以不同XLogData消息傳送。主keepalive消息 (B) Byte1('k') 標識這是一個發送者的keepalive消息。 Int64 服務端上當前的WAL終點。 Int64 傳送時服務端上的系統時間，是從2000-01-01午夜開始的微秒數。 Byte1 1意味著客戶端應該盡可能快的應答這個消息，以防止超時切斷連接。0的意思相反。接受進程可以在任何時間使用以下消息格式(同樣作為CopyData消息的裝載數據)應答發送者：備機狀態更新(F) Byte1('r') 標識這是一個接受者的狀態更新消息。 Int64 備機上接受并寫入磁盤的上次的WAL字節+1的位置。 Int64 備機上刷新到磁盤的上次的WAL字節+1的位置。 Int64 備機上已經應用的上次的WAL字節+1的位置。 Int64 傳送時客戶端上的系統時間，是從2000-01-01午夜開始的微秒數。 Byte1 如果是1，客戶端請求服務端立即應答這個消息。這用于ping服務端以測試連接是否還健康。熱備機的反饋消息(F) Byte1('h') 標識這是一個熱備機的反饋消息。 Int64 傳送時客戶端上的系統時間，是從2000-01-01午夜開始的微秒數。 Int32 備機上現在的xmin。如果備機正在傳送熱備機反饋將不再發到這個連接上的通知，這個值可能為0。之后非零的消息可能再初始化反饋機制。 Int32 備機的當前時間戳。 BASE_BACKUP [`LABEL` `_'label'_`] [`PROGRESS`] [`FAST`] [`WAL`] [`NOWAIT`] 指示服務器開始一個基礎備份的流。系統將在備份開始前自動進入備份模式，并且在備份完成后回到原來的狀態。可以接受以下選項: `LABEL` `_'label'_` 設定備份的標簽。如果沒有指定，則使用`base backup`。標簽的引號使用規則與[standard_conforming_strings](#calibre_link-1031)開關打開時的標準SQL字符串相同。 `PROGRESS` 請求產生進度報告時要用的信息。這將在每個表空間的頭部發回一個近似的大小，用于計算到流結束還有多少距離。這個大小是在傳輸前通過一次性統計所有文件的大小獲取的，可能會產生性能上的沖擊 - 實際上在傳送第一個流前可能會花比較長的時間。既然數據庫文件可能在備份過程中改變，這個大小只是近似的，并且在估算和實際發送文件之間可能增長和收縮。 `FAST` 請求一個快速的檢查點(checkpoint)。 `WAL` 包含這個備份所必要的WAL段。將包括在備份開始和結束期間`pg_xlog`目錄下的所有base目錄tar文件。 `NOWAIT` 缺省時備份會等待最后一個需要的xlog段被歸檔，或者在沒有啟用歸檔的情況下發出一個警告。指定`NOWAIT`可以把等待和警告無效，讓客戶端負責確認需要的日志是否有效。備份開始時，服務端首先發送2個通常的結果集，然后是1個以上的CopyResponse結果。最初的通常的結果集里，包含由2列構成的單一行的備份位置。第一個列是XLogRecPtr形式的開始位置，第二列是對應的時間線ID。第二個通常的結果集里各個表空間一行數據。每行包含的字段如下: spcoid 表空間的oid。 base目錄的情況下則為`NULL`。 spclocation 表空間目錄的完全路徑。base目錄的情況下則為`NULL`。 size 要求進度狀況報告的情況下，表空間的估算容量。沒有要求的情況下為`NULL`。第二個通常結果集之后被送過來的是一個以上的CopyResponse結果。一個是PGDATA用的，其余的則是每個`pg_default`、`pg_global`以外的追加表空間都有一個。 CopyResponse結果內的數據是表空間內容的tar形式（遵照POSIX 1003.1-2008規定的"ustar交換形式"）的轉儲(dump)。但是，標準規定的最后的2個零數據塊被省掉了。 tar數據結束后，和開始位置的形式相同，是包含備份終了位置的最終的結果集。為data目錄和每個表空間做的tar歸檔包含目錄下的所有文件，不管它們是PostgreSQL 的文件還是相同目錄下的其它在文件。但是以下文件被排除在外: * `postmaster.pid` * `postmaster.opts` * `pg_xlog`，包含子目錄。如果備份是包含WAL執行的，將包含一個合成版的`pg_xlog`。它只包含對于備份工作必須的文件而沒有其余的內容。如果服務器的文件系統支持的話，所有者，組和文件模式會被設置。所有的表空間被傳送完后，發送最終的通常結果集。這個結果集里包含單一行單一列的XLogRecPtr格式的備份結束位置。