MySQL日志的知識點有哪些

本篇內(nèi)容主要講解“MySQL日志的知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“MySQL日志的知識點有哪些”吧!

索縣ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！

Mysql的日志系統(tǒng)是Mysql保證無論何時崩潰數(shù)據(jù)都不會丟失的關(guān)鍵

眾所周知Mysql是持久化的數(shù)據(jù)庫, 所有的數(shù)據(jù)都是持久化到硬盤中的, 保證數(shù)據(jù)不會丟失

Mysql保證數(shù)據(jù)不會丟失是從以下兩個方面來體現(xiàn)的

• 能夠恢復(fù)到任意時刻的數(shù)據(jù)狀態(tài)

• 無論在事務(wù)提交前還是提交后崩潰都能保證數(shù)據(jù)不丟失

事務(wù)過程中崩潰能夠恢復(fù)到事務(wù)提交前的狀態(tài)

事務(wù)提交后崩潰已提交的數(shù)據(jù)不會丟失

MySQL保證以上兩個點的關(guān)鍵就是通過 undo log, redo log 和 binlog 這三個日志來實現(xiàn)的, 接下來將逐一介紹

undo log 回滾日志

undo log是Mysql的回滾日志, 存儲的是老版本的數(shù)據(jù)

主要作用

存儲老版本的數(shù)據(jù)

配合Read View和隱藏字段實現(xiàn)了Mysql的快照讀

用于在事務(wù)執(zhí)行失敗的時候回滾到事務(wù)開始前的版本

undo log 有什么類型

undo log 有兩種類型

對于 insert 命令, undo log 記錄的是新增的記錄的主鍵, 在回滾的時候根據(jù) undo log 中的主鍵去刪除對應(yīng)的記錄即可

對于 update / delete 命令, undo log 記錄的是被修改的記錄的舊數(shù)據(jù)

Mysql中的每一行數(shù)據(jù)都有一個最新修改當(dāng)前數(shù)據(jù)行的事務(wù)id和回滾指針這兩個字段, 當(dāng)對數(shù)據(jù)行進(jìn)行修改之后, undo log指針就會指向舊的這一行數(shù)據(jù), 而新生成的這一行數(shù)據(jù)的回滾指針就會指向undo log指針當(dāng)前指向的舊數(shù)據(jù)行

• Mysql為了避免undo log指針修改指向的時候出現(xiàn)并發(fā)問題, 在修改之前會對undo log指針增加排他鎖以保證undo log的正確寫入

undo log 什么時候刪除

undo log是用于保證事務(wù)在未提交的時候可以順利回滾到事務(wù)開始前的狀態(tài), 當(dāng)事務(wù)提交之后undo log就失去作用了, 就需要被刪除

undo log是交由Mysql中的 Purage 線程來負(fù)責(zé)刪除的, purage會定期檢查undo log中的deleted_bit 標(biāo)志, 這個標(biāo)志會在事務(wù)提交后被設(shè)置為true, purage 線程發(fā)現(xiàn)為true的記錄就會負(fù)責(zé)將其刪除

redo log 重做日志

redo log是Mysql的物理日志, 負(fù)責(zé)記錄某個數(shù)據(jù)頁執(zhí)行了什么樣的操作

redo log 的作用

• 負(fù)責(zé)記錄提交的事務(wù)對數(shù)據(jù)的修改, 記錄的內(nèi)容大概就是對x表的y頁z偏移做了a更新

• 讓Mysql在提交事務(wù)的時候無需等待數(shù)據(jù)持久化磁盤, 只需要將redo log持久化到磁盤就可以了

• 未清除的redo log的數(shù)量標(biāo)識了未刷盤的臟頁數(shù)量

為什么提交事務(wù)是選擇持久化redo log, 而不是持久化數(shù)據(jù)到磁盤

持久化數(shù)據(jù)到磁盤是隨機(jī)IO過程, 所以Mysql選擇將數(shù)據(jù)緩存起來, 等待一個合適的時機(jī)將數(shù)據(jù)一次性寫入磁盤, 減少IO

但是數(shù)據(jù)緩存在內(nèi)存中有丟失的風(fēng)險, 所以Mysql選擇將redo log持久化

redo log是順序?qū)? 持久化的效率比隨機(jī)寫的效率要高, 并且redo log記錄了數(shù)據(jù)的變化情況, 只要redo log在就可以保證在Mysql重啟后恢復(fù)數(shù)據(jù)

在InnoDB中, redo log是一個固定大小的類似循環(huán)隊列的存在, 每次寫入都從后面write pos的位置, 在持久化數(shù)據(jù)的時候就移動check point往前讀取

這樣設(shè)計的原因是因為redo log是防止Mysql崩潰后緩存的臟頁數(shù)據(jù)丟失而存在的

當(dāng)Mysql中的數(shù)據(jù)被持久化到磁盤中后, 被持久化部分的redo log其實就沒有用了, 就可以騰出空間來記錄新的數(shù)據(jù)

undo log 和 redo log 的區(qū)別

undo log記錄的是事務(wù)執(zhí)行過程中舊數(shù)據(jù)的狀態(tài), redo log記錄的是數(shù)據(jù)更新之后的狀態(tài)

redo log其實保障的是事務(wù)的持久性和一致性，而undo log則保障了事務(wù)的原子性

binlog 歸檔日志

binlog是Mysql server層實現(xiàn)的日志, 是所有引擎通用的

作用

binlog記錄的是mysql原始的語句邏輯, 并且是采用追加寫入的形式記錄的, 所以可以用于恢復(fù)mysql在任意時刻的數(shù)據(jù)庫數(shù)據(jù)狀態(tài)

所以叫binlog是歸檔日志

同時binlog也是Mysql實現(xiàn)主從復(fù)制的依賴, 從庫通過從主庫中復(fù)制binlog回放來同步主庫的數(shù)據(jù)狀態(tài)

定義

先寫日志到磁盤中, 再寫數(shù)據(jù)到磁盤中Mysql的寫操作不是立刻寫入到磁盤中的, 而是先寫日志, 保證redo log和binlog都持久化到磁盤中再由后臺線程選擇時機(jī)將數(shù)據(jù)持久化到硬盤的

為什么要先寫日志到磁盤中

因為刷臟頁是一個隨機(jī)讀寫的過程, 持久化到磁盤中的速度肯定沒有redo log | binlog這些順序?qū)懙乃俣瓤? 所以選擇先在內(nèi)存中對數(shù)據(jù)進(jìn)行修改, 再后期選擇時機(jī)異步持久化到磁盤中

所以在臟頁還未刷入磁盤中的這段時間就由redo log | binlog來保證數(shù)據(jù)的持久化, 防止斷電重啟等情況內(nèi)存中的數(shù)據(jù)丟失

當(dāng)臟頁滿的時候需要將臟頁寫入到磁盤再淘汰, 為何不全部淘汰掉下次使用的時候再通過redo log來恢復(fù)呢

從性能方面考慮的, 如果每次從磁盤中讀取數(shù)據(jù)到內(nèi)存都需要和redo log比對更新, 效率很低

MySQL刷臟頁寫入到磁盤保證了數(shù)據(jù)頁只要在內(nèi)存中, 就肯定是當(dāng)前最新的數(shù)據(jù)可以返回

如果內(nèi)存中沒有數(shù)據(jù)只要從磁盤中讀取肯定能得到最新的正確數(shù)據(jù), 而不用再去同redo log進(jìn)行比對

binlog和redo log的寫入過程 - WAL機(jī)制的基本保證

binlog和redo log都是將日志寫入劃分為三個過程 寫入cache, write和sync

在事務(wù)執(zhí)行過程中會將binlog和redo log寫入到對應(yīng)分配的緩存中, 以便在事務(wù)提交的時候一次性寫入到磁盤中

在事務(wù)提交的時候會先進(jìn)行write將數(shù)據(jù)寫入到操作系統(tǒng)的頁緩存中, 此時數(shù)據(jù)還未真正寫入文件, 但是已經(jīng)是交由操作系統(tǒng)的緩存來保管了, 如果此時Mysql進(jìn)程崩潰這部分寫入的數(shù)據(jù)也不會丟失, 操作系統(tǒng)的內(nèi)核線程會負(fù)責(zé)將這部分緩存中的數(shù)據(jù)寫入磁盤

• 但是如果操作系統(tǒng)崩潰了這部分?jǐn)?shù)據(jù)就丟失了

最后就是mysql手動調(diào)用sync將寫入在頁緩存中的數(shù)據(jù)持久化到硬盤, 寫入完成后數(shù)據(jù)就是持久化成功了

最后的write和sync步驟mysql提供了對應(yīng)的參數(shù)來控制寫入策略

redo log是通過innodb_flush_log_at_trx_commit來控制的

• 設(shè)置為 0 的時候，表示每次事務(wù)提交時都只是把redo log留在redo log的緩存中

丟失風(fēng)險最大

• 設(shè)置為 1 的時候，表示每次事務(wù)提交時都將redo log直接持久化到磁盤

丟失風(fēng)險最小, 但是IO占用大

• 設(shè)置為 2 的時候，表示每次事務(wù)提交時都只是把redo log寫到page cache

IO占用居中, 將寫入到磁盤這個最占用IO的過程交由操作系統(tǒng)來負(fù)責(zé)

binlog是通過參數(shù)sync_binlog來控制的

• sync_binlog=0 的時候，表示每次提交事務(wù)都只 write，不 fsync

• sync_binlog=1 的時候，表示每次提交事務(wù)都會執(zhí)行 fsync

• sync_binlog=N(N>1) 的時候，表示每次提交事務(wù)都 write，但累積 N 個事務(wù)后才 fsync

兩階段日志提交

什么是兩階段日志提交

將redo log日志提交的過程分為prepare和commit這兩個階段, binlog日志提交在這兩個階段中間

事務(wù)提交時redo log先提交后進(jìn)入prepare狀態(tài), 然后binlog提交完成后redo log才能將日志的狀態(tài)修改為commit已提交

為什么需要兩階段日志提交

和InnoDB引擎的回滾機(jī)制有關(guān), InnoDB的redo log提交了事務(wù)就無法回滾了, 如果在redo log提交后binlog寫入失敗的話就會出現(xiàn)兩份不統(tǒng)一的情況

如果此時數(shù)據(jù)庫異常重啟的話要依據(jù)那一份來恢復(fù)數(shù)據(jù)就值得思考了, 所以才需要兩階段日志提交

假設(shè)現(xiàn)在在時刻A數(shù)據(jù)庫崩潰的話, 因為binlog還未寫入, redo log還未提交, 所以重啟后事務(wù)會回滾, 兩份日志依舊是統(tǒng)一狀態(tài)

如果是時間段B的話, 就需要對redo log的提交標(biāo)志進(jìn)行判斷了, 在查詢redo log中是否有commit提交標(biāo)志, 如果有的話事務(wù)沒有問題, 直接提交

• 如果redo log中沒有對應(yīng)事務(wù)的提交標(biāo)志的話會對binlog進(jìn)行檢查

• 如果binlog完整并且?guī)в衏ommit標(biāo)志, 就會提交事務(wù)并在redo log后面補(bǔ)上commit標(biāo)志如果binlog不完整就回滾事務(wù)

這里可以發(fā)現(xiàn)兩階段日志提交中發(fā)生了崩潰是依據(jù)binlog來進(jìn)行標(biāo)準(zhǔn)判斷的, 原因是因為主從復(fù)制是依據(jù)binlog來進(jìn)行的

如果對兩份日志都需要檢查完整性的話, 主庫掛掉切換到從庫的時間會變長, 以binlog為基準(zhǔn)的話主庫掛了直接拿著binlog去從庫恢復(fù)數(shù)據(jù)即可, 無需檢查redo log的完整性

此外binlog是Mysql Server層的通用日志, 這也是選擇binlog作為基準(zhǔn)的原因

兩階段日志提交的缺點

• 磁盤IO次數(shù)高

在提交日志的時候會有redo log和binlog對應(yīng)的刷盤操作, IO次數(shù)高

• 鎖競爭激烈

為了保證多個事務(wù)提交的時候日志的記錄和事務(wù)的提交順序是一致的, 會使用鎖來保證日志提交的相對順序

但是在并發(fā)量大的情況下性能會變差

組提交機(jī)制

組提交機(jī)制的作用

當(dāng)有躲過事務(wù)提交的時候, 將多個事務(wù)的日志合并在一起去寫入, 減少磁盤IO操作

組提交機(jī)制的實現(xiàn)

組提交機(jī)制將commit過程拆分成三個過程, 對每個過程都維護(hù)了一個隊列, 并且通過鎖來保證事務(wù)的寫入順序

• 分成三個階段分別加鎖可以減少鎖粒度, 無需鎖住事務(wù)的整個提交過程

當(dāng)隊列為空的時候第一個進(jìn)入隊列的事務(wù)會成為后續(xù)進(jìn)入的事務(wù)的領(lǐng)導(dǎo)者, 帶領(lǐng)后續(xù)事務(wù)完成接下來的階段操作

階段一 : flush階段 : 多個事務(wù)按進(jìn)入的順序?qū)inlog從cache中寫入文件 (不刷盤)

第一個進(jìn)入flush階段的事務(wù)會作為領(lǐng)導(dǎo)者領(lǐng)導(dǎo)后面進(jìn)入的事務(wù)

領(lǐng)導(dǎo)者事務(wù)會帶領(lǐng)所有的事務(wù)對 redo log 進(jìn)行一次 write + fsync, 也就是將redo log 寫入磁盤, 完成redo log 的propare階段

如果在這個階段Mysql崩潰了, 會在重啟后回滾這組事務(wù)

階段二 : sync : 對binlog文件做fsync操作 (將多個事務(wù)的binlog合并一起刷盤)

在flush階段將binlog寫入到binlog文件后, 會等待一段時間再進(jìn)行刷盤, 目的是組合更多事務(wù)的binlog一起刷盤減少消耗

等待會有時間限制和最大事務(wù)限制, 滿足其中一個條件就會立刻對binlog進(jìn)行刷盤

sync階段主要負(fù)責(zé)binlog的組提交, 如果當(dāng)前階段Mysql崩潰的話, 在重啟后可以通過redo log的刷盤記錄繼續(xù)完成事務(wù)提交

• 因為此時binlog已經(jīng)完成提交了, 所以可以根據(jù)redo log來繼續(xù)提交事務(wù)

階段三 : commit : 對各個事務(wù)做InnoDB的commit操作

到此，相信大家對“MySQL日志的知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

文章標(biāo)題：MySQL日志的知識點有哪些
文章轉(zhuǎn)載：http://bm7419.com/article12/pssigc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供用戶體驗、品牌網(wǎng)站設(shè)計、域名注冊、靜態(tài)網(wǎng)站、做網(wǎng)站、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)