當(dāng)前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

MySQL三大日志及主从复制的原理

發(fā)布時(shí)間：2024/4/11 数据库 36 豆豆

生活随笔收集整理的這篇文章主要介紹了 MySQL三大日志及主从复制的原理小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

MySQL三大日志及主從復(fù)制的原理

文章目錄

MySQL三大日志及主從復(fù)制的原理
- 一、binlog
- - 1.概念
  - 2.分類
  - 3.binlog使用場(chǎng)景
  - 4.binlog刷盤時(shí)機(jī)
  - 5.binlog日志格式
- 二、redo log
- - 1.為什么需要redo log
  - 2.redo log基本概念
  - 3.redo log記錄形式
  - 4.redo log與binlog區(qū)別
- 三、undo log
- 四、主從復(fù)制的原理
- - 1.什么是主從復(fù)制?
  - 2.主從復(fù)制的作用
  - 3.主從復(fù)制的原理
  - 4.總結(jié)

日志是mysql數(shù)據(jù)庫的重要組成部分，記錄著數(shù)據(jù)庫運(yùn)行期間各種狀態(tài)信息。

mysql日志主要包括錯(cuò)誤日志、查詢?nèi)罩尽⒙樵內(nèi)罩尽⑹聞?wù)日志、二進(jìn)制日志幾大類。

作為開發(fā)，我們重點(diǎn)需要關(guān)注的是二進(jìn)制日志(binlog)和事務(wù)日志(包括redo log和undo log)。

一、binlog

1.概念

binlog用于記錄數(shù)據(jù)庫執(zhí)行的寫入性操作(不包括查詢)信息，以二進(jìn)制的形式保存在磁盤中。binlog是mysql的邏輯日志，并且由Server層進(jìn)行記錄，使用任何存儲(chǔ)引擎的mysql數(shù)據(jù)庫都會(huì)記錄binlog日志。

2.分類

邏輯日志：可以簡(jiǎn)單理解為記錄的就是sql語句。
物理日志：因?yàn)閙ysql數(shù)據(jù)最終是保存在數(shù)據(jù)頁中的，物理日志記錄的就是數(shù)據(jù)頁變更。
binlog是通過追加的方式進(jìn)行寫入的，可以通過max_binlog_size參數(shù)設(shè)置每個(gè)binlog文件的大小，當(dāng)文件大小達(dá)到給定值之后，會(huì)生成新的文件來保存日志。

3.binlog使用場(chǎng)景

在實(shí)際應(yīng)用中，binlog的主要使用場(chǎng)景有兩個(gè)，分別是主從復(fù)制和數(shù)據(jù)恢復(fù)。

主從復(fù)制：在Master端開啟binlog，然后將binlog發(fā)送到各個(gè)Slave端，Slave端重放binlog從而達(dá)到主從數(shù)據(jù)一致。
數(shù)據(jù)恢復(fù)：通過使用mysqlbinlog工具來恢復(fù)數(shù)據(jù)。

4.binlog刷盤時(shí)機(jī)

對(duì)于InnoDB存儲(chǔ)引擎而言，只有在事務(wù)提交時(shí)才會(huì)記錄biglog，此時(shí)記錄還在內(nèi)存中，那么biglog是什么時(shí)候刷到磁盤中的呢？mysql通過sync_binlog參數(shù)控制biglog的刷盤時(shí)機(jī)，取值范圍是0-N：

0：不去強(qiáng)制要求，由系統(tǒng)自行判斷何時(shí)寫入磁盤；
1：每次commit的時(shí)候都要將binlog寫入磁盤；
N：每N個(gè)事務(wù)，才會(huì)將binlog寫入磁盤。

從上面可以看出，sync_binlog最安全的是設(shè)置是1，這也是MySQL 5.7.7之后版本的默認(rèn)值。但是設(shè)置一個(gè)大一些的值可以提升數(shù)據(jù)庫性能，因此實(shí)際情況下也可以將值適當(dāng)調(diào)大，犧牲一定的一致性來獲取更好的性能。

5.binlog日志格式

binlog日志有三種格式，分別為STATMENT、ROW和MIXED。

在 MySQL 5.7.7之前，默認(rèn)的格式是STATEMENT，MySQL 5.7.7之后，默認(rèn)值是ROW。日志格式通過binlog-format指定。

STATMENT
基于SQL語句的復(fù)制(statement-based replication, SBR)，每一條會(huì)修改數(shù)據(jù)的sql語句會(huì)記錄到binlog中。
優(yōu)點(diǎn)：不需要記錄每一行的變化，減少了binlog日志量，節(jié)約了IO, 從而提高了性能；
缺點(diǎn)：在某些情況下會(huì)導(dǎo)致主從數(shù)據(jù)不一致，比如執(zhí)行sysdate()、slepp()等。
ROW
基于行的復(fù)制(row-based replication, RBR)，不記錄每條sql語句的上下文信息，僅需記錄哪條數(shù)據(jù)被修改了。
優(yōu)點(diǎn)：不會(huì)出現(xiàn)某些特定情況下的存儲(chǔ)過程、或function、或trigger的調(diào)用和觸發(fā)無法被正確復(fù)制的問題；
缺點(diǎn)：會(huì)產(chǎn)生大量的日志，尤其是alter table的時(shí)候會(huì)讓日志暴漲
MIXED
基于STATMENT和ROW兩種模式的混合復(fù)制(mixed-based replication, MBR)，一般的復(fù)制使用STATEMENT模式保存binlog，對(duì)于STATEMENT模式無法復(fù)制的操作使用ROW模式保存binlog

二、redo log

1.為什么需要redo log

我們都知道，事務(wù)的四大特性里面有一個(gè)是持久性，具體來說就是只要事務(wù)提交成功，那么對(duì)數(shù)據(jù)庫做的修改就被永久保存下來了，不可能因?yàn)槿魏卧蛟倩氐皆瓉淼臓顟B(tài)。
那么mysql是如何保證一致性的呢？最簡(jiǎn)單的做法是在每次事務(wù)提交的時(shí)候，將該事務(wù)涉及修改的數(shù)據(jù)頁全部刷新到磁盤中。
但是這么做會(huì)有嚴(yán)重的性能問題，主要體現(xiàn)在兩個(gè)方面：
因?yàn)镮nnodb是以頁為單位進(jìn)行磁盤交互的，而一個(gè)事務(wù)很可能只修改一個(gè)數(shù)據(jù)頁里面的幾個(gè)字節(jié)，這個(gè)時(shí)候?qū)⑼暾臄?shù)據(jù)頁刷到磁盤的話，太浪費(fèi)資源了！
一個(gè)事務(wù)可能涉及修改多個(gè)數(shù)據(jù)頁，并且這些數(shù)據(jù)頁在物理上并不連續(xù)，使用隨機(jī)IO寫入性能太差！

因此mysql設(shè)計(jì)了redo log，具體來說就是只記錄事務(wù)對(duì)數(shù)據(jù)頁做了哪些修改，這樣就能完美地解決性能問題了(相對(duì)而言文件更小并且是順序IO)。

2.redo log基本概念

redo log包括兩部分：一個(gè)是內(nèi)存中的日志緩沖(redo log buffer)，另一個(gè)是磁盤上的日志文件(redo log file)。
mysql每執(zhí)行一條DML語句，先將記錄寫入redo log buffer，后續(xù)某個(gè)時(shí)間點(diǎn)再一次性將多個(gè)操作記錄寫到redo log file。這種先寫日志，再寫磁盤的技術(shù)就是MySQL里經(jīng)常說到的WAL(Write-Ahead Logging) 技術(shù)。
在計(jì)算機(jī)操作系統(tǒng)中，用戶空間(user space)下的緩沖區(qū)數(shù)據(jù)一般情況下是無法直接寫入磁盤的，中間必須經(jīng)過操作系統(tǒng)內(nèi)核空間(kernel space)緩沖區(qū)(OS Buffer)。
因此，redo log buffer寫入redo log file實(shí)際上是先寫入OS Buffer，然后再通過系統(tǒng)調(diào)用fsync()將其刷到redo log file中，過程如下：
mysql支持三種將redo log buffer寫入redo log file的時(shí)機(jī)，可以通過innodb_flush_log_at_trx_commit參數(shù)配置，各參數(shù)值含義如下：

3.redo log記錄形式

前面說過，redo log實(shí)際上記錄數(shù)據(jù)頁的變更，而這種變更記錄是沒必要全部保存，因此redo log實(shí)現(xiàn)上采用了大小固定，循環(huán)寫入的方式，當(dāng)寫到結(jié)尾時(shí)，會(huì)回到開頭循環(huán)寫日志。如下圖：
同時(shí)我們很容易得知，在innodb中，既有redo log需要刷盤，還有數(shù)據(jù)頁也需要刷盤，redo log存在的意義主要就是降低對(duì)數(shù)據(jù)頁刷盤的要求。
在上圖中，write pos表示redo log當(dāng)前記錄的LSN(邏輯序列號(hào))位置，check point表示數(shù)據(jù)頁更改記錄刷盤后對(duì)應(yīng)redo log所處的LSN(邏輯序列號(hào))位置。
write pos到check point之間的部分是redo log空著的部分，用于記錄新的記錄；
check point到write pos之間是redo log待落盤的數(shù)據(jù)頁更改記錄。
當(dāng)write pos追上check point時(shí)，會(huì)先推動(dòng)check point向前移動(dòng)，空出位置再記錄新的日志。
啟動(dòng)innodb的時(shí)候，不管上次是正常關(guān)閉還是異常關(guān)閉，總是會(huì)進(jìn)行恢復(fù)操作。因?yàn)閞edo log記錄的是數(shù)據(jù)頁的物理變化，因此恢復(fù)的時(shí)候速度比邏輯日志(如binlog)要快很多。
重啟innodb時(shí)，首先會(huì)檢查磁盤中數(shù)據(jù)頁的LSN，如果數(shù)據(jù)頁的LSN小于日志中的LSN，則會(huì)從checkpoint開始恢復(fù)。
還有一種情況，在宕機(jī)前正處于checkpoint的刷盤過程，且數(shù)據(jù)頁的刷盤進(jìn)度超過了日志頁的刷盤進(jìn)度，此時(shí)會(huì)出現(xiàn)數(shù)據(jù)頁中記錄的LSN大于日志中的LSN，這時(shí)超出日志進(jìn)度的部分將不會(huì)重做，因?yàn)檫@本身就表示已經(jīng)做過的事情，無需再重做。

4.redo log與binlog區(qū)別

由binlog和redo log的區(qū)別可知：binlog日志只用于歸檔，只依靠binlog是沒有crash-safe能力的。
但只有redo log也不行，因?yàn)閞edo log是InnoDB特有的，且日志上的記錄落盤后會(huì)被覆蓋掉。因此需要binlog和redo log二者同時(shí)記錄，才能保證當(dāng)數(shù)據(jù)庫發(fā)生宕機(jī)重啟時(shí)，數(shù)據(jù)不會(huì)丟失。

三、undo log

數(shù)據(jù)庫事務(wù)四大特性中有一個(gè)是原子性，具體來說就是原子性是指對(duì)數(shù)據(jù)庫的一系列操作，要么全部成功，要么全部失敗，不可能出現(xiàn)部分成功的情況。

實(shí)際上，原子性底層就是通過undo log實(shí)現(xiàn)的。

undo log主要記錄了數(shù)據(jù)的邏輯變化，比如一條INSERT語句，對(duì)應(yīng)一條DELETE的undo log，對(duì)于每個(gè)UPDATE語句，對(duì)應(yīng)一條相反的UPDATE的undo log，這樣在發(fā)生錯(cuò)誤時(shí)，就能回滾到事務(wù)之前的數(shù)據(jù)狀態(tài)。

同時(shí)，undo log也是MVCC(多版本并發(fā)控制)實(shí)現(xiàn)的關(guān)鍵

四、主從復(fù)制的原理

1.什么是主從復(fù)制?

主從復(fù)制，是用來建立一個(gè)和主數(shù)據(jù)庫完全一樣的數(shù)據(jù)庫環(huán)境，稱為從數(shù)據(jù)庫；主數(shù)據(jù)庫一般是準(zhǔn)實(shí)時(shí)的業(yè)務(wù)數(shù)據(jù)庫。

2.主從復(fù)制的作用

1、做數(shù)據(jù)的熱備，作為后備數(shù)據(jù)庫，主數(shù)據(jù)庫服務(wù)器故障后，可切換到從數(shù)據(jù)庫繼續(xù)工作，避免數(shù)據(jù)丟失。
2、架構(gòu)的擴(kuò)展。業(yè)務(wù)量越來越大，I/O訪問頻率過高，單機(jī)無法滿足，此時(shí)做多庫的存儲(chǔ)，降低磁盤I/O訪問的頻率，提高單個(gè)機(jī)器的I/O性能。
3、讀寫分離，使數(shù)據(jù)庫能支撐更大的并發(fā)。在報(bào)表中尤其重要。由于部分報(bào)表sql語句非常的慢，導(dǎo)致鎖表，影響前臺(tái)服務(wù)。如果前臺(tái)使用master，報(bào)表使用slave，那么報(bào)表sql將不會(huì)造成前臺(tái)鎖，保證了前臺(tái)速度。

3.主從復(fù)制的原理

數(shù)據(jù)庫有個(gè)bin-log二進(jìn)制文件，記錄了所有sql語句。
我們的目標(biāo)就是把主數(shù)據(jù)庫的bin-log文件的sql語句復(fù)制過來。
讓其在從數(shù)據(jù)的relay-log重做日志文件中再執(zhí)行一次這些sql語句即可。
下面的主從配置就是圍繞這個(gè)原理配置
具體需要三個(gè)線程來操作：
binlog輸出線程:每當(dāng)有從庫連接到主庫的時(shí)候，主庫都會(huì)創(chuàng)建一個(gè)線程然后發(fā)送binlog內(nèi)容到從庫。

在從庫里，當(dāng)復(fù)制開始的時(shí)候，從庫就會(huì)創(chuàng)建兩個(gè)線程進(jìn)行處理：

從庫I/O線程:當(dāng)START SLAVE語句在從庫開始執(zhí)行之后，從庫創(chuàng)建一個(gè)I/O線程，該線程連接到主庫并請(qǐng)求主庫發(fā)送binlog里面的更新記錄到從庫上。從庫I/O線程讀取主庫的binlog輸出線程發(fā)送的更新并拷貝這些更新到本地文件，其中包括relay log文件。
從庫的SQL線程:從庫創(chuàng)建一個(gè)SQL線程，這個(gè)線程讀取從庫I/O線程寫到relay log的更新事件并執(zhí)行。

可以知道，對(duì)于每一個(gè)主從復(fù)制的連接，都有三個(gè)線程。擁有多個(gè)從庫的主庫為每一個(gè)連接到主庫的從庫創(chuàng)建一個(gè)binlog輸出線程，每一個(gè)從庫都有它自己的I/O線程和SQL線程。

4.總結(jié)

步驟一：主庫db的更新事件(update、insert、delete)被寫到binlog
步驟二：從庫發(fā)起連接，連接到主庫
步驟三：此時(shí)主庫創(chuàng)建一個(gè)binlog dump thread線程，把binlog的內(nèi)容發(fā)送到從庫
步驟四：從庫啟動(dòng)之后，創(chuàng)建一個(gè)I/O線程，讀取主庫傳過來的binlog內(nèi)容并寫入到relay log.
步驟五：還會(huì)創(chuàng)建一個(gè)SQL線程，從relay log里面讀取內(nèi)容，從Exec_Master_Log_Pos位置開始執(zhí)行讀取到的更新事件，將更新內(nèi)容寫入到slave的db.

總結(jié)

以上是生活随笔為你收集整理的MySQL三大日志及主从复制的原理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。