18.5. 預寫式日志 · PostgreSQL 中文文檔 9.3

# 18.5\. 預寫式日志參閱[Section 29.4](#calibre_link-1297)獲取調整這些設置的額外信息。 ## 18.5.1\. 設置 `wal_level` (`enum`) `wal_level`決定有多少信息被寫入到WAL中。默認值是`最小的`，其中寫入唯一從崩潰或立即關機中恢復的所需信息。 `archive`補充WAL歸檔需要的日志記錄，以及 `hot_standby`進一步增加在備用服務器上運行只讀查詢所需的信息。這個參數只能在服務器啟動時設置。在`最小`級別中，安全地忽略一些批量操作的WAL-日志，這可以使那些操作快很多（參閱[Section 14.4.7](#calibre_link-1197)）。這種優化可以應用到： | `CREATE TABLE AS` | |:--- | | `CREATE INDEX` | | `CLUSTER` | | `COPY` into tables that were created or truncated in the same transaction | 但是最小的WAL不包含從基本的備份和WAL日志中重建數據的足夠信息，所以`archive`或者`hot_standby`級別必須用來啟動 WAL歸檔([archive_mode](#calibre_link-1038))和流復制。在`hot_standby`級別，相同的信息被記錄為`archive`，加上需要重建從WAL運行的事務狀態信息。為了在備用服務器上啟用只讀查詢，主庫上`wal_level`必須設置為`hot_standby`，必須啟動備庫上的[hot_standby](#calibre_link-1134)。使用`hot_standby`和`archive`級別之間的性能幾乎沒有可測量的差異，如果任何生產的影響是明顯的，則是值得歡迎的。 `fsync` (`boolean`) 如果打開這個選項，那么PostgreSQL服務器將在好幾個地方使用`fsync()`系統調用 (或等價調用，參見[wal_sync_method](#calibre_link-1432))來確保更新已經物理上寫到磁盤中。這樣就保證了數據庫集群將在操作系統或者硬件崩潰的情況下恢復到一個一致的狀態。當關閉`fsync`時通常是性能利益，這可能會導致發生斷電或系統崩潰時不可恢復數據丟失。如果你可以很容易的從外部數據中創建您的整個數據庫，因此關閉`fsync`是明智的。關閉`fsync`安全情況的例子包括備份文件中新的數據庫集群的初始加載，數據庫被丟棄和重新創建之后，使用數據庫集群批處理數據，或者為只讀數據庫克隆被頻繁重建并且不用于故障轉移。為了關閉`fsync`高質量硬件本身是不充分的。當改變`fsync`從關閉到打開時，對于可靠的恢復，必須強制內核中所有被修改的緩沖區到持久存儲。當集群宕機或當fsync通過運行`initdb--sync-only`，`sync`，卸載文件系統，或重新啟動服務器的時候，再完成這項工作。在許多情況下，關閉[synchronous_commit](#calibre_link-1216) 為非關鍵的事務可以提供關閉`fsync`的潛力性能優勢，沒有數據損壞隨之而來的風險。 `fsync`只能在postgresql.conf文件里或者服務器命令行里設置。如果這個參數被關閉，那么請考慮把[full_page_writes](#calibre_link-1135)也關閉了。 `synchronous_commit` (`enum`) 命令返回"成功"指示給客戶端之前，指定是否事務提交將等待WAL記錄被寫入到磁盤。有效值是`on`,`remote_write`, `local`和`off`。默認情況下，安全設置是`on`。當`off`時，當成功報告給客戶端，并當該事務真正保證是安全的，不會在服務器崩潰的時候，可以有一定的延時（最大延遲[wal_writer_delay](#calibre_link-1433)的3倍）。不同于[fsync](#calibre_link-1214)，將此參數設置為`off`不會產生任何數據庫不一致的風險：操作系統或數據庫崩潰可能導致丟失一些最近提交的事務，但數據庫狀態將是一樣的，正如該事務已經徹底終止。因此，當性能比準確事務耐久性更重要時，關閉`synchronous_commit`是有效選擇。獲取更多討論請參閱[Section 29.3](#calibre_link-1296)。如果設置[synchronous_standby_names](#calibre_link-1434)，該參數控制是否事務提交將等待它的WAL記錄被復制到備用服務器。當設置`on`的時候，提交將等待直到回復當前同步備庫表明它已收到事務提交記錄，并刷新到磁盤。這確保事務不會丟失，除非主庫和備庫遭受他們的數據庫存儲崩潰。當設置為`remote_write`，事務將等待直到當前同步備庫的答復表明它已經收到事務的提交記錄，并且寫入到備用操作系統，但是數據并不一定在備庫中達到穩定存儲。即使PostgreSQL備庫實例崩潰，但并非備庫遭受操作系統級的崩潰，此設置足以確保數據的保存。當同步復制使用時，通常是明智的，要么等待本地刷新到磁盤和WAL記錄的復制，要么允許異步提交事務。然而，該設置`local`可用于希望等待本地刷新到磁盤上的事務，而不是同步復制。如果不設置`synchronous_standby_names`，設置`on`, `remote_write`和`local` 提供相同的同步級別：事務提交只能等待本地刷新到磁盤。該參數可以在任何時候被改變;對于任何事務的行為是由該設置提交生效時確定的。因此，它是可能的，并且有用的，有一些事務同步提交，其他的異步提交。例如，為了使單一多語句事務異步提交，缺省是相反的，在事務中發出`SET LOCAL synchronous_commit TO OFF`命令。 `wal_sync_method` (`enum`) 用來向磁盤強制更新WAL數據的方法。如果`fsync`是關閉的，那么這個設置就沒有意義，因為所有WAL文件更新都不會強制輸出。可能的值是： * `open_datasync` (用帶 `O_DSYNC`選項的`open()`打開WAL文件) * `fdatasync`(每次提交的時候都調用`fdatasync()`) * `fsync` (每次提交的時候都調用`fsync()`) * `fsync_writethrough` (每次提交的時候調用`fsync()`強制寫出任何磁盤寫緩沖區) * `open_sync`(用帶`O_SYNC`選項的`open()`寫WAL文件) 如果可用的話，該`open_`*選項也使用`O_DIRECT`。并非所有這些選擇在所有平臺上都可用。默認值是平臺支持的上面列表中的第一個方法，除了`fdatasync`在Linux上是缺省的。缺省的也不一定理想; 為了創建安全配置或達到最佳性能，可能要改變這個設置或你的系統配置的其他方面，將在[Section 29.1](#calibre_link-1294)中討論。這個參數只能在`postgresql.conf`文件或服務器命令行上設置。 `full_page_writes` (`boolean`) 打開這個選項的時候，PostgreSQL服務器在檢查點之后對頁面的第一次寫入時將整個頁面寫到 WAL 里面。這么做是因為在操作系統崩潰過程中可能只有部分頁面寫入磁盤，從而導致在同一個頁面中包含新舊數據的混合。在崩潰后的恢復期間，由于在WAL里面存儲的行變化信息不夠完整，因此無法完全恢復該頁。把完整的頁面影像保存下來就可以保證正確存儲頁面，代價是增加了寫入WAL的數據量。因為WAL重放總是從一個檢查點開始的，所以在檢查點后每個頁面第一次改變的時候做WAL備份就足夠了。因此，一個減小全頁面寫開銷的方法是增加檢查點的間隔參數值。把這個選項關閉會加快正常操作的速度，但是可能導致系統崩潰后不可恢復的數據損壞或者無記載數據損壞，它的危害類似于`fsync`，只是比較小而已。并且在建議參數相同的情況下關閉這個選項。關閉這個選項并不影響即時恢復(PITR)的WAL使用(參閱[Section 24.3](#calibre_link-466))。這個選項只能在`postgresql.conf`文件里或者服務器命令行設置。缺省是`on`。 `wal_buffers` (`integer`) 使用已經寫入磁盤的WAL數據共享內存的數量。-1的默認設置選擇大小等于 [shared_buffers](#calibre_link-1370)的1/32nd(大約3%)，但不小于`64kB`也不超過一個WAL段大小，通常`16MB`。如果自動選擇過大或過小，則可以手動設置這個值。但任何小于`32kB`的正值將當作`32kB`處理。這個參數只能在服務器啟動時設置。 WAL緩沖區的內容每次事務提交時寫入到磁盤，這樣非常大的值不可能提供顯著的好處。但是，當有許多客戶端都同時提交時，設置該值至少為幾兆可以提高繁忙服務器的寫入性能，在多數情況下，由-1的缺省設置選擇自動調整應給予合理的結果。 `wal_writer_delay` (`integer`) 聲明WAL寫入進程的活動輪回的延遲。在每一輪回中寫入進程將刷新WAL到磁盤。然后，它會休眠`wal_writer_delay`毫秒，并重復。默認值是200毫秒(`200ms`)。注意，在許多系統上，睡眠延遲的有效分辨率為10毫秒; 把`wal_writer_delay`的值設置為一個不是10的倍數的數值與設置為下一個10的倍數是一樣的效果。這個參數只能在`postgresql.conf`文件或服務器命令行上設置。 `commit_delay` (`integer`) `commit_delay`增加了時間延遲，在WAL刷新啟動之前，以微秒測量。這可以提高通過單一WAL刷新提交大量事務的組提交吞吐量。如果系統負載足夠高，額外事務在給定時間間隔內成為提交。然而，它也增加了每個WAL刷新的最多`commit_delay`微秒的延遲時間。但是如果沒有其它事務準備提交，那么這個間隔就是在浪費時間。如果至少`commit_siblings`個其它事務是活躍的，當刷新初始化的情況下。則僅僅只執行一個延遲。如果禁用`fsync`，則不執行任何延遲。缺省`commit_delay`是零（無延遲）。只有超級用戶可以更改此設置。在PostgreSQL先于9.3發布的版本中， `commit_delay`表現不同，更別說效能：它僅影響提交，而不是所有的WAL刷新，即使WAL刷新盡早完成了，也要等待整個配置延遲。在PostgreSQL9.3開始，第一個過程準備刷新等待配置延遲，而隨后的過程僅僅等待直到完成刷新操作。 `commit_siblings` (`integer`) 在執行`commit_delay`延遲的時候，要求最少同時打開的并發事務數目。大一些的數值會導致在延遲期間另外一個事務準備好提交的可能性增大。缺省是5。 ## 18.5.2\. 檢查點 `checkpoint_segments` (`integer`) 在自動的WAL檢查點之間的日志文件段的最大數量(通常每個段16兆字節)。缺省是3。增加這個參數可以增加崩潰恢復所需要的時間量。這個選項只能在`postgresql.conf`文件里或者服務器命令行中設置。 `checkpoint_timeout` (`integer`) 在自動WAL檢查點之間的最長時間，以秒計。缺省是5分鐘(`5min`)。增加這個參數可以增加崩潰恢復所需要的時間量。這個選項只能在`postgresql.conf`文件或者服務器命令行中設置。 `checkpoint_completion_target` (`floating point`) 聲明檢查點完成的目標，作為檢查點之間總時間的分數。缺省是0.5。這個參數只能在`postgresql.conf`文件中或者服務器命令行中設置。 `checkpoint_warning` (`integer`) 如果由于填充檢查點段文件導致的檢查點發生時間間隔接近這個參數表示的秒數，那么就向服務器日志發送一個建議增加`checkpoint_segments`值的消息。缺省是30秒(`30s`)。零則關閉警告。如果`checkpoint_timeout`小于`checkpoint_warning`，則不產生警告。這個選項只能在`postgresql.conf`文件里或者服務器命令行中設置。 ## 18.5.3\. 歸檔 `archive_mode` (`boolean`) 當啟用`archive_mode`的時候，已完成的WAL段通過設置[archive_command](#calibre_link-467) 發送到歸檔存儲。 `archive_mode`和`archive_command`是獨立變量，以致于`archive_command`不留歸檔模式而被改變。這個參數只能在服務器啟動時設置。當`wal_level`設置為`minimal`時，則不啟用`archive_mode`。 `archive_command` (`string`) 將一個完整的WAL文件序列歸檔的shell命令。字符串中任何`%p`都被要歸檔的文件的絕對路徑代替，而任何`%f`都只被該文件名代替(非絕對路徑都相對于集群的數據目錄)。如果你需要在命令里嵌入`%`字符就必須雙寫`%%`。有一點很重要：這個命令必須是當且僅當成功的時候才返回零。參閱[Section 24.3.1](#calibre_link-1435)獲取更多的信息。這個參數只能在`postgresql.conf`文件或服務器命令行上。除非在服務器啟動時開啟`archive_mode`，否則忽略它。如果`archive_command`是一個空字符串（缺省）而 `archive_mode`已啟用，暫時禁用WAL歸檔，但是服務器仍繼續堆積WAL段文件期望迅速提供一個命令。設置`archive_command`命令什么也不做但返回true `/bin/true` (Windows上的`REM`)，有效地禁用歸檔，但也為了歸檔恢復打破了所需WAL文件鏈，所以應該只在特殊情況下使用。 `archive_timeout` (`integer`) [archive_command](#calibre_link-467)僅在已完成的WAL段上調用。因此，如果服務器只產生很少的WAL流量(或產生流量的周期很長)，那么在完成事務以及安全歸檔存儲之間將有一個很長的延時。為了限制未歸檔數據的逗留時間，你可以強制服務器以`archive_timeout`指定的秒數為周期切換到新的WAL段文件。當這個參數大于零時，服務器將切換到新的段文件，無論從剩余段文件切換過去多少秒，并且有任何的數據庫活動，包含一個單獨的檢查點（增加`checkpoint_timeout` 將減少空閑系統上不必要的檢查）。注意，由于強制切換而提早關閉的歸檔文件仍然與完整的歸檔文件長度相同。因此，將`archive_timeout` —設為很小的值是不明智的，它將導致占用巨大的歸檔存儲空間。將`archive_timeout`設置為60秒左右是比較合理的。如果你想要拷貝主服務器數據更加快速，你應該考慮使用流復制，而不是歸檔。這個選項只能在`postgresql.conf`文件或者服務器命令行里設置。