官方文件
https://www.postgresql.org/docs/11/wal-intro.html
https://www.postgresql.org/docs/11/wal-configuration.html
https://www.postgresql.org/docs/11/runtime-config-wal.html
https://www.postgresql.org/docs/11/runtime-config-preset.html
https://www.postgresql.org/docs/11/runtime-config-replication.html

https://www.postgresql.org/docs/11/wal-intro.html
WAL's central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged, that is, after log records describing the changes have been flushed to permanent storage. 
簡單地說，WAL的核心概念是，對資料檔案(表和索引所在的地方)的更改必須在寫入了日誌檔案後這些更改之後才可以寫入資料檔案，也就是說，描述更改的日誌記錄被重新整理到永久儲存之後才可以寫資料檔案。
Using WAL results in a significantly reduced number of disk writes, because only the log file needs to be flushed to disk to guarantee that a transaction is committed, rather than every data file changed by the transaction. The log file is written sequentially, and so the cost of syncing the log is much less than the cost of flushing the data pages. 
使用WAL可以顯著減少磁碟寫操作的數量，因為只需要將日誌檔案重新整理到磁碟以確保提交事務，而不是事務更改的每個資料檔案。日誌檔案是按順序寫入的，因此同步日誌的成本要比重新整理資料頁的成本低得多。

備註：資料庫將髒資料刷到資料檔案上,這個動作是隨機I/O,效能比寫日誌的順序I/O差太多

**總結**
1、WAL即Write Ahead Log預寫式日誌,簡稱wal日誌,相當於oracle中的redo日誌。只是oracle中redo是固定幾個redo日誌檔案,然後輪著切換去寫入。pg中wal日誌是動態切換,單個wal日誌寫滿繼續寫下一個wal日誌，連續不斷生成wal日誌。
2、單個WAL檔案的大小,預設為16MB,引數是wal_segment_size,可以理解為PG把Wal日誌儲存到N個大小為16M(預設值)的WAL segment file,一般不做更改,Postgresql 11版本之前只能在編譯pg時指定,Postgresql 11版本開始支援 initdb 和 pg_resetwal 修改 WAL 檔案大小,使用**pg_resetwal 方式修改wal_segment_size後，重啟後原來的資料都不會丟失，因為修改前是正常pg_ctl stop關閉的。如果在流複製的主庫修改這個引數再重啟，主庫資料不會丟失，但是會發現流複製不正常了**，此時從庫會報錯ERROR:  requested WAL segment 0000000100000000000000XX has already been removed，且主庫也會報錯ERROR:  requested WAL segment 0000000100000000000000XX has already been removed，當從庫關閉後，主庫不再這個錯，如果從庫再開啟，從庫會繼續報這個錯，主庫也繼續跟著報這個錯
3、決定wal_pg目錄下面的wal日誌檔案數量的引數是min_wal_size、max_wal_size、wal_keep_segments，其中wal_keep_segments配置的是 standby 複製所需的在pg_wal目錄中最少保留的 WAL 檔案的數目,一般情況下,這大概就是 wal 尺寸範圍,如果這個引數配置為0,那麼此時 WAL 檔案的數量還取決於max_wal_size，max_wal_size指定每兩個checkpoint檢查點之間產生的WAL最大量。當WAL日誌檔案超過這個WAL大小時會被自動刪除，當然這只是一個軟限制,WAL大小可能會超過max_wal_size，獨立於max_wal_size之外，wal_keep_segments + 1 個最近的 WAL 檔案將總是被保留。還有，**如果使用了 WAL 歸檔，舊的段在被歸檔之前不能被不能刪除或回收，直到它們被歸檔。如果WAL歸檔跟不上WAL生成的速度，或者archive_command重複失敗，舊的WAL檔案將在pg_wal中累積，直到問題解決。**
4、如果max_wal_size和wal_keep_segments沒起作用導致wal_pg目錄下面的wal日誌檔案不自動刪除從而越來越多，原因主要是負載過重、archive_command失敗或wal_keep_segments設定過高,當然replication slot不再使用的歷史複製槽pg_replication_slots.active=f存在的話，Wal日誌也不會自動刪除，這是因為replication slot複製插槽提供了一種自動的方法來確保主伺服器在所有備用伺服器接收到WAL段之前不會刪除WAL段，從而導致Wal日誌超過max_wal_size，以至於Wal日誌越來越多Wal目錄越來越大。
5、正常情況下pg_wal目錄下的wal檔案為線上WAL日誌，不能刪除，刪除後如果遇到資料庫重啟則會丟失資料
6、pg_wal日誌沒有設定保留週期的引數，即沒有類似mysql的引數expire_logs_days，**在檢查點之後，當舊的wal日誌檔案不再需要時，它們將被刪除或回收**(按編號順序重新命名為將來的段)。
7、**replication slot複製插槽提供了一種自動的方法來確保主伺服器在所有備用伺服器接收到WAL段之前，主伺服器不會刪除WAL段**
8、執行select pg_switch_wal()語句手工切換wal日誌時該執行過程會很快，但是pg_wal目錄下的wal日誌檔案並不會被自動刪除；執行checkpoint語句時該執行過程會很比較慢，pg_wal目錄下的一些wal日誌檔案被自動刪除，這是因為當舊的wal日誌檔案不再需要時，它們將被刪除或回收(已實驗過，執行checkpoint後，一些Wal被自動刪除了)
9、min_wal_size引數意思：只要 WAL 磁碟使用量保持在這個設定之下，在檢查點發生時舊的WAL檔案總是被回收以便未來使用(wal檔案重複利用,rename成新的檔名)，而不是直接被刪除。這可以被用來確保有足夠的 WAL 空間被保留來應付 WAL 使用的高峰，例如執行大型的批處理任務。 預設是 80 MB。也就是說為wal日誌檔案保留的最小磁碟空間的,在這個大小之內的wal日誌檔案不會被刪除,而是直接複寫。假如該值為100MB,然後pg_wal裡面已經生成的日誌檔案佔用磁碟為80MB,此時WAL磁碟使用率為80MB低於這個100MB,那麼這80MB的pg_wal日誌檔案都會被複用,這可以用來確保預留足夠的WAL空間處理WAL使用中的峰值。min_wal_size設定的值不是指作業系統df看到物理磁碟可用空間小於min_wal_size時需要回收wal以便使wal在物理磁碟不足時可以不受物理磁碟不足的影響
10、Postgresql哪些情況會觸發資料庫的checkpoint
10.1、手動執行CHECKPOINT命令
10.2、執行需要檢查點的命令（例如pg_start_backup 或pg_ctl stop|restart等等）
10.3、達到檢查點配置時間(checkpoint_timeout)
10.4、max_wal_size已滿
10.5、資料庫正常shutdown
11、Wal日誌歸檔的方法，前提是已經啟用了archive_mode=on和設定了archive_command
11.1、select pg_switch_wal();
11.2、wal日誌寫滿後會自動歸檔
11.3、達到引數archive_timeout值
12、Wal歸檔後,不會把之前的wal刪除，歸檔就是把wal拷貝一份到歸檔的路徑下面
13、手工清理pg_wal日誌的命令是pg_archivecleanup，如下表示刪除000000010000000000000005之前的所有日誌
pg_archivecleanup /postgresql/pgsql/data/pg_wal 000000010000000000000005
14、WAL的配置引數大部分可以選擇預設值，一般配置min_wal_size、max_wal_size、wal_keep_segments、checkpoint_timeout這個幾個引數就夠了
15、postgresql wal三種模式minimal、replica、logical下，產生的日誌量不會相差太大，比較像oracle的redo和mysql的redo log，而不像mysql的binlog引數binlog_format=statement或binlog_format=row時產生的binlog日誌會相差很大，因為statement時，binlog只記錄sql語句，row時，binlog會記錄真實刪除行的主鍵id和其他所有欄位的資訊，mysql的如果delete語句刪掉10萬行資料，用statement的話就是一個 SQL語句被記錄到binlog中，佔用幾十個位元組的空間。但如果用row格式的binlog，就要把這10萬條記錄都寫到binlog中。
16、PostgreSQL在寫入頻繁的場景中，會產生大量的WAL日誌，而且WAL日誌量會遠遠超過實際更新的資料量，這就叫做“WAL寫放大”，產生的原因主要有以下兩點。說個題外話當年Uber也是這個原因之一把pg切換成了mysql，參見https://eng.uber.com/postgres-to-mysql-migration/
16.1、full page writes，PostgreSQL會在一個checkpoint檢查點之後的頁面的第一次修改期間將每個頁面的全部內容寫到Wal檔案
16.2、update時如果新記錄位置發生變更，索引記錄也要相應變更，這個變更也要記入WAL。而索引記錄的變更又有可能導致索引頁的全頁寫，進一步加劇了把內容寫到Wal檔案。
17、PostgreSQL的安裝目錄下有個叫做pg_xlogdump的命令可以解析WAL檔案(mysql可以使用strings檢視redo log和使用mysqlbinlog檢視binlog，oracle沒有可以直接檢視redo log的linux命令)，命令如下
pg_xlogdump /pgsql/data/pg_xlog/0000000100000555000000D5 -b
18、wal日誌檔案和LSN編號對應規則：wal日誌檔名的後兩位是LSN的前兩位;wal日誌檔案的偏移量是LSN的後六位對應的十進位制值
18.1、select pg_walfile_name(pg_current_wal_lsn())命令中我們看到wal日誌檔名00000001000000010000004D的後兩位是4D，而LSN號1/4D000140的/斜槓後面的前兩位也是4D，也就是說日誌檔名的後兩位是LSN的前兩位。
18.2、SELECT * FROM pg_walfile_name_offset(pg_current_wal_lsn())命令中我們看到wal日誌中的偏移量是320，而LSN號1/4D000140後6位是000140,000140對應的十進位制值剛好是320,也就是說日誌檔案的偏移量是LSN的後六位的十進位制值
例如當前wal日誌偏移量為504
postgres=# select pg_current_wal_lsn();
 pg_current_wal_lsn
 1/4D000140
(1 row)

postgres=# select pg_walfile_name(pg_current_wal_lsn());
     pg_walfile_name
 00000001000000010000004D
(1 row)

postgres=# SELECT * FROM pg_walfile_name_offset(pg_current_wal_lsn());
        file_name         | file_offset
--------------------------+-------------
 00000001000000010000004D |         320
(1 row)

postgres=# select x'000140'::int;
 int4
  320
(1 row)

**WAL的涉及的引數及解釋：**
wal_segment_size：
Reports the size of write ahead log segments. The default value is 16MB
單個WAL檔案的大小,預設為16MB,一般不做更改,且在pg11之前,只能在編譯pg時指定。

wal_level
確定將多少資訊寫入 WAL 。 預設值為 replica ,它寫入足夠的資料以支援 WAL 歸檔和複製,包括在備用伺服器上執行只讀查詢。
從低到告的三個級別分別是minimal、replica、logical，minimal會去掉除從崩潰或者立即關機中進行恢復所需的資訊之外的所有記錄，logical=replica+邏輯解碼所需的資訊。
在 9.6 之前的版本中，這個引數也允許值archive和hot_standby。現在仍然接受這些值，但是它們會被對映到replica。

wal_keep_segments：
Specifies the minimum number of past log file segments kept in the pg_wal directory, in case a standby server needs to fetch them for streaming replication. Each segment is normally 16 megabytes. 
這個引數配置的是 standby 複製所需的在pg_wal目錄中最少保留的 WAL 檔案的數目,一般情況下,這大概就是 wal 尺寸範圍,如果這個引數配置為0,那麼此時 WAL 檔案的數量還取決於max_wal_size等其他引數。預設值為0

min_wal_size：
min_wal_size puts a minimum on the amount of WAL files recycled for future usage
min_wal_size為將來使用而回收的WAL檔案的數量設定了一個最小值
https://www.postgresql.org/docs/11/runtime-config-wal.html
As long as WAL disk usage stays below this setting, old WAL files are always recycled for future use at a checkpoint, rather than removed. This can be used to ensure that enough WAL space is reserved to handle spikes in WAL usage, for example when running large batch jobs. The default is 80 MB. This parameter can only be set in the postgresql.conf file or on the server command line.
只要WAL磁碟使用率低於這個設定,舊的WAL檔案總是被回收(wal檔案重複利用,rename成新的檔名),以供將來檢查點使用。而不是刪除。 可以理解為wal日誌檔案保留的磁碟大小,在這個大小之內的wal日誌檔案不會被刪除,而是直接複寫。預設是 80 MB。
備註：假如該值為100MB,然後pg_wal裡面已經生成的日誌檔案佔用磁碟為80MB,此時WAL磁碟使用率為80MB低於這個100MB,那麼這80MB的pg_wal日誌檔案都會被複用,這可以用來確保預留足夠的WAL空間處理WAL使用中的峰值

max_wal_size：
Maximum size to let the WAL grow to between automatic WAL checkpoints. This is a soft limit; WAL size can exceed max_wal_size under special circumstances, like under heavy load, a failing archive_command, or a high wal_keep_segments setting. The default is 1 GB. Increasing this parameter can increase the amount of time needed for crash recovery.
這個引數指定每兩個checkpoint檢查點之間產生的WAL最大量。當WAL日誌檔案超過這個WAL大小時會被自動刪除，當然這只是一個軟限制,WAL大小可能會超過max_wal_size,比如在負載過重、archive_command失敗或wal_keep_segments設定過高的情況下,增加這個引數 可能導致崩潰恢復所需的時間。預設為 1 GB
https://www.postgresql.org/docs/11/warm-standby.html#STREAMING-REPLICATION-SLOTS
Replication slots provide an automated way to ensure that the master does not remove WAL segments until they have been received by all standbys
複製插槽提供了一種自動的方法來確保主伺服器在所有備用伺服器接收到WAL段之前不會刪除WAL段，比如replication slot不再使用的歷史複製槽pg_replication_slots.active=f存在的話，Wal日誌就不會自動刪除，從而導致Wal日誌超過max_wal_size，以至於Wal日誌越來越多Wal目錄越來越大

checkpoint_timeout
Maximum time between automatic WAL checkpoints, in seconds. The valid range is between 30 seconds and one day. The default is five minutes (5min). Increasing this parameter can increase the amount of time needed for crash recovery. 
自動WAL檢查點之間的最長時間,以秒計,合理的範圍在30秒到1天之間,預設是5分鐘
備註：如果檢查點觸發的頻率小於30s,則執行日誌中會提醒你增加max_wal_size

checkpoint_completion_target
Specifies the target of checkpoint completion, as a fraction of total time between checkpoints. The default is 0.5.
預設值為0.5，PostgreSQL被期望能夠在下一個檢查點啟動之前的大約一半時間內完成每個檢查點,也就是說每個checkpoint需要在checkpoints間隔時間的50%內完成。
假如我的checkpoint_timeout設定是30分鐘,而wal生成了100G遇到IO很慢的時間就需要很長時間來完成這100GB的checkpoint,那麼設定成0.5就允許我在15分鐘內完成checkpoint,設定成0.8就允許我在24分鐘內完成checkpoint,調大這個值就可以降低checkpoint對效能的影響,但是萬一資料庫出現故障,那麼這個值設定越大資料庫就越危險。

fsync：表示每次提交時是否強制Wal更新到磁碟，預設就是ON,也就是說提交的資訊一定會寫入Wal日誌檔案，雖然關閉fsync常常可以得到效能上的收益，但當發生斷電或系統崩潰時可能造成不可恢復的資料損壞。和Mysql的innodb_flush_log_at_trx_commit引數類似
如果關閉這個引數，那麼一般也需要關閉full_page_writes引數

synchronous_commit：指定在命令返回“success”指示給客戶端之前，一個事務是否需要等待 WAL 記錄被寫入磁碟，預設值是ON。當設定為off時，在向客戶端報告成功和真正保證事務不會被伺服器崩潰威脅之間會有延遲(最大的延遲是wal_writer_delay的三倍)。不同於fsync，將這個引數設定為off不會產生資料庫不一致性的風險

full_page_writes：表示PostgreSQL伺服器在一個檢查點之後的頁面的第一次修改期間是否將每個頁面的全部內容寫到 WAL 中。這麼做是因為在作業系統崩潰期間正在處理的一次頁寫入可能只有部分完成，從而導致在一個磁碟頁面中混合有新舊資料。在崩潰後的恢復期間，通常儲存在 WAL 中的行級改變資料不足以完全恢復這樣一個頁面。儲存完整的頁面映像可以保證頁面被正確儲存，但代價是增加了必須被寫入 WAL 的資料量，因為 WAL 重放總是從一個檢查點開始，所以在檢查點後每個頁面的第一次改變時這樣做就夠了。因此，一種減小全頁面寫開銷的方法是增加檢查點間隔引數值。把這個引數關閉會加快正常操作，但是在系統失敗後可能導致不可恢復的資料損壞，或者靜默的資料損壞。預設值是on。

wal_buffers：表示還未寫入磁碟的 WAL 資料的共享記憶體量。預設值 -1 選擇等於shared_buffers的 1/32 的尺寸（大約3%），但是通常為不小於64kB也不大於 WAL 段的尺寸。如果自動的選擇太大或太小可以手工設定該值，但是任何小於32kB的正值都將被當作32kB。這個引數只能在伺服器啟動時設定。在每次事務提交時，WAL 緩衝區的內容被寫出到磁碟，因此極大的值不可能提供顯著的收益。不過，把這個值設定為幾個兆位元組可以在一個繁忙的伺服器（其中很多客戶端會在同一時間提交）上提高寫效能。由預設設定 -1 選擇的自動調節將在大部分情況下得到合理的結果。

wal_writer_delay：指定 WAL 寫入器刷寫 WAL 的頻繁程度。在刷寫 WAL 之後它會睡眠wal_writer_delay毫秒，除非被一個非同步提交事務喚醒。假如上一次刷寫發生在少於wal_writer_delay毫秒以前並且從上一次刷寫發生以來產生了少於wal_writer_flush_after位元組的 WAL，則WAL將只被寫入到作業系統而不是被刷到磁碟。預設值是 200 毫秒（200ms）。通俗理解就是WAL writer程式的間歇時間，類似oracle redo buffer每3秒刷一次磁碟，如果時間過長可能造成WAL buffer的記憶體不足；反之過小將會引起WAL的不斷的寫入，對磁碟的IO也是很大考驗。

commit_delay：表示在一次 WAL 刷寫被髮起之前，commit_delay增加一個時間延遲，以微妙計。如果系統負載足夠高，使得在一個給定間隔內有額外的事務準備好提交，那麼通過允許更多事務通過一個單次 WAL 刷寫來提交能夠提高組提交的吞吐量。但是，它也把每次 WAL 刷寫的潛伏期增加到了最多commit_delay微秒。因為如果沒有其他事務準備好提交，就會浪費一次延遲，只有在當一次刷寫將要被髮起時有至少commit_siblings個其他活動事務時，才會執行一次延遲。另外，如果fsync被禁用，則將不會執行任何延遲。預設的commit_delay是零(無延遲)。通俗解釋就是表示了一個已經提交的資料在WAL buffer中存放的時間。如果設定為非0，表明了某個事務執行commit後不會立即寫入WAL中，而仍存放在WAL buffer中，這樣對於後面的事務申請WAL buffer時非常不利，尤其是提交事務較多的高峰期，可能引起WAL buffer記憶體不足，同樣如果此時崩潰資料面臨著丟失的危險。優點是能夠使資料集中寫入這樣降低了系統的IO，提高了效能。類似mysql的binlog_group_commit_sync_delay 引數
    
commit_siblings：表示在執行commit_delay延遲時，要求的併發活動事務的最小數目，系統預設值是5。 表示當一個事務發出提交請求，此時資料庫中正在執行的事務數量大於5，則該事務將等待一段時間(commit_delay的值)，反之，該事務則直接寫入WAL。類似mysql的binlog_group_commit_sync_no_delay_count 引數

archive_mode
當啟用archive_mode時，可以通過設定 archive_command命令將完成的 WAL 段傳送到 歸檔儲存。除用於禁用的off之外，還有兩種模式： on和always。在普通操作期間，這兩種模式之間 沒有區別，但是當設定為always時，WAL 歸檔器在歸檔恢復 或者後備模式下也會被啟用。在always模式下，所有從歸檔恢復 的或者用流複製傳來的檔案將被（再次）歸檔。預設值是off。

archive_timeout
you can set archive_timeout to force the server to switch to a new WAL segment file periodically. When this parameter is greater than zero, the server will switch to a new segment file whenever this many seconds have elapsed since the last segment file switch, and there has been any database activity, including a single checkpoint (checkpoints are skipped if there is no database activity).
您可以設定archive_timeout來強制伺服器定期切換到新的WAL段檔案。當此引數大於0時，只要從最後一次段檔案切換以來已經經過了這麼多秒，並且存在任何資料庫活動，包括單個檢查點(如果沒有資料庫活動，則跳過檢查點)，伺服器就會切換到新的段檔案。只要DB例項有寫入,儘管寫入量很少,只要到達 archive_timeout 會觸發WAL檔案的強制切換。因此如果archive_timeout如果太短就會產生很多新的WAL日誌檔案,從而產生大量歸檔。預設值為0
archive_timeout就是定時歸檔的時間
如果為0表示不啟用定時歸檔，而是當Wal檔案寫滿後開始寫下一個Wal檔案時，在archive_mode=on的情況下時通過archive_command命令將Wal檔案歸檔

https://www.postgresql.org/docs/11/wal-configuration.html
Checkpoints are points in the sequence of transactions at which it is guaranteed that the heap and index data files have been updated with all information written before that checkpoint. At checkpoint time, all dirty data pages are flushed to disk and a special checkpoint record is written to the log file. (The change records were previously flushed to the WAL files.) In the event of a crash, the crash recovery procedure looks at the latest checkpoint record to determine the point in the log (known as the redo record) from which it should start the REDO operation. Any changes made to data files before that point are guaranteed to be already on disk. Hence, after a checkpoint, log segments preceding the one containing the redo record are no longer needed and can be recycled or removed. (When WAL archiving is being done, the log segments must be archived before being recycled or removed.)
檢查點是事務序列中的點，在這些點上，可以保證所有更新資訊已經在檢查點之前寫入了堆和索引資料檔案。在檢查點時，將所有髒資料頁重新整理到磁碟，並將一個特殊的檢查點記錄寫入日誌檔案。(更改記錄之前被重新整理到WAL檔案中。)在發生崩潰時，崩潰恢復過程將檢視最新的檢查點記錄，以確定日誌中應該從何處開始重做操作(稱為重做記錄)。在此之前對資料檔案所做的任何更改都保證已經在磁碟上。因此，在檢查點之後，不再需要包含重做記錄的日誌段之前的日誌段，可以回收或刪除。(在進行WAL歸檔時，必須在回收或刪除日誌段之前對其進行歸檔。)

The checkpoint requirement of flushing all dirty data pages to disk can cause a significant I/O load. For this reason, checkpoint activity is throttled so that I/O begins at checkpoint start and completes before the next checkpoint is due to start; this minimizes performance degradation during checkpoints.
檢查點要求將所有髒資料頁重新整理到磁碟，這可能導致大量I/O負載。由於這個原因，檢查點活動被調節以便I/O在檢查點開始時開始並在下一個檢查點開始之前完成;這可以最大限度地降低檢查點期間的效能下降。

The server's checkpointer process automatically performs a checkpoint every so often. A checkpoint is begun every checkpoint_timeout seconds, or if max_wal_size is about to be exceeded, whichever comes first. The default settings are 5 minutes and 1 GB, respectively. If no WAL has been written since the previous checkpoint, new checkpoints will be skipped even if checkpoint_timeout has passed. (If WAL archiving is being used and you want to put a lower limit on how often files are archived in order to bound potential data loss, you should adjust the archive_timeout parameter rather than the checkpoint parameters.) It is also possible to force a checkpoint by using the SQL command CHECKPOINT.
伺服器的檢查指標程式經常自動執行檢查點。每個checkpoint_timeout秒開始一個檢查點，或者如果要超過max_wal_size，則以先到的為準。預設設定分別為5分鐘和1 GB。如果在前一個檢查點之後沒有寫入WAL，那麼將跳過新的檢查點，即使checkpoint_timeout已經通過。(如果正在使用WAL歸檔，並且您希望對檔案歸檔的頻率設定一個較低的限制，以便繫結潛在的資料丟失，那麼您應該調整archive_timeout引數，而不是檢查點引數。)還可以使用SQL命令檢查點強制設定檢查點。

Reducing checkpoint_timeout and/or max_wal_size causes checkpoints to occur more often. This allows faster after-crash recovery, since less work will need to be redone. However, one must balance this against the increased cost of flushing dirty data pages more often. If full_page_writes is set (as is the default), there is another factor to consider. To ensure data page consistency, the first modification of a data page after each checkpoint results in logging the entire page content. In that case, a smaller checkpoint interval increases the volume of output to the WAL log, partially negating the goal of using a smaller interval, and in any case causing more disk I/O.
減少checkpoint_timeout和/或max_wal_size會導致更頻繁地出現檢查點。這允許更快的崩潰後恢復，因為需要重做的工作更少。但是，必須在這一點與更頻繁地重新整理髒資料頁所增加的成本之間進行權衡。如果設定了full_page_writes(預設設定)，那麼還需要考慮另一個因素。為了確保資料頁面的一致性，資料頁面在每個檢查點之後的第一次修改將導致記錄整個頁面內容。在這種情況下，更小的檢查點間隔會增加輸出容量到WAL日誌，在一定程度上否定了使用更小的間隔的目標，並且在任何情況下都會導致更多的磁碟I/O。

Checkpoints are fairly expensive, first because they require writing out all currently dirty buffers, and second because they result in extra subsequent WAL traffic as discussed above. It is therefore wise to set the checkpointing parameters high enough so that checkpoints don't happen too often. As a simple sanity check on your checkpointing parameters, you can set the checkpoint_warning parameter. If checkpoints happen closer together than checkpoint_warning seconds, a message will be output to the server log recommending increasing max_wal_size. Occasional appearance of such a message is not cause for alarm, but if it appears often then the checkpoint control parameters should be increased. Bulk operations such as large COPY transfers might cause a number of such warnings to appear if you have not set max_wal_size high enough.
檢查點相當昂貴，首先是因為它們需要寫出所有當前的髒緩衝區，其次是因為它們會導致前面討論的額外的後續WAL流量。因此，明智的做法是將檢查點引數設定得足夠高，這樣檢查點就不會經常出現。作為對檢查點引數的簡單完整性檢查，可以設定checkpoint_warning引數。如果檢查點發生的距離比checkpoint_warning秒更近，則會向伺服器日誌輸出一條訊息，建議增加max_wal_size。偶爾出現這樣的訊息並不會引起警報，但如果經常出現，則應該增加檢查點控制引數。如果沒有將max_wal_size設定得足夠高，那麼像大型複製傳輸這樣的大容量操作可能會導致出現大量這樣的警告。

To avoid flooding the I/O system with a burst of page writes, writing dirty buffers during a checkpoint is spread over a period of time. That period is controlled by checkpoint_completion_target, which is given as a fraction of the checkpoint interval. The I/O rate is adjusted so that the checkpoint finishes when the given fraction of checkpoint_timeout seconds have elapsed, or before max_wal_size is exceeded, whichever is sooner. With the default value of 0.5, PostgreSQL can be expected to complete each checkpoint in about half the time before the next checkpoint starts. On a system that's very close to maximum I/O throughput during normal operation, you might want to increase checkpoint_completion_target to reduce the I/O load from checkpoints. The disadvantage of this is that prolonging checkpoints affects recovery time, because more WAL segments will need to be kept around for possible use in recovery. Although checkpoint_completion_target can be set as high as 1.0, it is best to keep it less than that (perhaps 0.9 at most) since checkpoints include some other activities besides writing dirty buffers. A setting of 1.0 is quite likely to result in checkpoints not being completed on time, which would result in performance loss due to unexpected variation in the number of WAL segments needed.
為了避免大量的頁寫操作充斥I/O系統，在檢查點期間寫入髒緩衝區要分散在不同時間段。該時間段週期由checkpoint_completion_target控制，它是檢查點間隔的一部分。調整I/O速率，以便在經過給定的checkpoint_timeout秒數時或者在超過max_wal_size之前結束檢查點(checkpoint_timeout秒數或超過max_wal_size這兩者以誰先到達為準)。預設值為0.5,PostgreSQL可以在下一個檢查點開始前的一半時間內完成每個檢查點。在正常操作期間非常接近最大I/O吞吐量的系統上，您可能希望增加checkpoint_completion_target以減少檢查點的I/O負載。這樣做的缺點是，延長檢查點會影響恢復時間，因為需要保留更多的WAL段以供恢復時使用。儘管checkpoint_completion_target可以設定為1.0，但是最好將其設定在1.0以下(可能最多0.9)，因為檢查點除了寫入髒緩衝區之外還包含其他活動。設定為1.0很可能會導致檢查點不能按時完成，這將導致效能損失，因為所需的WAL段數量會發生意外變化。

On Linux and POSIX platforms checkpoint_flush_after allows to force the OS that pages written by the checkpoint should be flushed to disk after a configurable number of bytes. Otherwise, these pages may be kept in the OS's page cache, inducing a stall when fsync is issued at the end of a checkpoint. This setting will often help to reduce transaction latency, but it also can have an adverse effect on performance; particularly for workloads that are bigger than shared_buffers, but smaller than the OS's page cache.
在Linux和POSIX平臺上，checkpoint_flush_after允許強制作業系統將檢查點寫入的頁面以可配置的位元組數重新整理到磁碟。否則，這些頁面可能會儲存在作業系統的頁面快取中，導致在檢查點結束時發出fsync時出現停頓。此設定通常有助於減少事務延遲，但也可能對效能產生不利影響;特別是對於比shared_buffers大，但比OS的頁面快取小的工作負載。

The number of WAL segment files in pg_wal directory depends on min_wal_size, max_wal_size and the amount of WAL generated in previous checkpoint cycles. When old log segment files are no longer needed, they are removed or recycled (that is, renamed to become future segments in the numbered sequence). If, due to a short-term peak of log output rate, max_wal_size is exceeded, the unneeded segment files will be removed until the system gets back under this limit. Below that limit, the system recycles enough WAL files to cover the estimated need until the next checkpoint, and removes the rest. The estimate is based on a moving average of the number of WAL files used in previous checkpoint cycles. The moving average is increased immediately if the actual usage exceeds the estimate, so it accommodates peak usage rather than average usage to some extent. min_wal_size puts a minimum on the amount of WAL files recycled for future usage; that much WAL is always recycled for future use, even if the system is idle and the WAL usage estimate suggests that little WAL is needed.
pg_wal目錄中的WAL段檔案的數量取決於min_wal_size、max_wal_size和在以前的檢查點週期中生成的WAL數量。當舊的日誌段檔案不再需要時，它們將被刪除或回收(也就是說，按編號順序重新命名為將來的段)。如果由於日誌輸出率的短期峰值，超過了max_wal_size，那麼不需要的段檔案將被刪除，直到系統返回到這個限制之下。如果低於這個限制，系統將回收足夠的WAL檔案來滿足估計的需求，直到下一個檢查點，並刪除其餘的。這個估計是基於前一個檢查點週期中使用的WAL檔案數量的移動平均值。如果實際使用量超過估計，則移動平均會立即增加，因此在某種程度上它適應峰值使用量，而不是平均使用量。min_wal_size為將來使用而回收的WAL檔案的數量設定一個最小值;即使系統處於閒置狀態，而且WAL的使用量估計表明需要少量的WAL，那麼大量的WAL也會被回收以備將來使用。

Independently of max_wal_size, wal_keep_segments + 1 most recent WAL files are kept at all times. Also, if WAL archiving is used, old segments can not be removed or recycled until they are archived. If WAL archiving cannot keep up with the pace that WAL is generated, or if archive_command fails repeatedly, old WAL files will accumulate in pg_wal until the situation is resolved. A slow or failed standby server that uses a replication slot will have the same effect (see Section 26.2.6).
獨立於max_wal_size, wal_keep_segments + 1個最新的WAL檔案會一直儲存。此外，如果使用了WAL歸檔，舊的段不能刪除或回收，直到它們被歸檔。如果WAL歸檔跟不上WAL生成的速度，或者archive_command重複失敗，舊的WAL檔案將在pg_wal中累積，直到問題解決。使用複製槽的慢速或失敗的備用伺服器也會產生同樣的效果。

In archive recovery or standby mode, the server periodically performs restartpoints, which are similar to checkpoints in normal operation: the server forces all its state to disk, updates the pg_control file to indicate that the already-processed WAL data need not be scanned again, and then recycles any old log segment files in the pg_wal directory. Restartpoints can't be performed more frequently than checkpoints in the master because restartpoints can only be performed at checkpoint records. A restartpoint is triggered when a checkpoint record is reached if at least checkpoint_timeout seconds have passed since the last restartpoint, or if WAL size is about to exceed max_wal_size. However, because of limitations on when a restartpoint can be performed, max_wal_size is often exceeded during recovery, by up to one checkpoint cycle's worth of WAL. (max_wal_size is never a hard limit anyway, so you should always leave plenty of headroom to avoid running out of disk space.)
在存檔恢復或待機模式下，伺服器定期執行重啟點，類似於正常執行時的檢查點:伺服器強制將其所有狀態轉移到磁碟，更新pg_control檔案，以表明不需要再次掃描已處理的WAL資料，然後回收pg_wal目錄中的所有舊日誌段檔案。在主程式中，重新起始點不能比檢查點執行得更頻繁，因為重新起始點只能在檢查點記錄上執行。如果從最後一個重啟點開始已經經過了至少checkpoint_timeout秒，或者如果WAL大小即將超過max_wal_size，那麼當到達檢查點記錄時，就會觸發一個重啟點。但是，由於對何時可以執行重新起始點的限制，在恢復期間經常會超過max_wal_size，最多超過一個檢查點週期的WAL。(max_wal_size從來都不是一個硬限制，所以您應該始終留有足夠的空間，以避免耗盡磁碟空間。)

There are two commonly used internal WAL functions: XLogInsertRecord and XLogFlush. XLogInsertRecord is used to place a new record into the WAL buffers in shared memory. If there is no space for the new record, XLogInsertRecord will have to write (move to kernel cache) a few filled WAL buffers. This is undesirable because XLogInsertRecord is used on every database low level modification (for example, row insertion) at a time when an exclusive lock is held on affected data pages, so the operation needs to be as fast as possible. What is worse, writing WAL buffers might also force the creation of a new log segment, which takes even more time. Normally, WAL buffers should be written and flushed by an XLogFlush request, which is made, for the most part, at transaction commit time to ensure that transaction records are flushed to permanent storage. On systems with high log output, XLogFlush requests might not occur often enough to prevent XLogInsertRecord from having to do writes. On such systems one should increase the number of WAL buffers by modifying the wal_buffers parameter. When full_page_writes is set and the system is very busy, setting wal_buffers higher will help smooth response times during the period immediately following each checkpoint.
有兩個常用的內部WAL函式:XLogInsertRecord和XLogFlush。XLogInsertRecord用於將一個新記錄放入共享記憶體中的WAL緩衝區中。如果沒有新記錄的空間，XLogInsertRecord將不得不寫入(移動到核心快取)一些已填充的WAL緩衝區。這是不希望看到的，因為當受影響的資料頁上持有排他鎖時，每個資料庫低階修改(例如行插入)都使用XLogInsertRecord，因此操作需要儘可能快。更糟糕的是，寫入WAL緩衝區可能還會強制建立新的日誌段，這會花費更多的時間。通常，應該通過一個XLogFlush請求來寫入和重新整理WAL緩衝區，這個請求在大多數情況下是在事務提交時發出的，以確保事務記錄被重新整理到永久儲存中。在具有高日誌輸出的系統上，XLogFlush請求發生的頻率可能不足以防止XLogInsertRecord不得不進行寫操作。在這樣的系統上，應該通過修改wal_buffers引數來增加WAL緩衝區的數量。當設定了full_page_writes並且系統非常繁忙時，將wal_buffers設定得更高將有助於使每個檢查點之後的響應時間更平穩。

The commit_delay parameter defines for how many microseconds a group commit leader process will sleep after acquiring a lock within XLogFlush, while group commit followers queue up behind the leader. This delay allows other server processes to add their commit records to the WAL buffers so that all of them will be flushed by the leader's eventual sync operation. No sleep will occur if fsync is not enabled, or if fewer than commit_siblings other sessions are currently in active transactions; this avoids sleeping when it's unlikely that any other session will commit soon. Note that on some platforms, the resolution of a sleep request is ten milliseconds, so that any nonzero commit_delay setting between 1 and 10000 microseconds would have the same effect. Note also that on some platforms, sleep operations may take slightly longer than requested by the parameter.
commit_delay引數定義了在獲取XLogFlush中的鎖之後，組提交leader程式將休眠多少微秒，而組提交follower將在leader後面排隊。這種延遲允許其他伺服器程式將它們的提交記錄新增到WAL緩衝區中，以便所有這些記錄都將被leader的最終同步操作重新整理。如果沒有啟用fsync，或者當前處於活動事務中的其他會話少於commit_sibling，則不會發生睡眠;這樣可以避免在其他會話不太可能很快提交時出現睡眠。注意，在一些平臺上，睡眠請求的解析度是10毫秒，因此在1到10000微秒之間的任何非零的commit_delay設定都具有相同的效果。還要注意的是，在一些平臺上，睡眠操作所花費的時間可能比該引數所請求的時間稍長。

Since the purpose of commit_delay is to allow the cost of each flush operation to be amortized across concurrently committing transactions (potentially at the expense of transaction latency), it is necessary to quantify that cost before the setting can be chosen intelligently. The higher that cost is, the more effective commit_delay is expected to be in increasing transaction throughput, up to a point. The pg_test_fsync program can be used to measure the average time in microseconds that a single WAL flush operation takes. A value of half of the average time the program reports it takes to flush after a single 8kB write operation is often the most effective setting for commit_delay, so this value is recommended as the starting point to use when optimizing for a particular workload. While tuning commit_delay is particularly useful when the WAL log is stored on high-latency rotating disks, benefits can be significant even on storage media with very fast sync times, such as solid-state drives or RAID arrays with a battery-backed write cache; but this should definitely be tested against a representative workload. Higher values of commit_siblings should be used in such cases, whereas smaller commit_siblings values are often helpful on higher latency media. Note that it is quite possible that a setting of commit_delay that is too high can increase transaction latency by so much that total transaction throughput suffers.
由於commit_delay的目的是允許每個重新整理操作的成本在併發提交事務中平攤(可能以事務延遲為代價)，所以有必要在智慧選擇設定之前對該成本進行量化。成本越高，在一定程度上，commit_delay在提高事務吞吐量方面的預期效果就越好。pg_test_fsync程式可用於測量單個WAL重新整理操作所花費的平均時間(以微秒為單位)。對於commit_delay來說，在一個8kB的寫操作之後，程式報告重新整理所花費的平均時間的一半通常是最有效的設定，因此在針對特定工作負載進行優化時，建議將這個值作為起始點使用。當WAL日誌儲存在高延遲的旋轉磁碟上時，調整commit_delay特別有用，即使在同步時間非常快的儲存介質上，比如固態驅動器或帶有電池支援的寫快取的RAID陣列，也會有顯著的好處;但是這一定要在一個有代表性的工作負載上進行測試。在這種情況下應該使用較高的commit_sibling值，而較小的commit_sibling值在延遲較高的媒體上通常很有幫助。注意，設定過高的commit_delay很可能會增加事務延遲，從而影響整個事務吞吐量。

When commit_delay is set to zero (the default), it is still possible for a form of group commit to occur, but each group will consist only of sessions that reach the point where they need to flush their commit records during the window in which the previous flush operation (if any) is occurring. At higher client counts a “gangway effect” tends to occur, so that the effects of group commit become significant even when commit_delay is zero, and thus explicitly setting commit_delay tends to help less. Setting commit_delay can only help when (1) there are some concurrently committing transactions, and (2) throughput is limited to some degree by commit rate; but with high rotational latency this setting can be effective in increasing transaction throughput with as few as two clients (that is, a single committing client with one sibling transaction).
當commit_delay設定為0(預設),它仍然是一種小組提交的現象有可能發生,但每組只包含會話到達的地方是,他們需要衝洗他們的提交記錄的視窗前沖洗操作期間發生(如果有的話)。在較高的客戶端計數時，往往會出現“通道效應”，因此即使在commit_delay為0時，組提交的效果也會變得顯著，因此顯式地設定commit_delay幫助不大。設定commit_delay只有在以下情況下才有幫助:(1)有一些併發提交的事務，(2)吞吐量受到提交率的一定限制;但是由於具有很高的旋轉延遲，此設定可以有效地提高只有兩個客戶機(即一個提交客戶機具有一個兄弟事務)的事務吞吐量。

The wal_sync_method parameter determines how PostgreSQL will ask the kernel to force WAL updates out to disk. All the options should be the same in terms of reliability, with the exception of fsync_writethrough, which can sometimes force a flush of the disk cache even when other options do not do so. However, it's quite platform-specific which one will be the fastest. You can test the speeds of different options using the pg_test_fsync program. Note that this parameter is irrelevant if fsync has been turned off.
wal_sync_method引數決定了PostgreSQL將如何要求核心強制將WAL更新到磁碟。就可靠性而言，所有選項都應該是相同的，除了fsync_writethrough，它有時會強制重新整理磁碟快取，即使其他選項沒有這樣做。但是，哪個平臺最快是完全不同於平臺的。您可以使用pg_test_fsync程式測試不同選項的速度。注意，如果fsync已經關閉，那麼這個引數是不相關的。

Enabling the wal_debug configuration parameter (provided that PostgreSQL has been compiled with support for it) will result in each XLogInsertRecord and XLogFlush WAL call being logged to the server log. This option might be replaced by a more general mechanism in the future.
啟用wal_debug配置引數(前提是PostgreSQL已經編譯並支援它)將導致每個XLogInsertRecord和XLogFlush WAL呼叫被記錄到伺服器日誌中。這一選擇可能在將來被一種更一般的機制所取代。

Postgresqlg關於wal日誌總結，一文搞清楚它的所有概念和相關操作

相關文章