轉發來源:html
https://www.jianshu.com/p/a37ceed648a8數據庫
https://www.cnblogs.com/daduxiong/archive/2010/09/30/1839533.html服務器
WAL:Write-Ahead Loggingoracle
爲何進入WAL?async
持久性是指,事務提交後,對系統的影響必須是永久的,即便系統意外宕機,也必須確保事務提交時的修改已真正永久寫入到永久存儲中。最簡單的實現方法,固然是在事務提交後當即刷新事務修改後的數據到磁盤。可是磁盤和內存之間的IO操做是最影響數據庫系統影響時間的,一有事務提交就去刷新磁盤,會對數據庫性能產生很差影響。性能
WAL機制的引入,即保證了事務持久性和數據完整性,又儘可能地避免了頻繁IO對性能的影響。日誌
WAL的概念就是對數據文件的改變(包括表和索引)必須先寫入日誌,即日誌記錄刷新到永久儲存以後,才能被寫。遵循這個過程,就不須要在每一個事務提交時都刷新數據頁到磁盤,由於在宕機時能夠用日誌來恢復數據庫:任何沒有應用到數據頁上的改動均可以根據日誌記錄重作。htm
WAL如何工做?blog
WAL機制實際是在這個寫數據的過程當中加入了對應的寫WAL log的過程,步驟同樣是先到Buffer,再刷新到Disk。索引
Change發生時:
- 先將變動後內容記入WAL Buffer
- 再將更新後的數據寫入Data Buffer
Commit發生時:
- WAL Buffer刷新到Disk
- Data Buffer寫磁盤推遲
Checkpoint發生時:
Change時:
Commit和Checkpoint時
WAL的好處?
使用WAL能夠顯著地減小寫磁盤的次數,由於只須要把日誌文件刷新到磁盤就能夠保證事務被提交,而不須要把事務改動過的每個數據文件都刷新到磁盤。日誌文件是連續寫的,因此同步log的花銷遠小於刷新數據頁的花銷。特別是服務器要處理涉及數據存儲不一樣部分的大量小事務時更是這樣。另外,當服務器在處理大量並行小事務時,log文件一次fsync就能夠提交多個事務。
WAL還使得在線備份和時間點恢復成爲可能。經過歸檔WAL數據,咱們能夠恢復到WAL數據覆蓋範圍內的任什麼時候間點:只需install一份數據庫的物理備份,並恢復WAL日誌到所需時間便可。更重要的是,這個物理備份並沒必要須是一個數據庫狀態的瞬時快照—若是一段時間的快照,那把WAL日誌也恢復成那一段時間的便可。
WAL的配置參數:
- fsync:該參數直接控制日誌是否先寫入磁盤。默認值是ON(先寫入)。開啓該值時代表,更新數據寫入磁盤時系統必須等待WAL的寫入完成。能夠配置該參數爲OFF,更新數據寫入磁盤徹底不用等待WAL的寫入完成,沒有了等待的時間,顯然接下來的工做可以更早的去作,節省了時間,提升了性能。其直接隱患是沒法保證在系統崩潰時最近的事務可以獲得恢復,也就沒法保證相關數據的真實與正確性。
- synchronous_commit:參數代表是否等待WAL完成後才返回給用戶事務的狀態信息。默認值是ON,代表必須等待WAL完成後才返回事務狀態信息。配置OFF值可以更快的反饋回事務狀態。因參數只是控制事務的狀態反饋,所以對於數據的一致性不存在風險。但事務的狀態信息影響着數據庫的整個狀態。該參數能夠靈活的配置,對於業務沒有嚴謹要求的事務能夠配置爲OFF,可以爲系統的性能帶來不小的提高。
- wal_sync_method:WAL寫入磁盤的控制方式,默認值是fsync。可選用值:open_datasync,fdatasync,fsync_writethrough,fsync,open_sync。
- full_page_writes:代表是否將整個page寫入WAL。
- wal_buffers:用於存放WAL數據的內存空間。系統默認值是64K,執行一個大的事務確定受到影響,應該適當的增大該參數。相似oracle中的log buffer。該參數還受如下幾個參數影響。
- wal_writer_delay:WAL writer進程的間歇時間。默認值是200ms。準確的配置應該根據自身系統的運行情況。若是時間過長可能形成WAL buffer的內存不足;反之太小將會引發WAL的不斷的寫入,對磁盤的IO也是很大考驗。
- commit_delay:表示了一個已經提交的數據在WAL buffer中存放的時間,單位ms,默認值是0,不用延遲。非0值表示可能存在多個事務的WAL同時寫入磁盤。若是設置爲非0,代表了某個事務執行commit後不會當即寫入WAL中,而仍存放在WAL buffer中,這樣對於後面的事務申請WAL buffer時很是不利,尤爲是提交事務較多的高峯期,可能引發WAL buffer內存不足。若是內存足夠大,能夠儘可能延長該參數值,可以使數據集中寫入這樣下降了系統的IO,提升了性能。一樣若是此時崩潰數據面臨着丟失的危險。我的建議採用默認值,同時將WAL文件存放在IO性能好的磁盤上。
- commit_siblings:該參數很是有意思,該參數還決定了commit_delay的有效性。系統默認值是5。表示當一個事務發出提交請求,此時數據庫中正在執行的事務數量大於5,則該事務將等待一段時間(commit_delay的值),反之,該事務則直接寫入WAL。