synchronous_commit

指定在命令返回”success”指示給客戶端之前，一個事務是否需要等待 WAL 記錄被寫入磁盤。

合法的值是{local,remote_write,remote_apply,on,off}

默認的并且安全的設置是on。

不同于fsync，將這個參數設置為off不會產生數據庫不一致性的風險：一個操作系統或數據庫崩潰可能會造成一些最近據說已提交的事務丟失，但數據庫狀態是一致的，就像這些事務已經被干凈地中止。因此，當性能比完全確保事務的持久性更重要時，關閉synchronous_commit可以作為一個有效的代替手段。

這個參數可以隨時被修改；任何一個事務的行為由其提交時生效的設置決定。因此，可以同步提交一些事務，同時異步提交其他事務。例如，當默認是相反時，實現一個單一多語句事務的異步提交，在事務中發出SET LOCAL synchronous_commit TO OFF。

單實例環境

on：

當數據庫提交事務時，wal先寫入 wal buffer 再寫入 wal 日志文件，設置成on表示提交事務時需等待本地wal寫入wal日志后才向客戶端返回成功。

on 為默認設置，數據庫非常安全，但性能有所損耗。

off：

當數據庫提交事務時不需要等待本地 wal buffer 寫入 wal 日志，隨即向客戶端返回成功，設置成off會給數據庫帶來一點風險：數據庫宕機時最新提交的少量事務可能丟失，數據庫重啟后會認為這些事務異常終止，會rollback。

適用對數據庫準確性要求不高同時追求數據庫性能的的場景。

local：

local含義和on類似，表示提交事務時需要等待本地wal寫入后才向客戶端返回成功。

流復制環境

on：

表示流復制主庫提交事務時，需等待備庫接收主庫發送的wal日志流并寫入wal文件，之后才向客戶端返回成功，簡單的說on表示本地wal已落盤，備庫的wal也已落盤，有兩份持久化的wal，但備庫此時還沒有完成重做。

這個選項帶來的事務響應時間較高。

remote_write：

表示流復制主庫提交事務時，需等待備庫接收主庫發送的wal日志流并寫入備節點操作系統緩存中，之后向客戶端返回成功，這種情況下備庫出現異常關閉時不會有已傳送的wal日志丟失風險，但備庫操作系統異常宕機就有已傳送的wal丟失風險了，此時wal可能還沒有完全寫入備節點wal文件中，簡單的說 remote_write 表示本地wal已落盤，備庫的wal還在備庫操作系統緩存中，也就是說只有一份持久化的wal。

這個選項帶來的事務響應時間較低。

remote_apply：

表示流復制主庫提交事務時，需等待備庫接收主庫發送的wal流并寫入wal文件，同時備庫已經完成重做，之后才向客戶端返回成功，簡單的說remote_apply 表示本地wal已落盤，備庫wal已落盤并且已經完成重做，這個設置保證了擁有兩份持久化的wal，同時備庫也已經完成了重做。

這個選項帶來的事務響應時間最高。

補充：postgresql wal日志部分參數

fsync

fsync ：控制wal日志刷新是否開啟刷新到磁盤,此參數控制wal_sync_method參數的刷新方法,如果fsync為off,則wal_sync_method的方法是沒有意義的,

如果沒開啟這個參數,則可能由于wal日志塊沒有刷新到磁盤永久存儲而導致故障發生后實例出現塊折斷(oracle稱其為block curruption)

wal_sync_method

wal_sync_method :wal日志刷新方法,可選值為open_datasync/fdatasync/fsync/fsync_writethrough/open_sync

linux系統默認為fdatasync,以open開頭的在某些系統上不支持

wal_buffers

wal_buffers :wal緩沖區,默認為-1,大小為1/32的shared_buffer,最小不少于64k,最大不大于一個wal_segment(默認16M大小),一般保持默認即可,因為過了wal_writer_delay(默認200ms)總會刷新清空此緩存，設置太大了也用不上.

wal_writer_delay

wal_writer_delay:前面已經說過,這有點類似oracle和mysql的1s定時寫日志策略,每隔這么長時間就會刷wal日志緩沖區的數據,然后sleep,到點后再刷，如此循環往復.

commit_delay

commit_delay :提交的延遲時間,如果設置了此參數,則會commit后延遲一段時間再進行提交,此機制可以合并其他事務進而一起進行組提交,不過合并的事務數是有限制的,要至少有commit_siblings參數個事務等待提交的時候才會延遲,所有當有大量事務的時候會延遲,而如果事務很稀少就不會再被延遲了.

commit_siblings

commit_siblings :組提交個數的最少個數,此參數上面已經進行說明

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持。如有錯誤或未考慮完全的地方，望不吝賜教。