Article directory
Series Article Directory
1. MySQL innodb engine architecture analysis-Buffer Pool
2. MySQL innodb engine architecture analysis-Redo log
3. MySQL innodb engine architecture analysis-Double Write Buffer
4.MySQL innodb engine architecture analysis-Change Buffer
foreword
In the transaction processing process of MySQL, the database must guarantee the characteristics of the transaction (about the characteristics of the database transaction, you can refer to my blog post database transaction management and the three-level blocking protocol ), among which the characteristics of transaction persistence must be realized. When , it is easiest to change the data on the disk in real time, but there are several problems in this implementation:
- Because Innodb interacts with the disk in units of pages, and a transaction may only modify a few bytes in a data page, it is a waste of resources to flush the complete data page to the disk at this time.
- A transaction may involve modifying multiple data pages, and these data pages are not physically continuous, and the write performance using random IO is too poor.
- A transaction is not 100% committed, and it may be rolled back. If the transaction is not committed but rolled back after performing random IO, the disk IO is wasted. Each random IO may include disk surface seeking, path seeking, and query. In the process of sectors, if a disk space is opened up so that the physical addresses are continuous, each record is recorded in this area, so that each time the disk only appends the previous data, which reduces the disk seek , The number of seeks, only write data in one continuous sector. Disk IO is a very precious resource and cannot be wasted easily.
Therefore, MySQL designed the Redo log. Specifically, it only records the changes made to the data page by the transaction, so that the performance problem can be perfectly solved. Relatively speaking, the area where the Redo log exists is a continuous disk physical space. is a sequential IO.
1. What is Redo log?
Redo log is unique to InnoDB engine. Records the modification of data in the transaction. In mysql, if the data is modified, before the transaction is committed, it will first be recorded as a redo log and written to the disk, and when the transaction is committed, the new data will be written to the disk.
2. How does Redo log work?
Composition of Redo log
Redo log consists of two parts: one is the log buffer (Redo log buffer) in memory, and the other is the log file (Redo log file) on disk. Every time MySQL executes a statement, it first writes the records to the Redo log buffer, and then writes multiple operation records to the Redo log file at a certain point in time.
Redo log records the physical log, which records "what modification was made on a certain data page", such as the following statement:
update table set a = 1 where id = 1;
then the translation into a physical log is similar to this:
put the 10th The value at offset 1024 of page 90 of the table space is updated to 1. The
following is the general structure of most types of redo logs:
- type: the type of redo log, currently there are many types of redo log
MLOG_1BYTE: the decimal value corresponding to the type field is 1, which means that a byte is written at a certain offset of the page
MLOG_2BYTES: the decimal value corresponding to the type field is 2, which means that in Write two bytes MLOG_4BYTES at a certain offset of the page
: the decimal corresponding to the type field is 4, which means writing four bytes MLOG_8BYTES at a certain offset of the page
: the decimal corresponding to the type field is 8, Indicates that eight bytes are written at a certain offset of the page
MLOG_WRITE_STRING:: The decimal value corresponding to the type field is 30, indicating that a string of data is written at a certain offset of the page - Space ID: table space ID
- page number: page number
- data: the content of a redo log
Redo log configuration
By default, the Redo log is represented on disk by two physical files named ib_logfile0 and ib_logfile1. The parameters related to Redo log are briefly introduced as follows:
- innodb_log_files_in_group: The number of redo log files, named as: ib_logfile0, iblogfile1... iblogfilen. The default is 2, and the maximum is 100.
- innodb_log_file_size: The size of a single redo log file, the default value is 48M, and the maximum value is 512G. Note that the maximum value refers to the sum of the entire redo log series files, that is, (innodb_log_files_in_group * innodb_log_file_size) cannot be greater than the maximum value of 512G.
- innodb_log_group_home_dir: Specifies the path where the redo log file group is located. The default is ./, which means it is in the data directory of the database.
- innodb_log_buffer_size: redo log buffer size, default 16M. Delay the writing of the transaction log to disk, put the redo log into the buffer, and then flush the log from the buffer to the disk according to the setting of the innodb_flush_log_at_trx_commit parameter.
- innodb_flush_log_at_trx_commit: The policy that controls redo log flushing to disk, the default is 1.
When it is set to 0, it means that the disk operation will not be performed each time the transaction is submitted. If the database hangs up, the record from the time of the hangup to the last disk flushing will be lost.
When it is set to 1, it means that the disk operation will be performed every time the transaction is submitted (default value)
. It's just that the data can be hung up, the operating system is normal, and the submitted things will not be lost.
When to refresh the Redo log
Depending on the parameters set by innodb_flush_log_at_trx_commit, the database will flush the Redo log at the following times:
- Background thread brushing.
- There are too many dirty pages, and the InnoDB storage engine forces Checkpoint. Make some redo files can be rewritten. When the buffer pool is not enough, the least recently used page will be overflowed according to the LRU algorithm. If the page is a dirty page, then checkpiont needs to be enforced to flush the dirty page, that is, the new version of the page, back to disk.
- when the transaction is committed. Dirty pages can not be written, but the redo log must be written before submission!
- Shut down the server gracefully.
Summarize
Changing the redo log and its buffer size requires restarting the database instance. It is recommended to make an evaluation during initialization. You can appropriately increase the number and size of redo log groups, especially if your database instance is updated frequently. But it is not recommended to set too large redo log.