MySQL in the redo log files
There are three MySQL log files, redo log, bin log, undo log. Engine redo log storage layer (InnoDB) generated log, in order to ensure the reliability of the main data; bin log is generated on a MySQL database level logs, mainly used for point in time and recover from the master copy. Rollback undo log is mainly used for the transaction (undo log record of each modification operation inverse operation) and consistency of non-locking --- MVCC read multi-version concurrency control (undo log roll back rows to a specific version ).
redo log and undo log is generated on the storage engine level log and record all the data modifications: just redo log record is modified on the page "physical level" operations, such as page number xxx, yyy write offset into the 'zzz' transactions; undo log record is the logical operation log, such as a row of the INSERT statement data operation, then an undo log is recorded contrary DELETE operations.
redo log effect
MySQL as a storage system, in order to ensure reliability of data, place orders finally obtained. However, the speed and to write data, the memory needs to be introduced based on the "pool." In fact, more than MySQL, this buffer is introduced to solve the speed problem thinking everywhere. Now that the data is cached in the buffer pool first, and then in some way flushed to disk, then there is data in the buffer pool due to downtime caused by loss of data in order to solve the problem in this case is lost, the introduction of the redo log . In other storage systems, such as Elasticsearch, but also has a similar mechanism, called translog.
However, when data is written to a general discussion, in MySQL, commonly called the transactional operations, according to the ACID properties of a transaction, how to ensure the guarantee after a transaction is committed Durability of? And that is the role of the redo log. When writing user data to MySQL, the first to write redo log, then redo log according to "somehow" persisted to disk, into a redo log file, user data is in the "buffer" in (such as data pages, index pages). If downtime occurs, redo log file on the disk is read to recover the data. From this perspective, a persistent MySQL transactions is achieved by redo log.
redo log is written to disk
During the operation of the transaction, we will continue to produce redo log, the redo log will first set in the redo log buffer, and then in a redo log buffer data in some manner are sequentially written to disk (redo log each operation aggregated to redo log buffer, and then unified by the redo log buffer to write the disk, you can do the order written). These methods are:
MySQL master thread periodic task once per second, the redo log buffer is flushed to disk (even if the transaction has not yet submitted)
MySQL master thread periodic task every 10 seconds, the redo log buffer is flushed to disk
When the redo log buffer size is less than 1/2 of the free space (the innodb_log_buffer_size parameter), the redo log buffer is flushed to disk
When the redo log file size has reached a certain threshold about to "unavailable" (log file group take turns writing files), trigger async / sync flush checkpoint, in a timely manner some of the dirty pages are flushed to disk, while the redo log buffer to refresh disk, and then update the log sequence number value of the redo log file.
redo log buffer is flushed to disk innodb_flush_log_at_trx_commit timing parameters are controlled by parameters Possible values are: 0,1,2:
- 0 refresh thread periodically by the master task
- 1 when a transaction commit redo log buffer synchronous writes disk, accompanied by calls fsync
- 2 is written to disk redo log log data asynchronously, that is only written to the file system cache, after the transaction is successful submission does not guarantee redo log data must be stored on the disk
When redo log is written to disk, 512B sector size is written to ensure that each write can write successfully, do not need a double write mechanism.
