在InnoDB中，bufferpool里面的dirtypage一方面可以加快數(shù)據(jù)處理速度，同時也會造成數(shù)據(jù)的不一致(RAMvsDISK)。本文介紹了dirtypage是如何產(chǎn)生，以及InnoDB如何利用redolog如何消除dirtypage產(chǎn)生的數(shù)據(jù)不一致。

當(dāng)事務(wù)(Transaction)需要修改某條記錄（row）時，InnoDB需要將該數(shù)據(jù)所在的page從disk讀到bufferpool中，事務(wù)提交后，InnoDB修改page中的記錄(row)。這時bufferpool中的page就已經(jīng)和disk中的不一樣了，我們稱bufferpool中的page為dirtypage。Dirtypage等待flush到disk上。

dirtypage既然是在Bufferpool中，那么如果系統(tǒng)突然斷電Dirtypage中的數(shù)據(jù)修改是否會丟失？這個擔(dān)心是很有必要的，例如如果一個用戶完成一個操作（數(shù)據(jù)庫完成了一個事務(wù)，page已經(jīng)在bufferpool中修改，但dirtypage尚未flush），這時系統(tǒng)斷電，bufferpool數(shù)據(jù)全部消失。那么，這個用戶完成的操作（導(dǎo)致的數(shù)據(jù)庫修改）是否會丟失呢？答案是不會(innodb_flush_log_at_trx_commit=1)。這就是redolog要做的事情，在disk上記錄更新。

redolog在每次事務(wù)commit的時候，就立刻將事務(wù)更改操作記錄到redolog。所以即使bufferpool中的dirtypage在斷電時丟失，InnoDB在啟動時，仍然會根據(jù)redolog中的記錄完成數(shù)據(jù)恢復(fù)。

redolog的另一個作用是，通過延遲dirtypage的flush最小化磁盤的randomwrites。（redolog會合并一段時間內(nèi)TRX對某個page的修改）

正常情況下，dirtypage什么時候flush到disk上？
1).redolog是一個環(huán)(ring)結(jié)構(gòu)，當(dāng)redo空間占滿時，將會將部分dirtypageflush到disk上，然后釋放部分redolog。這種情況可以通過Innodb_log_wait(SHOWGLOBALSTATUS)觀察，情況發(fā)生該計(jì)數(shù)器會自增一次。
2).當(dāng)需要在Bufferpool分配一個page，但是已經(jīng)滿了，并且所有的page都是dirty的（否則可以釋放不dirty的page），通常是不會發(fā)生的。這時候必須flushdirtypagestodisk。這種情況將會記錄到Innodb_buffer_pool_wait_free中。一般地，可以可以通過啟動參數(shù)innodb_max_dirty_pages_pct控制這種情況，當(dāng)bufferpool中的dirtypage到達(dá)這個比例的時候，將會強(qiáng)制設(shè)定一個checkpoint，并把dirtypageflush到disk中。
3).檢測到系統(tǒng)空閑的時候，會flush，每次64pages。

涉及的InnoDB配置參數(shù)：innodb_flush_log_at_trx_commit、innodb_max_dirty_pages_pct；狀態(tài)參數(shù)：Innodb_log_wait、Innodb_buffer_pool_wait_free。

我的my.cnf文件是這樣的

innodb_data_home_dir = /usr/local/mysql/var
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /usr/local/mysql/var
innodb_buffer_pool_size = 16M
innodb_additional_mem_pool_size = 2M
innodb_log_file_size = 5M

innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

結(jié)果啟動的時候報(bào)錯如下：

130904 16:26:00 [ERROR] /usr/local/mysql/libexec/mysqld: unknown variable 'innod
b_data_file_path=ibdata1:10M:autoextend'
130904 16:26:00 [ERROR] Aborting

130904 16:26:00 [Note] /usr/local/mysql/libexec/mysqld: Shutdown complete

130904 16:26:00 mysqld_safe mysqld from pid file /usr/local/mysql/var/test4.wolf
.org.pid ended

我查看得知

>show variables like 'have%';

如果 have_innodb = NO 的話，那確實(shí)是編譯的時候innodb沒有加載進(jìn)去。

那么需要重新編譯的時候 ./configure ... --with-plugins=innobase?

唉唉唉唉，只有重新編譯了

[root@test4 mysql-5.1.70]# ./configure --prefix=/usr/local/mysql --enable-assembler --datadir=/mysql/data --with-client-ldflags=-all-static--with-unix-socket-path=/tmp --with-charset=utf8 --enable-thread-safe-client --with-pthread --without-debug --with-big-tables --enable-community-features --enable-profiling --enable-local-infile --with-fast-mutexes --with-plugins=partition,federated,ndbcluster,innobase,csv,blackhole,myisam,innodb_plugin

[root@test4 mysql-5.1.70]# make && strip sql/mysqld && make install

如果你編譯安裝 的時候編譯了innnodb但是還是出現(xiàn)這位洋的問題，那么就這么解決

解決如下：?
/var/lib/mysql目錄下，刪除ibdata1、ib_logfile1、 ib_logfile0，然后重啟MySql讓其重建以上文件:?
mysqladmin -uroot -p shutdown?
sudo mysqld_safe &?
搞定!

本文出自 “好好活著” 博客，請務(wù)必保留此出處http://wolfword.blog.51cto.com/4892126/1288657

from:?http://wolfword.blog.51cto.com/4892126/1288383

總結(jié)

以上是生活随笔為你收集整理的mysql dba系统学习（10）innodb引擎的redo log日志的原理 mysql dba系统学习（11）管理innodb引擎的redo log日志的一个问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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