mysql關於redo事務日誌ib_logfile的理解

總結

1、redo事務日誌就是ib_logfile,兩個ib_logfile開頭的檔案，它們就是log group中的redo log file，而且它們的大小完全一致且等於變數innodb_log_file_size定義的值

2、redo事務日誌的作用就是用於crash recovery，crash recovery是資料庫重啟時自動的行為，無需為DBA執行任何額外工作

3、MySQL以迴圈方式寫入重做日誌檔案，如果最後1個 ib_logfile 被寫滿，而第一個ib_logfile中所有記錄的事務對資料的變更已經被持久化到磁碟中，將清空並重用之。

4、redo事務日誌的概念類似oracle的online redo log，裡面包含commit和uncommit的資料

5、寫redo事務日誌有幾種方式，每隔1秒或每次事務提交，所以裡面可以包含沒有提交uncommit的資料

6、show engine innodb status可以看到redo log的資訊

     Log sequence number：表明當前redo log的最新LSN。

     Log flushed up to：表明當前已經重新整理到磁碟上redo log的LSN。

     Last checkpoint at ：redo log記錄的更新已經重新整理到磁碟上的檢查點LSN，該LSN之前的redo log上記錄的更新已全部重新整理到磁碟上，可以被覆蓋重複使用。

7、檢視ib_logfile裡的內容的方法

[root@mydb ~]# strings /var/lib/mysql/ib_logfile0

相關引數

innodb_log_file_size ：每個redo log檔案大小

innodb_log_files_in_group ：redo log日誌組成員個數

innodb_log_group_home_dir ：redo log存放目錄

innodb_page_size ：InnoDB表空間的頁面大小，預設16K

innodb_flush_log_at_timeout ：日誌重新整理頻率，單位秒

Write and flush the logs every N seconds. innodb_flush_log_at_timeout allows the timeout period between flushes to be increased in order to reduce flushing and avoid impacting performance of binary log group commit. The default setting for innodb_flush_log_at_timeout is once per second.

每N秒寫入並重新整理日誌。 innodb_flush_log_at_timeout允許增加重新整理之間的超時時間，以減少重新整理並避免影響二進位制日誌組提交的效能。 innodb_flush_log_at_timeout的預設設定是每秒一次。

innodb_flush_log_at_trx_commit ：控制commit動作是否重新整理log buffer到磁碟

Controls the balance between strict ACID compliance for commit operations and higher performance that is possible when commit-related I/O operations are rearranged and done in batches. 

The default setting of 1 is required for full ACID compliance. Logs are written and flushed to disk at each transaction commit

With a setting of 0, logs are written and flushed to disk once per second

With a setting of 2, logs are written after each transaction commit and flushed to disk once per second

控制提交操作的嚴格ACID合規性與重新安排和批次完成與 提交 相關的I / O操作時可能實現的更高效能之間的平衡。

預設設定為1。在每次事務提交時，日誌都會寫入並重新整理到磁碟。這種方式即使系統崩潰也不會丟失任何資料，但是因為每次提交都寫入磁碟，IO的效能較差。

設定為0時，每秒寫入日誌並將其重新整理到磁碟一次。也就是說設定為0時是(大約)每秒重新整理寫入到磁碟中的，當系統崩潰，會丟失1秒鐘的資料。

設定為2時，在每次事務提交後寫入日誌，然後每秒再重新整理一次磁碟。每次提交都僅寫入到os buffer，然後是每秒呼叫fsync()將os buffer中的日誌寫入到log file on disk。

日誌重新整理頻率由innodb_flush_log_at_timeout控制，允許您將日誌重新整理頻率設定為N秒（其中N為1 ... 2700，預設值為1）。但是，任何mysqld程式崩潰都可以消除最多N秒的事務。

innodb_flush_log_at_timeout很多人誤以為是控制innodb_flush_log_at_trx_commit值為0和2時的1秒頻率，實際上並非如此。

以下四種方式將innodb日誌緩衝區的日誌重新整理到磁碟

1、每秒一次執行重新整理Innodb_log_buffer到重做日誌檔案。即使某個事務還沒有提交，Innodb儲存引擎仍然每秒會將重做日誌快取重新整理到重做日誌檔案。

2、每個事務提交時會將重做日誌重新整理到重做日誌檔案。

3、當重做日誌快取可用空間少於一半時，重做日誌快取被重新整理到重做日誌檔案

4、當有checkpoint時，checkpoint在一定程度上代表了刷到磁碟時日誌所處的LSN位置

https://dev.mysql.com/doc/refman/5.7/en/innodb-redo-log.html

The redo log is a disk-based data structure used during crash recovery to correct data written by incomplete transactions.

重做日誌是在崩潰恢復期間用於糾正由未完成事務寫入的資料的基於磁碟的資料結構。

By default, the redo log is physically represented on disk as a set of files, named ib_logfile0 and ib_logfile1. MySQL writes to the redo log files in a circular fashion. 

預設情況下，重做日誌在磁碟上物理表示為一組檔案，名為ib_logfile0和ib_logfile1。 MySQL以迴圈方式寫入重做日誌檔案。

備註：innodb_log_files_in_group 確定ib_logfile檔案個數，命名從 ib_logfile0 開始。如果最後1個 ib_logfile 被寫滿，而第一個ib_logfile中所有記錄的事務對資料的變更已經被持久化到磁碟中，將清空並重用之。

https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_redo_log

redo

The data, in units of records, recorded in the redo log when DML statements make changes to InnoDB tables. It is used during crash recovery to correct data written by incomplete transactions. The ever-increasing LSN value represents the cumulative amount of redo data that has passed through the redo log.

當DML語句對InnoDB表進行更改時，以記錄為單位的資料記錄在重做日誌中。 它在崩潰恢復期間用於更正由未完成的事務寫入的資料。 不斷增加的LSN值表示透過重做日誌的重做資料的累積量。

redo log

A disk-based data structure used during crash recovery, to correct data written by incomplete transactions. During normal operation, it encodes requests to change InnoDB table data, which result from SQL statements or low-level API calls through NoSQL interfaces. Modifications that did not finish updating the data files before an unexpected shutdown are replayed automatically.

The redo log is physically represented as a set of files, typically named ib_logfile0 and ib_logfile1. The data in the redo log is encoded in terms of records affected; this data is collectively referred to as redo. The passage of data through the redo logs is represented by the ever-increasing LSN value. The original 4GB limit on maximum size for the redo log is raised to 512GB in MySQL 5.6.3.

在崩潰恢復期間使用的基於磁碟的資料結構，用於糾正由未完成的事務寫入的資料。 在正常操作期間，它編碼更改InnoDB表資料的請求，這些資料來自SQL語句或透過NoSQL介面的低階API呼叫。 在意外關閉之前未完成更新資料檔案的修改會自動重播。

重做日誌在物理上表示為一組檔案，通常名為ib_logfile0和ib_logfile1。 重做日誌中的資料根據受影響的記錄進行編碼; 這些資料統稱為重做。 資料透過重做日誌的傳遞由不斷增加的LSN值表示。 在MySQL 5.6.3中，重做日誌的最大大小的原始4GB限制被提升到512GB。

crash

MySQL uses the term “crash” to refer generally to any unexpected shutdown operation where the server cannot do its normal cleanup. For example, a crash could happen due to a hardware fault on the database server machine or storage device; a power failure; a potential data mismatch that causes the MySQL server to halt; a fast shutdown initiated by the DBA; or many other reasons. The robust, automatic crash recovery for InnoDB tables ensures that data is made consistent when the server is restarted, without any extra work for the DBA.

MySQL使用術語“崩潰”來指代伺服器無法正常清理的任何意外關閉操作。 例如，由於資料庫伺服器計算機或儲存裝置上的硬體故障，可能會發生崩潰; 停電; 潛在的資料不匹配導致MySQL伺服器停止; 由DBA發起的快速關閉; 或許多其他原因。 InnoDB表的強大自動崩潰恢復功能可確保在重新啟動伺服器時使資料保持一致，而無需為DBA執行任何額外工作。

crash recovery

The cleanup activities that occur when MySQL is started again after a crash. For InnoDB tables, changes from incomplete transactions are replayed using data from the redo log. Changes that were committed before the crash, but not yet written into the data files, are reconstructed from the doublewrite buffer. When the database is shut down normally, this type of activity is performed during shutdown by the purge operation.

During normal operation, committed data can be stored in the change buffer for a period of time before being written to the data files. There is always a tradeoff between keeping the data files up-to-date, which introduces performance overhead during normal operation, and buffering the data, which can make shutdown and crash recovery take longer.

崩潰後再次啟動MySQL時發生的清理活動。 對於InnoDB表，使用重做日誌中的資料重放未完成事務的更改。 在崩潰之前提交但尚未寫入資料檔案的更改將從doublewrite緩衝區重建。 當資料庫正常關閉時，在清除操作期間執行此類活動。

在正常操作期間，提交的資料可以在寫入資料檔案之前儲存在更改緩衝區中一段時間。 在保持資料檔案最新之間總是需要權衡，這會在正常操作期間引入效能開銷，並緩衝資料，這會使關閉和崩潰恢復花費更長時間。

備註：CrashSafe指MySQL伺服器當機重啟後能夠保證：所有已經提交的事務的資料仍然存在；所有沒有提交的事務的資料自動回滾。Innodb透過Redo Log和Undo Log可以保證這兩點。

log buffer

The memory area that holds data to be written to the log files that make up the redo log. It is controlled by the innodb_log_buffer_size configuration option.

儲存要寫入構成重做日誌的日誌檔案的資料的記憶體區域。 它由innodb_log_buffer_size配置選項控制。

log file

One of the ib_logfileN files that make up the redo log. Data is written to these files from the log buffer memory area.

構成重做日誌的ib_logfileN檔案之一。 資料從日誌緩衝區儲存區寫入這些檔案。

log group

The set of files that make up the redo log, typically named ib_logfile0 and ib_logfile1. (For that reason, sometimes referred to collectively as ib_logfile.)

組成重做日誌的檔案集，通常名為ib_logfile0和ib_logfile1。（因此，有時統稱為ib_logfile。）

LSN

Acronym for “log sequence number”. This arbitrary, ever-increasing value represents a point in time corresponding to operations recorded in the redo log. (This point in time is regardless of transaction boundaries; it can fall in the middle of one or more transactions.) It is used internally by InnoDB during crash recovery and for managing the buffer pool.

Prior to MySQL 5.6.3, the LSN was a 4-byte unsigned integer. The LSN became an 8-byte unsigned integer in MySQL 5.6.3 when the redo log file size limit increased from 4GB to 512GB, as additional bytes were required to store extra size information. Applications built on MySQL 5.6.3 or later that use LSN values should use 64-bit rather than 32-bit variables to store and compare LSN values.

In the MySQL Enterprise Backup product, you can specify an LSN to represent the point in time from which to take an incremental backup. The relevant LSN is displayed by the output of the mysqlbackup command. Once you have the LSN corresponding to the time of a full backup, you can specify that value to take a subsequent incremental backup, whose output contains another LSN for the next incremental backup.

“日誌序列號”的縮寫。這個任意的，不斷增加的值表示與重做日誌中記錄的操作相對應的時間點。 （此時間點與事務邊界無關;它可以落在一個或多個事務的中間。）它在崩潰恢復期間由InnoDB內部使用，用於管理緩衝池。

在MySQL 5.6.3之前，LSN是一個4位元組的無符號整數。當重做日誌檔案大小限制從4GB增加到512GB時，LSN成為MySQL 5.6.3中的8位元組無符號整數，因為需要額外的位元組來儲存額外的大小資訊。在MySQL 5.6.3或更高版本上構建的使用LSN值的應用程式應使用64位而不是32位變數來儲存和比較LSN值。

在MySQL Enterprise Backup產品中，您可以指定LSN來表示進行增量備份的時間點。相關的LSN由mysqlbackup命令的輸出顯示。一旦您擁有與完全備份時間相對應的LSN，您就可以指定該值以進行後續增量備份，其輸出包含用於下一次增量備份的另一個LSN。