PostgreSQL 異步提交

異步提交是一個允許事務(wù)能更快完成的選項，代價是在數(shù)據(jù)庫崩潰時最近的事務(wù)會丟失。在很多應(yīng)用中這是一個可接受的交換。

如前一節(jié)所述，事務(wù)提交通常是同步的：服務(wù)器等到事務(wù)的WAL記錄被刷寫到持久存儲之后才向客戶端返回成功指示。因此客戶端可以確保那些報告已被提交的事務(wù)確會被保存，即便隨后馬上發(fā)生了一次服務(wù)器崩潰。但是，對于短事務(wù)來說這種延遲是其總執(zhí)行時間的主要部分。選擇異步提交模式意味著服務(wù)器將在事務(wù)被邏輯上提交后立刻返回成功，而此時由它生成的WAL記錄還沒有被真正地寫到磁盤上。這將為小型事務(wù)的生產(chǎn)力產(chǎn)生顯著地提升。

異步提交會帶來數(shù)據(jù)丟失的風(fēng)險。在向客戶端報告事務(wù)完成到事務(wù)真正被提交（即能保證服務(wù)器崩潰時它也不會被丟失）之間有一個短的時間窗口。因此如果客戶端將會做一些要求其事務(wù)被記住的外部動作，就不應(yīng)該用異步提交。例如，一個銀行肯定不會使用異步提交事務(wù)來記錄一臺ATM的現(xiàn)金分發(fā)。但是在很多情境中不需要這種強(qiáng)的保證，例如事件日志。

使用異步提交帶來的風(fēng)險是數(shù)據(jù)丟失，而不是數(shù)據(jù)損壞。如果數(shù)據(jù)庫可能崩潰，它會通過重放WAL到被刷寫的最后一個記錄來進(jìn)行恢復(fù)。數(shù)據(jù)庫將因此被恢復(fù)到一個自身一致狀態(tài)，但是任何還沒有被刷寫到磁盤的事務(wù)將不會反映在該狀態(tài)中。因此其影響就是丟失了最后的少量事務(wù)。由于事務(wù)按照提交順序被重放，所以不會出現(xiàn)任何不一致性 — 例如一個事務(wù)B按照前面一個事務(wù)A的效果來進(jìn)行修改，則不會出現(xiàn)A的效果丟失而B的效果被保留的情況。

用戶可以選擇每一個事務(wù)的提交模式，這樣可以有同步提交和異步提交的事務(wù)并行運行。這允許我們靈活地在性能和事務(wù)持久性之間進(jìn)行權(quán)衡。提交模式由用戶可設(shè)置的參數(shù)synchronous_commit控制，它可以使用任何一種修改配置參數(shù)的方法進(jìn)行設(shè)置。一個事務(wù)真正使用的提交模式取決于當(dāng)事務(wù)提交開始時synchronous_commit的值。

特定的實用命令，如DROP TABLE，被強(qiáng)制按照同步提交而不考慮synchronous_commit的設(shè)定。這是為了確保服務(wù)器文件系統(tǒng)和數(shù)據(jù)庫邏輯狀態(tài)之間的一致性。支持兩階段提交的命令頁總是同步提交的，如PREPARE TRANSACTION。

如果數(shù)據(jù)庫在異步提交和事務(wù)WAL記錄寫入之間的風(fēng)險窗口期間崩潰，在該事務(wù)期間所作的修改將丟失。風(fēng)險窗口的持續(xù)時間是有限制的，因為一個后臺進(jìn)程（“WAL寫進(jìn)程”）每wal_writer_delay毫秒會把未寫入的 WAL記錄刷寫到磁盤。風(fēng)險窗口實際的最大持續(xù)時間是wal_writer_delay的3倍，因為WAL寫進(jìn)程被設(shè)計成傾向于在忙時一次寫入所有頁面。

異步提交提供的行為與配置fsync = off不同。fsync是一個服務(wù)器范圍的設(shè)置，它將會影響所有事務(wù)的行為。它禁用了PostgreSQL中所有嘗試同步寫入到數(shù)據(jù)庫不同部分的邏輯，并且因此一次系統(tǒng)崩潰（即，一個硬件或操作系統(tǒng)崩潰，不是PostgreSQL本身的失?。┛赡茉斐蓴?shù)據(jù)庫狀態(tài)的任意損壞。在很多情境中，帶來大部分性能提升的異步提交可以通過關(guān)閉 fsync來獲得，而且不會帶來數(shù)據(jù)損壞的風(fēng)險。

commit_delay也看起來很像異步提交，但它實際上是一種同步提交方法（事實上，commit_delay在異步提交時被忽略）。commit_delay會使事務(wù)在刷寫WAL到磁盤之前有一個延遲，它期望由一個這樣的事務(wù)所執(zhí)行的刷寫能夠也服務(wù)于其他同時提交的事務(wù)。該設(shè)置可以被看成是一種時間窗口，在其期間事務(wù)可以參與到一次單一的刷寫中，這種方式用于在多個事務(wù)之間攤銷刷寫的開銷。