redo log
The redo log is called a redo log. It is used to solve the problem of data loss caused by the server being down before the database transaction is submitted to the disk.
As the storage engine of MySQL, InnoDB stores data in disks. If you have to operate disk IO every time you read and write data, the efficiency will be very low. For this reason, InnoDB provides a cache (Buffer Pool). The Buffer Pool contains some data pages on the disk. Mapping, as a buffer for accessing the database: when reading data from the database, it will first be read from the Buffer Pool. If there is not one in the Buffer Pool, it will be read from the disk and put into the Buffer Pool; when writing data to the database , will be written to the Buffer Pool first, and the modified data in the Buffer Pool will be refreshed to the disk regularly (dirty brushing)
The use of Buffer Pool greatly improves the efficiency of reading and writing data, but it also brings new problems: if MySQL goes down and the modified data in the Buffer Pool has not been flushed to the disk, it will cause data loss and transaction failure. Durability is not guaranteed.
Therefore, redo log was introduced to solve this problem: when the data is modified, in addition to modifying the data in the Buffer Pool, the operation will also be recorded in the redo log; when the transaction is committed, the fsync interface will be called to flush the redo log. If MySQL goes down, you can read the data in the redo log and restore the database when it restarts. The redo log uses WAL (Write-ahead logging, write-ahead log). All modifications are first written to the log and then updated to the Buffer Pool, ensuring that the data will not be lost due to MySQL downtime, thereby meeting the durability requirements.
Since the redo log also needs to write the log to the disk when the transaction is committed, why is it faster than directly writing the modified data in the Buffer Pool to the disk (that is, brushing it dirty)? There are mainly two reasons:
(1) Cleaning is random IO, because the data location modified each time is random, but writing redo log is an append operation and belongs to sequential IO.
(2) The unit of dirtying is data page (Page). The default page size of MySQL is 16KB. A small modification on a Page requires the entire page to be written; while the redo log only contains the part that really needs to be written, which is invalid. IO is greatly reduced.
undo log
The two main functions of undo log are to implement MVCC and transaction rollback
When a record is deleted, a corresponding insert record will be recorded in the undo log, and vice versa. When a record is updated, a corresponding update record will be recorded. If the update is the primary key, it will be deleted first and then inserted. Record of the reverse logical operation of two events.
When things are rolled back, the corresponding content will be read in reverse for rollback. The original value of the modified data can also be read according to the undo log.
Meow Interview Assistant: A one-stop solution to interview questions. You can search the WeChat applet [Meow Interview Assistant] or follow [Meow Interview Assistant] -> Interview Assistant to answer questions for free. If you have any good interview knowledge or skills, I look forward to sharing them with you!