偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

MySQL事務(wù)已提交,數(shù)據(jù)卻丟了,趕緊檢查下這個配置!?。?/h1>

數(shù)據(jù)庫 MySQL
既然redo log能保證事務(wù)的ACID特性,那為什么還會出現(xiàn),水友提問中出現(xiàn)的“數(shù)據(jù)庫崩潰,丟數(shù)據(jù)”的問題呢?一起看下redo log的實現(xiàn)細節(jié)。

有個水友提問:

沈老師,我們有一次MySQL崩潰,重啟后發(fā)現(xiàn)有些已經(jīng)提交的事務(wù)對數(shù)據(jù)的修改丟失了,不是說事務(wù)能保證ACID特性么,想問下什么情況下可能導(dǎo)致“事務(wù)已經(jīng)提交,數(shù)據(jù)卻丟失”呢?

這個問題有點復(fù)雜,得先從redo log說起。

為什么要有redo log?

事務(wù)提交后,必須將事務(wù)對數(shù)據(jù)頁的修改刷(fsync)到磁盤上,才能保證事務(wù)的ACID特性。

這個刷盤,是一個隨機寫,隨機寫性能較低,如果每次事務(wù)提交都刷盤,會極大影響數(shù)據(jù)庫的性能。

隨機寫性能差,有什么優(yōu)化方法呢?

架構(gòu)設(shè)計中有兩個常見的優(yōu)化方法:

  • 先寫日志(write log first),將隨機寫優(yōu)化為順序?qū)懀?/li>
  • 將每次寫優(yōu)化為批量寫;

這兩個優(yōu)化,數(shù)據(jù)庫都用上了。

先說第一個優(yōu)化,將對數(shù)據(jù)的修改先順序?qū)懙饺罩纠?,這個日志就是redo log。

假如某一時刻,數(shù)據(jù)庫崩潰,還沒來得及將數(shù)據(jù)頁刷盤,數(shù)據(jù)庫重啟時,會重做redo log里的內(nèi)容,以保證已提交事務(wù)對數(shù)據(jù)的影響被刷到磁盤上。

一句話,redo log是為了保證已提交事務(wù)的ACID特性,同時能夠提高數(shù)據(jù)庫性能的技術(shù)。

既然redo log能保證事務(wù)的ACID特性,那為什么還會出現(xiàn),水友提問中出現(xiàn)的“數(shù)據(jù)庫崩潰,丟數(shù)據(jù)”的問題呢?一起看下redo log的實現(xiàn)細節(jié)。

redo log的三層架構(gòu)?

畫了一個丑圖,簡單說明下redo log的三層架構(gòu):

  • 粉色,是InnoDB的一項很重要的內(nèi)存結(jié)構(gòu)(In-Memory Structure),日志緩沖區(qū)(Log Buffer),這一層,是MySQL應(yīng)用程序用戶態(tài);
  • 屎黃色,是操作系統(tǒng)的緩沖區(qū)(OS cache),這一層,是OS內(nèi)核態(tài);
  • 藍色,是落盤的日志文件。

redo log最終落盤的步驟如何?

首先,事務(wù)提交的時候,會寫入Log Buffer,這里調(diào)用的是MySQL自己的函數(shù)WriteRedoLog;

接著,只有當(dāng)MySQL發(fā)起系統(tǒng)調(diào)用寫文件write時,Log Buffer里的數(shù)據(jù),才會寫到OS cache。注意,MySQL系統(tǒng)調(diào)用完write之后,就認為文件已經(jīng)寫完,如果不flush,什么時候落盤,是操作系統(tǒng)決定的;

畫外音:有時候打日志,明明printf了,tail -f卻看不到,就是這個原因,操作系統(tǒng)還沒有刷盤。

最后,由操作系統(tǒng)(當(dāng)然,MySQL也可以主動flush)將OS cache里的數(shù)據(jù),最終fsync到磁盤上。

操作系統(tǒng)為什么要緩沖數(shù)據(jù)到OS cache里,而不直接刷盤呢?

這里就是將“每次寫”優(yōu)化為“批量寫”,以提高操作系統(tǒng)性能。

數(shù)據(jù)庫為什么要緩沖數(shù)據(jù)到Log Buffer里,而不是直接write呢?

這也是“每次寫”優(yōu)化為“批量寫”思路的體現(xiàn),以提高數(shù)據(jù)庫性能。

畫外音:這個優(yōu)化思路,非常常見,高并發(fā)的MQ落盤,高并發(fā)的業(yè)務(wù)數(shù)據(jù)落盤,都可以使用。 redo log的三層架構(gòu),MySQL做了一次批量寫優(yōu)化,OS做了一次批量寫優(yōu)化,確實能極大提升性能,但有什么副作用嗎?

畫外音:有優(yōu)點,必有缺點。

這個副作用,就是可能丟失數(shù)據(jù):

  • 事務(wù)提交時,將redo log寫入Log Buffer,就會認為事務(wù)提交成功;
  • 如果寫入Log Buffer的數(shù)據(jù),write入OS cache之前,數(shù)據(jù)庫崩潰,就會出現(xiàn)數(shù)據(jù)丟失;
  • 如果寫入OS cache的數(shù)據(jù),fsync入磁盤之前,操作系統(tǒng)崩潰,也可能出現(xiàn)數(shù)據(jù)丟失;

畫外音:如上文所說,應(yīng)用程序系統(tǒng)調(diào)用完write之后(不可能每次write后都立刻flush,這樣寫日志很蠢),就認為寫成功了,操作系統(tǒng)何時fsync,應(yīng)用程序并不知道,如果操作系統(tǒng)崩潰,數(shù)據(jù)可能丟失。

任何脫離業(yè)務(wù)的技術(shù)方案都是耍流氓:

  • 有些業(yè)務(wù)允許低效,但不允許一丁點數(shù)據(jù)丟失;
  • 有些業(yè)務(wù)必須高性能高吞吐,能夠容忍少量數(shù)據(jù)丟失。

MySQL是如何折衷的呢?

MySQL有一個參數(shù):

innodb_flush_log_at_trx_commit

能夠控制事務(wù)提交時,刷redo log的策略。

目前有三種策略:

策略一:最佳性能(innodb_flush_log_at_trx_commit=0)

  • 每隔一秒,才將Log Buffer中的數(shù)據(jù)批量write入OS cache,同時MySQL主動fsync。
  • 這種策略,如果數(shù)據(jù)庫崩潰,有一秒的數(shù)據(jù)丟失。

策略二:強一致(innodb_flush_log_at_trx_commit=1)

  • 每次事務(wù)提交,都將Log Buffer中的數(shù)據(jù)write入OS cache,同時MySQL主動fsync。
  • 這種策略,是InnoDB的默認配置,為的是保證事務(wù)ACID特性。

策略三:折衷(innodb_flush_log_at_trx_commit=2)

  • 每次事務(wù)提交,都將Log Buffer中的數(shù)據(jù)write入OS cache;
  • 每隔一秒,MySQL主動將OS cache中的數(shù)據(jù)批量fsync。

畫外音:磁盤IO次數(shù)不確定,因為操作系統(tǒng)的fsync頻率并不是MySQL能控制的。

  • 這種策略,如果操作系統(tǒng)崩潰,最多有一秒的數(shù)據(jù)丟失。

畫外音:因為OS也會fsync,MySQL主動fsync的周期是一秒,所以最多丟一秒數(shù)據(jù)。

講了這么多,回到水友的提問上來,數(shù)據(jù)庫崩潰,重啟后丟失了數(shù)據(jù),有很大的可能,是將innodb_flush_log_at_trx_commit參數(shù)設(shè)置為0了,這位水友最好和DBA一起檢查一下InnoDB的配置。

可能有水友要問,高并發(fā)的業(yè)務(wù),InnoDB運用哪種刷盤策略最合適?

高并發(fā)業(yè)務(wù),行業(yè)最佳實踐,是使用第三種折衷配置(=2),這是因為:

  • 配置為2和配置為0,性能差異并不大,因為將數(shù)據(jù)從Log Buffer拷貝到OS cache,雖然跨越用戶態(tài)與內(nèi)核態(tài),但畢竟只是內(nèi)存的數(shù)據(jù)拷貝,速度很快;
  • 配置為2和配置為0,安全性差異巨大,操作系統(tǒng)崩潰的概率相比MySQL應(yīng)用程序崩潰的概率,小很多,設(shè)置為2,只要操作系統(tǒng)不崩潰,也絕對不會丟數(shù)據(jù)。

總結(jié)

(1) 為了保證事務(wù)的ACID特性,理論上每次事務(wù)提交都應(yīng)該刷盤,但此時效率很低,有兩種優(yōu)化方向:

  • 隨機寫優(yōu)化為順序?qū)?/li>
  • 每次寫優(yōu)化為批量寫

(2) redo log是一種順序?qū)?,它有三層架?gòu):

  • MySQL應(yīng)用層:Log Buffer
  • OS內(nèi)核層:OS cache
  • OS文件:log file

(3) 為了滿足不同業(yè)務(wù)對于吞吐量與一致性的需求,MySQL事務(wù)提交時刷redo log有三種策略:

  • 0:每秒write一次OS cache,同時fsync刷磁盤,性能好;
  • 1:每次都write入OS cache,同時fsync刷磁盤,一致性好;
  • 2:每次都write入OS cache,每秒fsync刷磁盤,折衷;

(4) 高并發(fā)業(yè)務(wù),行業(yè)內(nèi)的最佳實踐,是:

innodb_flush_log_at_trx_commit=2

知其然,知其所以然,希望大家有收獲。

責(zé)任編輯:趙寧寧 來源: 架構(gòu)師之路
相關(guān)推薦

2025-06-30 08:43:50

網(wǎng)關(guān)代碼

2013-03-22 09:04:11

施密特Google Now蘋果

2022-04-28 09:02:55

Gitcommitlint配置

2010-03-24 09:09:00

Opera MiniIphone

2022-11-16 17:10:25

MySQL數(shù)據(jù)事務(wù)

2023-02-27 14:42:46

MySQLSQL

2022-07-27 08:52:10

MySQL二階段提交

2023-02-02 07:06:10

2024-05-21 14:12:07

2022-01-03 07:18:05

臟讀幻讀 MySQL

2022-06-29 11:01:05

MySQL事務(wù)隔離級別

2024-07-03 10:26:17

2024-01-02 07:55:26

MySQLRedolog緩存

2025-02-26 08:26:38

2021-03-17 00:05:50

分布式事務(wù)提交

2009-02-11 13:08:29

事務(wù)提交事務(wù)管理Spring

2020-06-17 16:56:36

數(shù)據(jù)庫MySQL跨行事務(wù)

2017-08-22 17:10:45

數(shù)據(jù)庫MySQL事務(wù)模型

2021-01-05 10:48:38

RedisAOF日志RDB快照
點贊
收藏

51CTO技術(shù)棧公眾號