Logging system: How is an SQL update statement executed?
Unlike the query process, the update process also involves two important log modules: redo log (redo log) and binlog (archive log).
Important log module: redo log
MySQL's WAL technology
The full name of WAL is Write-Ahead Logging. Its key point is to write the log first, and then write to the disk.
When a record needs to be updated, the InnoDB engine will first write the record to the redo log and update the memory. At this time, the update is complete.
The InnoDB engine will update this operation record to the disk at an appropriate time, and this update is often done when the system is relatively idle.
InnoDB's redo log is a fixed-size circular linked list.
For example, it can be configured as a group of 4 files, and the size of each file is 1GB, so a total of 4GB operations can be recorded.
Start writing from the beginning, and then return to the beginning and write in a loop at the end.
write pos is the position of the current record, it moves backward while writing, and returns to the beginning of file 0 after writing to the end of file No. 3.
checkpoint is the current position to be erased, and it is also moved backwards and cyclically. Before erasing the record, the record must be updated to the data file.
The blank part between write pos and checkpoint can be used to record new operations.
If the write pos catches up with the checkpoint, no new updates can be performed at this time, and it is necessary to stop and erase some records first, and advance the checkpoint.
With the redo log, InnoDB can ensure that even if the database restarts abnormally, the previously submitted records will not be lost. This capability is called crash-safe.
Redo log is used to ensure crash-safe capability
When the parameter innodb_flush_log_at_trx_commit is set to 1, it means that the redo log of each transaction is directly persisted to disk.
It is recommended that you set this parameter to 1, so as to ensure that the data will not be lost after an abnormal restart of MySQL.
Important log module: binlog
The redo log is a log specific to the InnoDB engine, and the server layer also has its own log, called binlog (archived log).
The redo log is unique to the InnoDB engine; the binlog is implemented by the server layer of MySQL and can be used by all engines.
Redo log is a physical log, which records "what modification was made on a certain data page"; binlog is a logical log, which records the original logic of this statement, such as "Add 1 to the c field of the row ID=2" .
The redo log is written in a loop, and the space will always be used up; the binlog can be appended. "Append write" means that after the binlog file is written to a certain size, it will switch to the next one, and will not overwrite the previous log.
The Redo log does not record the "status after update" of the data page, but records "what changes have been made" on this page. Binlog has two modes, the statement format is to record the sql statement, and the row format will record the content of the row, two records, both before and after the update.
When the sync_binlog parameter is set to 1, it means that the binlog of each transaction is persisted to disk.
It is also recommended that you set this parameter to 1, so as to ensure that the binlog will not be lost after MySQL restarts abnormally.
two-phase commit
Why must there be a "two-phase commit"? This is to make the logic consistent between the two logs.
If you do not use "two-phase commit", then the state of the database may be inconsistent with the state of the library recovered from its log.
When you need to expand capacity, that is, when you need to build more backup databases to increase the readability of the system, the common practice is to use full backup and apply binlog to achieve this. This "inconsistency" will lead to your There is an inconsistency between the master and slave databases online.
Both redo log and binlog can be used to represent the commit status of a transaction, and the two-phase commit is to keep these two states logically consistent.
