您好,登錄后才能下訂單哦!
synchronous_commit參數(shù)怎么在postgresql中使用?相信很多沒有經(jīng)驗的人對此束手無策,為此本文總結(jié)了問題出現(xiàn)的原因和解決方法,通過這篇文章希望你能解決這個問題。
synchronous_commit
指定在命令返回”success”指示給客戶端之前,一個事務(wù)是否需要等待 WAL 記錄被寫入磁盤。
合法的值是{local,remote_write,remote_apply,on,off}
默認的并且安全的設(shè)置是on。
不同于fsync,將這個參數(shù)設(shè)置為off不會產(chǎn)生數(shù)據(jù)庫不一致性的風險:一個操作系統(tǒng)或數(shù)據(jù)庫崩潰可能會造成一些最近據(jù)說已提交的事務(wù)丟失,但數(shù)據(jù)庫狀態(tài)是一致的,就像這些事務(wù)已經(jīng)被干凈地中止。因此,當性能比完全確保事務(wù)的持久性更重要時,關(guān)閉synchronous_commit可以作為一個有效的代替手段。
這個參數(shù)可以隨時被修改;任何一個事務(wù)的行為由其提交時生效的設(shè)置決定。因此,可以同步提交一些事務(wù),同時異步提交其他事務(wù)。例如,當默認是相反時,實現(xiàn)一個單一多語句事務(wù)的異步提交,在事務(wù)中發(fā)出SET LOCAL synchronous_commit TO OFF。
on:
當數(shù)據(jù)庫提交事務(wù)時,wal先寫入 wal buffer 再寫入 wal 日志文件,設(shè)置成on表示提交事務(wù)時需等待本地wal寫入wal日志后才向客戶端返回成功。
on 為默認設(shè)置,數(shù)據(jù)庫非常安全,但性能有所損耗。
off:
當數(shù)據(jù)庫提交事務(wù)時不需要等待本地 wal buffer 寫入 wal 日志,隨即向客戶端返回成功,設(shè)置成off會給數(shù)據(jù)庫帶來一點風險:數(shù)據(jù)庫宕機時最新提交的少量事務(wù)可能丟失,數(shù)據(jù)庫重啟后會認為這些事務(wù)異常終止,會rollback。
適用對數(shù)據(jù)庫準確性要求不高同時追求數(shù)據(jù)庫性能的的場景。
local:
local含義和on類似,表示提交事務(wù)時需要等待本地wal寫入后才向客戶端返回成功。
on:
表示流復制主庫提交事務(wù)時,需等待備庫接收主庫發(fā)送的wal日志流并寫入wal文件,之后才向客戶端返回成功,簡單的說on表示本地wal已落盤,備庫的wal也已落盤,有兩份持久化的wal,但備庫此時還沒有完成重做。
這個選項帶來的事務(wù)響應時間較高。
remote_write:
表示流復制主庫提交事務(wù)時,需等待備庫接收主庫發(fā)送的wal日志流并寫入備節(jié)點操作系統(tǒng)緩存中,之后向客戶端返回成功,這種情況下備庫出現(xiàn)異常關(guān)閉時不會有已傳送的wal日志丟失風險,但備庫操作系統(tǒng)異常宕機就有已傳送的wal丟失風險了,此時wal可能還沒有完全寫入備節(jié)點wal文件中,簡單的說 remote_write 表示本地wal已落盤,備庫的wal還在備庫操作系統(tǒng)緩存中,也就是說只有一份持久化的wal。
這個選項帶來的事務(wù)響應時間較低。
remote_apply:
表示流復制主庫提交事務(wù)時,需等待備庫接收主庫發(fā)送的wal流并寫入wal文件,同時備庫已經(jīng)完成重做,之后才向客戶端返回成功,簡單的說remote_apply 表示本地wal已落盤,備庫wal已落盤并且已經(jīng)完成重做,這個設(shè)置保證了擁有兩份持久化的wal,同時備庫也已經(jīng)完成了重做。
這個選項帶來的事務(wù)響應時間最高。
補充:postgresql wal日志部分參數(shù)
fsync
fsync :控制wal日志刷新是否開啟刷新到磁盤,此參數(shù)控制wal_sync_method參數(shù)的刷新方法,如果fsync為off,則wal_sync_method的方法是沒有意義的,
如果沒開啟這個參數(shù),則可能由于wal日志塊沒有刷新到磁盤永久存儲而導致故障發(fā)生后實例出現(xiàn)塊折斷(oracle稱其為block curruption)
wal_sync_method
wal_sync_method :wal日志刷新方法,可選值為open_datasync/fdatasync/fsync/fsync_writethrough/open_sync
linux系統(tǒng)默認為fdatasync,以open開頭的在某些系統(tǒng)上不支持
wal_buffers
wal_buffers :wal緩沖區(qū),默認為-1,大小為1/32的shared_buffer,最小不少于64k,最大不大于一個wal_segment(默認16M大小),一般保持默認即可,因為過了wal_writer_delay(默認200ms)總會刷新清空此緩存,設(shè)置太大了也用不上.
wal_writer_delay
wal_writer_delay:前面已經(jīng)說過,這有點類似oracle和mysql的1s定時寫日志策略,每隔這么長時間就會刷wal日志緩沖區(qū)的數(shù)據(jù),然后sleep,到點后再刷,如此循環(huán)往復.
commit_delay
commit_delay :提交的延遲時間,如果設(shè)置了此參數(shù),則會commit后延遲一段時間再進行提交,此機制可以合并其他事務(wù)進而一起進行組提交,不過合并的事務(wù)數(shù)是有限制的,要至少有commit_siblings參數(shù)個事務(wù)等待提交的時候才會延遲,所有當有大量事務(wù)的時候會延遲,而如果事務(wù)很稀少就不會再被延遲了.
commit_siblings
commit_siblings :組提交個數(shù)的最少個數(shù),此參數(shù)上面已經(jīng)進行說明
看完上述內(nèi)容,你們掌握synchronous_commit參數(shù)怎么在postgresql中使用的方法了嗎?如果還想學到更多技能或想了解更多相關(guān)內(nèi)容,歡迎關(guān)注億速云行業(yè)資訊頻道,感謝各位的閱讀!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。