知識(shí)點(diǎn)

1 語句執(zhí)行依次經(jīng)過 : 連接器 , 分析器 , 優(yōu)化器 ,執(zhí)行器(操作引擎) , 然后進(jìn)入存儲(chǔ)引擎
2 redo log 和 bin log 的設(shè)計(jì)思路可以用到自己的程序里
3 redo log 類似粉板 , 先記賬 , 不忙的時(shí)候再記到本子上(磁盤) , 因?yàn)楹笳哌€需要去一頁一頁翻找到對(duì)應(yīng)人的記錄再進(jìn)行修改 , 速度慢 , 對(duì)應(yīng)到磁盤就是 IO 成本高
4 粉板和賬本 = Write-Ahead Logging , 先寫日志再寫磁盤
5 粉板空間有限 , 如果滿了則需要放下手上的工作 ,先把一部分寫到賬本里
6 redo log 固定大小的一組文件 , 類似一個(gè)循環(huán)隊(duì)列的寫法 ,

image.png

7 redo log 保證了 crash safe , 因?yàn)槭菍懺谖募锏?br> 8 binlog是 server 層的日志 , 沒有 crash-safe 能力 , 為何? 我的猜測(cè)是 binlog 沒有事務(wù)提交 , redo log 則有兩階段提交 , 如果崩潰了事務(wù)就回滾了 , 數(shù)據(jù)和 redo log 都保證了一致 , 而 binlog 很可能已經(jīng)寫入數(shù)據(jù)庫,但是 binlog 沒有記錄
9 redo log 只有 innodb 有 , binlog 所有引擎都可以用
10 redo log 記錄在數(shù)據(jù)也上做了什么修改 , binlog 記錄執(zhí)行語句 或 ROW(變化前和后的都會(huì)記)
11 redo 是循環(huán)寫 , binlog 是一直追加寫
12 先更新內(nèi)存里該行的數(shù)據(jù) , 同時(shí)寫 redo log prepare , 然后寫 binlog ,然后 redo log 提交

14 誤刪恢復(fù) : 用全量備份恢復(fù)到某個(gè)點(diǎn) , 然后取出從該點(diǎn)開始的 binlog 進(jìn)行重放 , 然后從臨時(shí)庫按需恢復(fù)到線上庫
13 兩階段提交 ? 目前理解為一個(gè)原子事務(wù) , 只有binlog小弟同意并成功了,才會(huì)通知老大redo log提交
15 兩階段提交 , 我的理解是 其實(shí)就是保證了 redo log 和 binlog 寫的原子性 , 保證了一致
16 擴(kuò)容讀庫方法 : 全量+binlog
17 參數(shù) innodb_flush_log_at_trx_commit=1 , 每次 redo log 直接寫磁盤 , 保證異常重啟數(shù)據(jù)不丟 sync_binlog=1 一樣的道理
18 兩階段提交在日常開發(fā)中可能也用得到
19 問題: 全量備份 , 什么場(chǎng)景 一天一備 比 一周一備份 更有優(yōu)勢(shì) ? 影響力數(shù)據(jù)庫系統(tǒng)的哪個(gè)指標(biāo)?
問題不太好 , 如果要使用到全量恢復(fù)的話 , 一天一備可以應(yīng)用比較少的 binlog , 一周一備最壞情況要應(yīng)用一周的 binlog
20 留言里的討論還沒看? 評(píng)論 留言可以當(dāng)做測(cè)試用例 看提問自己能不能解答