默認(rèn)情況下會(huì)有兩個(gè)文件，名稱分別為ib_logfile0和ib_logfile1。MySQL官方手冊(cè)中將其稱為InnoDB存儲(chǔ)引擎的日志文件，不過更準(zhǔn)確的定義應(yīng)該是重做日志文件（redo log file）。為什么強(qiáng)調(diào)是重做日志文件呢？因?yàn)橹刈鋈罩疚募?duì)于InnoDB存儲(chǔ)引擎至關(guān)重要，它們記錄了對(duì)于InnoDB存儲(chǔ)引擎的事務(wù)日志。
重做日志文件的主要目的是，萬(wàn)一實(shí)例或者介質(zhì)失敗（media failure），重做日志文件就能派上用場(chǎng)。如數(shù)據(jù)庫(kù)由于所在主機(jī)掉電導(dǎo)致實(shí)例失敗，InnoDB存儲(chǔ)引擎會(huì)使用重做日志恢復(fù)到掉電前的時(shí)刻，以此來(lái)保證數(shù)據(jù)的完整性。
每個(gè)InnoDB存儲(chǔ)引擎至少有1個(gè)重做日志文件組（group），每個(gè)文件組下至少有2個(gè)重做日志文件，如默認(rèn)的ib_logfile0、ib_logfile1。為了得到更高的可靠性，你可以設(shè)置多個(gè)鏡像日志組（mirrored log groups），將不同的文件組放在不同的磁盤上。日志組中每個(gè)重做日志文件的大小一致，并以循環(huán)方式使用。InnoDB存儲(chǔ)引擎先寫重做日志文件1，當(dāng)達(dá)到文件的最后時(shí)，會(huì)切換至重做日志文件2，當(dāng)重做日志文件2也被寫滿時(shí)，會(huì)再切換到重做日志文件1中。圖3-2顯示了一個(gè)擁有3個(gè)重做日志文件的重做日志文件組。
 |
| 圖3-2 日志文件組 |
參數(shù)innodb_log_file_size、innodb_log_files_in_group、innodb_mirrored_log_groups、innodb_log_group_home_dir影響著重做日志文件的屬性。參數(shù)innodb_log_file_size指定了重做日志文件的大?。籭nnodb_log_files_in_group指定了日志文件組中重做日志文件的數(shù)量，默認(rèn)為2；innodb_mirrored_log_groups指定了日志鏡像文件組的數(shù)量，默認(rèn)為1，代表只有一個(gè)日志文件組，沒有鏡像；innodb_log_group_home_dir指定了日志文件組所在路徑，默認(rèn)在數(shù)據(jù)庫(kù)路徑下。以下顯示了一個(gè)關(guān)于重做日志組的配置：
- mysql> show variables like 'innodb%log%'\G;
- *************************** 1. row ***************************
- Variable_name: innodb_flush_log_at_trx_commit
- Value: 1
- *************************** 2. row ***************************
- Variable_name: innodb_locks_unsafe_for_binlog
- Value: OFF
- *************************** 3. row ***************************
- Variable_name: innodb_log_buffer_size
- Value: 8388608
- *************************** 4. row ***************************
- Variable_name: innodb_log_file_size
- Value: 5242880
- *************************** 5. row ***************************
- Variable_name: innodb_log_files_in_group
- Value: 2
- *************************** 6. row ***************************
- Variable_name: innodb_log_group_home_dir
- Value: ./
- *************************** 7. row ***************************
- Variable_name: innodb_mirrored_log_groups
- Value: 1
- 7 rows in set (0.00 sec)
重做日志文件的大小設(shè)置對(duì)于MySQL數(shù)據(jù)庫(kù)各方面還是有影響的。一方面不能設(shè)置得太大，如果設(shè)置得很大，在恢復(fù)時(shí)可能需要很長(zhǎng)的時(shí)間；另一方面又不能太小了，否則可能導(dǎo)致一個(gè)事務(wù)的日志需要多次切換重做日志文件。在錯(cuò)誤日志中可能會(huì)看到如下警告：
- 090924 11:39:44 InnoDB: ERROR: the age of the
last checkpoint is 9433712, - InnoDB: which exceeds the log group capacity 9433498.
- InnoDB: If you are using big BLOB or TEXT rows,
you must set the - InnoDB: combined size of log files at least 10
times bigger than the - InnoDB: largest such row.
- 090924 11:40:00 InnoDB: ERROR: the age of the
last checkpoint is 9433823, - InnoDB: which exceeds the log group capacity 9433498.
- InnoDB: If you are using big BLOB or TEXT rows,
you must set the - InnoDB: combined size of log files at least 10
times bigger than the - InnoDB: largest such row.
- 090924 11:40:16 InnoDB: ERROR: the age of the
last checkpoint is 9433645, - InnoDB: which exceeds the log group capacity 9433498.
- InnoDB: If you are using big BLOB or TEXT rows,
you must set the - InnoDB: combined size of log files at least 10
times bigger than the - InnoDB: largest such row.
重做日志文件（2）
上面錯(cuò)誤集中在InnoDB: ERROR: the age of the last checkpoint is 9433645,InnoDB: which exceeds the log group capacity 9433498。這是因?yàn)橹刈鋈罩居幸粋€(gè)capacity變量，該值代表了最后的檢查點(diǎn)不能超過這個(gè)閾值，如果超過則必須將緩沖池（innodb buffer pool）中刷新列表（flush list）中的部分臟數(shù)據(jù)頁(yè)寫回磁盤。
也許有人會(huì)問，既然同樣是記錄事務(wù)日志，那和我們之前的二進(jìn)制日志有什么區(qū)別？首先，二進(jìn)制日志會(huì)記錄所有與MySQL有關(guān)的日志記錄，包括InnoDB、MyISAM、Heap等其他存儲(chǔ)引擎的日志。而InnoDB存儲(chǔ)引擎的重做日志只記錄有關(guān)其本身的事務(wù)日志。其次，記錄的內(nèi)容不同，不管你將二進(jìn)制日志文件記錄的格式設(shè)為STATEMENT還是ROW，又或者是MIXED，其記錄的都是關(guān)于一個(gè)事務(wù)的具體操作內(nèi)容。而InnoDB存儲(chǔ)引擎的重做日志文件記錄的關(guān)于每個(gè)頁(yè)（Page）的更改的物理情況（如表3-2所示）。此外，寫入的時(shí)間也不同，二進(jìn)制日志文件是在事務(wù)提交前進(jìn)行記錄的，而在事務(wù)進(jìn)行的過程中，不斷有重做日志條目（redo entry）被寫入重做日志文件中。
表3-2 重做日志結(jié)構(gòu)
在第2章中已經(jīng)提到，對(duì)于寫入重做日志文件的操作不是直接寫，而是先寫入一個(gè)重做日志緩沖（redo log buffer）中，然后根據(jù)按照一定的條件寫入日志文件。圖3-3很好地表示了這個(gè)過程。
 |
| 圖3-3 重做日志寫入過程 |
上面提到了從日志緩沖寫入磁盤上的重做日志文件是按一定條件的，那這些條件有哪些呢？第2章分析了主線程（master thread），知道在主線程中每秒會(huì)將重做日志緩沖寫入磁盤的重做日志文件中，不論事務(wù)是否已經(jīng)提交。另一個(gè)觸發(fā)這個(gè)過程是由參數(shù)innodb_ flush_log_at_trx_commit控制，表示在提交（commit）操作時(shí)，處理重做日志的方式。
參數(shù)innodb_flush_log_at_trx_commit可設(shè)的值有0、1、2。0代表當(dāng)提交事務(wù)時(shí)，并不將事務(wù)的重做日志寫入磁盤上的日志文件，而是等待主線程每秒的刷新。而1和2不同的地方在于：1是在commit時(shí)將重做日志緩沖同步寫到磁盤；2是重做日志異步寫到磁盤，即不能完全保證commit時(shí)肯定會(huì)寫入重做日志文件，只是有這個(gè)動(dòng)作。
本章介紹了與MySQL數(shù)據(jù)庫(kù)相關(guān)的一些文件，并了解了文件可以分為MySQL數(shù)據(jù)庫(kù)文件以及和各存儲(chǔ)引擎有關(guān)的文件。與MySQL數(shù)據(jù)庫(kù)有關(guān)的文件中，錯(cuò)誤文件和二進(jìn)制日志文件非常重要。當(dāng)MySQL數(shù)據(jù)庫(kù)發(fā)生任何錯(cuò)誤時(shí)，DBA首先就應(yīng)該去查看錯(cuò)誤文件，從文件提示的內(nèi)容中找出問題的所在。當(dāng)然，錯(cuò)誤文件不僅記錄了錯(cuò)誤的內(nèi)容，也記錄了警告的信息，通過一些警告也有助于DBA對(duì)于數(shù)據(jù)庫(kù)和存儲(chǔ)引擎的優(yōu)化。
二進(jìn)制日志的作用非常關(guān)鍵，可以用來(lái)進(jìn)行point in time的恢復(fù)以及復(fù)制（replication）環(huán)境的搭建。因此，建議在任何時(shí)候時(shí)都啟用二進(jìn)制日志的記錄。從MySQL 5.1開始，二進(jìn)制日志支持STATEMENT、ROW、MIX三種格式，用來(lái)更好地同步數(shù)據(jù)庫(kù)。DBA應(yīng)該十分清楚三種不同格式之間的差異。
本章的最后介紹了和InnoDB存儲(chǔ)引擎相關(guān)的文件，包括表空間文件和重做日志文件。表空間文件是用來(lái)管理InnoDB存儲(chǔ)引擎的存儲(chǔ)，分為共享表空間和獨(dú)立表空間。重做日志非常重要，用來(lái)記錄InnoDB存儲(chǔ)引擎的事務(wù)日志，也因?yàn)橹刈鋈罩镜拇嬖冢攀沟肐nnoDB存儲(chǔ)引擎可以提供可靠的事務(wù)。
