14.4.13.1 Group Commit for Redo Log Flushing
The redo log is a disk-based data structure used during crash recovery to correct data written by incomplete transactions. During normal operations, the redo log encodes requests to change InnoDB table data that result from SQL statements or low-level API calls. Modifications that did not finish updating the data files before an unexpected shutdown are replayed automatically during initialization, and before the connections are accepted. For information about the role of the redo log in crash recovery, see Section 14.18.2, “InnoDB Recovery”.
重做日誌是基於磁盤的數據結構，用來在崩潰恢復期間糾正由未完成的事務寫入的數據，在正常操作期間，重做日誌對更改來自SQL語句或低級API調用的InnoDB表數據的請求進行編碼。。在初始化期間以及接受連接之前，會在意外關閉之前自動重播未完成更新數據文件的修改。有關重做日誌在崩潰恢復中的作用的信息，請看 Section 14.18.2, “InnoDB Recovery”.
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. 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 log is represented by an ever-increasing LSN value.
默認情況下，重做日誌在磁盤上物理地表示爲一組文件，名字爲ib_logfile0 和ib_logfile1，MySQL以循環方式寫入重做日誌文件，重做日誌中的數據按受影響的記錄進行編碼。這些數據統稱爲重做。數據通過重做日誌的過程由不斷增加的LSN值表示。
For related information, see:
- Section 14.6.1, “InnoDB Startup Configuration”
- Section 8.5.4, “Optimizing InnoDB Redo Logging”
- Section 14.7.2, “Changing the Number or Size of InnoDB Redo Log Files”
- InnoDB Crash Recovery
NEXT: 14.4.12 Temporary Tablespace https://blog.51cto.com/itzhoujun/2353748
PREV: 14.4.13.1 Group Commit for Redo Log Flushing https://blog.51cto.com/itzhoujun/2353750