?
This document uses PHP Chinese website manual Release
異步提交是一個可以加快速事務(wù)完成的選項,如果數(shù)據(jù)庫崩潰時,最新的信息可能會丟失。 在大多數(shù)應(yīng)用中這個是均衡的。
在前一個章節(jié)的描述,事務(wù)提交一般是同步的:在對客戶端成功運行一個指示之前, 服務(wù)器等待事務(wù)的WAL記錄對存儲的刷新。即使在服務(wù)器崩潰后, 客戶端依然會保證報告提交的事務(wù)將會保存。盡管,對于簡短的事務(wù),延遲對與整個 事務(wù)時間來說是一個主要的部分。選擇異步提交模式意味著,在其產(chǎn)生WAL記錄成功轉(zhuǎn)到磁盤之前, 一旦事務(wù)在邏輯上完成后服務(wù)端將會返回成功。這樣對事務(wù)的吞吐量可以提供一個顯著的提高。
異步提交介紹了數(shù)據(jù)丟失的風(fēng)險。這是在向客戶端報告事務(wù)完成的時間點和實際執(zhí)行客戶端的時間點之間的一個很小的時間窗口 (即,保證如果服務(wù)器崩潰時不會丟失)。因此如果客戶端采取外部動作(前提是假設(shè)事務(wù)會被記下),此時不應(yīng)使用異步提交。 例如,一個銀行肯定不會為一個ATM分配現(xiàn)金的事務(wù)使用異步提交。但在多數(shù)情況下,如事件日志記錄,不需要這種強力保證。
使用異步提交的風(fēng)險在于數(shù)據(jù)丟失,而不是數(shù)據(jù)損壞。如果數(shù)據(jù)庫崩潰,那么它會根據(jù)刷入的最新的WAL記錄來進行恢復(fù)。 因此數(shù)據(jù)庫會被轉(zhuǎn)儲到一個自我意志狀態(tài),但任何沒有寫入到磁盤的事務(wù)不會被注入到這個狀態(tài)。因此最后的結(jié)果時丟失最新的幾個事務(wù)。 因為事務(wù)是以提交的順序進行重新執(zhí)行,不會引入非一致狀態(tài);例如,如果事務(wù)B所做的更改依賴于前一個事務(wù)A,那么丟失A的效果,而B的效果被保留是不可能的。
用戶可以為每個事務(wù)選擇提交模式,因此可以同時使用同步和異步提交事務(wù)。 這樣就允許在性能和事務(wù)持久性之間做一個靈活的權(quán)衡。提交模式是由synchronous_commit控制的。 用于任意一個事務(wù)的模式依賴于事務(wù)提交開始時synchronous_commit的值。
某些公用命令,如DROP TABLE,會強制使用同步提交,無論synchronous_commit參數(shù)是怎么設(shè)置的。 這是為了保證服務(wù)器文件系統(tǒng)和數(shù)據(jù)庫邏輯狀態(tài)之間的一致性。支持兩階段提交的命令,如PREPARE TRANSACTION, 也是使用同步提交。
如果在一個異步提交和寫WAL事務(wù)記錄時發(fā)生數(shù)據(jù)庫崩潰, 此時在事務(wù)期間的修改會丟失。風(fēng)險的持續(xù)時間會被限制,因為"WAL writer"后臺進程會 每隔wal_writer_delay毫秒就向磁盤刷入未寫入的WAL記錄。 風(fēng)險的實際最大持續(xù)時間是三倍的wal_writer_delay,因為WAL寫進程被設(shè)計為支持在繁忙時 一次寫入所有塊。
Caution |
IMMEDIATE模式的關(guān)閉等同于服務(wù)器崩潰,因此會造成哪些未刷入的異步提交的數(shù)據(jù)丟失。 |
異步提交不同于設(shè)置fsync = off。 fsync是一個用于更改所有事物的行為的服務(wù)器端設(shè)置。 它會禁用PostgreSQL中嘗試向數(shù)據(jù)庫不同部分同步寫入的邏輯, 因此,一次系統(tǒng)崩潰(停電或操作系統(tǒng)崩潰,而不是PostgreSQL本身出問題)會導(dǎo)致 數(shù)據(jù)庫狀態(tài)不可預(yù)知的崩潰。在多數(shù)情況下,通過關(guān)閉fsync,異步提交會提高性能, 不會有數(shù)據(jù)崩潰的風(fēng)險。
看起來,commit_delay與異步提交很相似,但實際上它是一種異步提交方法 (事實上,異步提交時會忽略commit_delay)。 在一次異步提交嘗試向磁盤刷入WAL之前,commit_delay會造成延遲, 希望在一個這樣的事務(wù)中執(zhí)行一個單獨的刷入可以用于同一時間的其他事務(wù)提交。 當(dāng)存在不一致提交事務(wù)時,設(shè)置commit_delay也是有用的, 很難調(diào)整到一個實際上是幫助而不是傷害吞吐量的值。