Find N3入網：最高支持16+1TB
OPPO將于近期登場的Find N3折疊屏目前已經正式入網，型號為PHN110。本次Find N3在外觀方面相比前兩代有很大的變化，不再是小號的橫向折疊屏，而是跟別的廠商一樣采用了較為常見的
上一篇《刷盤，還是不刷盤，是一個問題》中我們遇到了哪些問題？
(1) 已提交事務+未提交事務的ACID特性怎么保證？
畫外音：上一篇中遇到的問題，主要是原子性與持久性。
(2) 數據庫崩潰，怎么實施故障恢復？
(3) 每次都刷盤隨機寫，性能低，怎么提高數據庫性能？
畫外音：正常情況下，不需要每個事務提交，都進行刷盤。
要提升隨機寫性能，最容易想到的，就是利用高性能的順序寫日志，記錄事務中的一些信息，來實現已提交事務的數據“要刷盤”，未提交事務的數據“不刷盤”，以及實現故障恢復。
事務中，對數據庫的寫操作。
每條日志記錄會有一個遞增的日志序列號（log sequence number，LSN），唯一標識一條日志記錄。
還有一種特殊的日志記錄，叫檢查點（checkpoint）。
檢查點記錄了某一個時刻，緩沖池（buffer pool）中所有數據頁（page）的狀態信息。
有了檢查點和順序寫日志，我們就可以通過：
來解決，上面提到的三大難題。
這，就是我們今天要聊的核心技術，預寫日志（write-ahead logging，WAL）。
預寫日志不僅僅是一種日志，更像是一種模式，一種協議，它要求在進行數據寫入操作時，必須先寫入操作日志。
如同數據的內存-磁盤兩層結構一樣，為了提升性能，預寫日志也分為內存-磁盤兩層結構：
還是之前那個事務T1：
開始事務
預寫日志首先會記錄，T1事務開始：
LSN=0:<T1, BEGIN>
讀取A的值是一個讀操作，不需要進行記錄。
修改記錄A的值是一個寫操作，需要進行記錄，而且要記錄修改前的值，與修改后的值，類似于：
LSN=1:<T1, A, 1, 2>
以方便未來進行redo與undo（如上圖中的屎黃色1）。
接下來，事務會對緩沖池中的數據進行修改（如上圖中的屎黃色2）。
到目前為止，預寫日志都還是寫在buffer中，并沒有刷到磁盤上。
首先，T1事務提交，也會記錄到buffer中：
LSN=2:<T1, COMMIT>
但這樣，還遠遠不夠。
預寫日志，必須全部從buffer里刷到磁盤上，也就是日志文件中，事務才能標記上“已提交”，并返回給應用程序。
沒錯，只要預寫日志從buffer刷到磁盤，而不需要數據從buffer刷到磁盤，就能返回應用程序，事務提交成功。
至于數據什么時候從buffer刷回磁盤，這取決于緩沖池刷盤策略，例如：隔一段時間異步刷盤（如上圖中的屎黃色便簽）。
這，就是預寫日志的核心思路。
(1) 日志序列號（log sequence number，LSN），唯一標識一條日志記錄，遞增；
(2) 檢查點（checkpoint），記錄了某一個時刻，緩沖池（buffer pool）中所有數據頁（page）的狀態信息。
(3) 預寫日志記錄什么核心信息？
(4) 數據庫何時能向應用程序返回“事務成功”？
預寫日志刷盤成功之后。
(5) 上一篇《刷盤，還是不刷盤，是一個問題》結尾的問題：在數據庫返回應用程序事務成功之前，要不要將數據刷回磁盤？
只要有預寫日志機制，只需要預寫日志刷盤，不需要數據刷盤。
新的場景出現了：如果數據庫崩了，怎么利用檢查點（checkpoint）以及預寫日志，來進行刷盤和數據恢復呢？讓你來設計，你會怎么做？
本文鏈接：http://www.tebozhan.com/showinfo-26-98559-0.html一分鐘了解，預寫日志 WAL 的核心思路...
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號