mysql5.6 redo log with brush dirty

1.redo Log

In order to ensure data security and improve system performance when the server crashes, the InnoDB storage engine first logs the contents of the submissions to the redo log, while the actual data file changes are placed in the future, batch mode brush disk. Redo logs are like logical storage sites, and it loops through multiple files. (Ib_logfile0, Ib_logfile1, Ib_logfile2)

Innodb_log_file_size #各日志文件大小

Innodb_log_files_in_group #日志文件的个数, InnoDB the final usable log size is innodb_log_file_size *innodb_log_files_in_group

Innodb_log_group_home_dir #日志目录

The larger the redo log space, the more "dirty pages" can be stuck in the InnoDB buffer pool. This way, the dirty pages of the InnoDB buffer pool can be refreshed to disk in much larger quantities. Because the Mysql5.5redo log has a maximum free space of 4GB, productivity is not high in innodb with large caches. mysql5.6 start to allow users to set more than 4GB redo log, innodb_log_file_size *innodb_log_files_in_ The group combination can be up to 512GB. This allows dirty pages to play a more efficient role in write buffering when there is a lot of cache space.

2. Brush Dirty

After a user query is processed in InnoDB, its result is changed in the buffer pool in memory space, but it has not yet been logged to disk. This page is called dirty pages, and the process of logging dirty pages to disk is called brushing dirty. Brush dirty divided into two algorithms: Flush-list (the list of changed pages in the time management buffer pool) lru-list (for managing the list of very-used pages in the buffer pool)

(1) Flush-list depending on how the Rdbmsredo log works (write Ahead log), in redo logs and dirty pages, the redo log is always first completely brushed to disk before the redo log slots associated with that dirty page can be reused again. In order to quickly find dirty pages in the buffer pool, a linked list is maintained according to the modified chronological order of the dirty pages, which is called flush-list.

(2) If the InnoDB buffer pool is full of data pages and indexes, the INNODB buffer pool has no free space. In this case, a new query arrives, in order to execute the query, the INNODB storage engine must remove several loaded pages from the buffer pool, InnoDB is not arbitrarily deleted, InnoDB manages the lru-list linked list, which is selected from the list when it needs to be deleted. Lru-list maintains a list of recently infrequently used pages. The lru-list is divided into two regions, MRU and LRU. The MRU is located before 5/8 of Lru-list and the remainder is LRU. That is, the usual pages are stored before 5/8, and the remaining 3/8 are infrequently used pages (you can modify the innodb_old_blocks_pct system variable value to control the split point between the MRU and the LRU, with a default value of 5/8). Deleting content deletes several pages at the end of the least-used list. The brush is dirty before it is deleted.

mysql5.6 redo log with brush dirty