If I want to talk to you about the locking mechanism in InnoDB, it will inevitably involve the MySQL log system, binlog, redo log, undo log, etc. I saw these three logs summarized by some friends. Not bad, hurry up and share it with your friends.
The log is an important part of the mysql database, recording various status information during the operation of the database. mysql Logs mainly include error logs, query logs, slow query logs, transaction logs, and binary logs.
As a developer, what we need to focus on is the binary log (binlog) and transaction log (including redo log and undo log). This article will introduce these three types of logs in detail next.
binlog is used to record write operations (excluding queries) information performed by the database and is saved on the disk in binary form. binlog is the logical log of mysql and is recorded by the Server layer. The mysql database using any storage engine will record binlogLog.
Logical log: It can be understood that what is recorded is the sql statement.
Physical log: mysqlThe data is ultimately saved In the data page, the physical log records the data page changes.
binlog is written by appending. Each binlog file can be set through the max_binlog_size parameter. When the file size reaches the given value, a new file will be generated to save the log.
In actual applications, binlog has two main usage scenarios, namely master-slave replication and data recovery.
Master-slave replication: Open binlog on the Master side, and then send binlog to each Slave side, Slave side replays binlog to achieve master-slave data consistency.
Data recovery: Recover data by using the mysqlbinlog tool.
For the InnoDB storage engine, it will only be recorded when the transaction is committedbiglog , the record is still in the memory at this time, so when was biglog flushed to the disk?
mysqlControl the flushing timing of biglog through the sync_binlog parameter, the value range is 0-N:
0: No mandatory requirement, the system will decide when to write to the disk;
1: Every time commit##binlog must be written to the disk when #;
binlog will be written to the disk for every N transactions.
sync_binlog is 1, which is also MySQL 5.7.7Default value for subsequent versions. However, setting a larger value can improve database performance. Therefore, in actual situations, you can also increase the value appropriately and sacrifice a certain degree of consistency to obtain better performance.
binlogThe log has three formats, namely STATMENT, ROW and MIXED.
MySQL 5.7.7, the default format is STATEMENT, after MySQL 5.7.7, the default value is ROW . The log format is specified by binlog-format.
STATMENT: Replication based on SQL statements (statement-based replication, SBR), each statement will be modified The SQL statements of the data will be recorded in binlog.
ROW: Row-based replication (row-based replication, RBR), does not record the context information of each SQL statement, only It is necessary to record which data has been modified.
MIXED: Mixed-based replication based on STATMENT and ROW , MBR), general copying uses STATEMENT mode to save binlog, for operations that cannot be copied in STATEMENT mode, use ROW mode Save binlog
So how does
mysqlensure consistency?
The simple way is to flush all data pages involved in modifications to disk every time a transaction is committed. However, doing so will cause serious performance problems, mainly reflected in two aspects:
Because Innodb performs disk interaction in units of pages, and a transaction is likely to only modify a few data pages. Bytes, it would be 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. The performance of using random IO writing is too poor!
So
mysqldesignedredo log. Specifically, it only records what modifications the transaction has made to the data page, so It can perfectly solve the performance problem (relatively speaking, the file is smaller and it is sequential IO).
redo log includes two parts: one is the log buffer in memory (redo log buffer), The other is the log file on disk (redo logfile).
mysqlEach time a DML statement is executed, the record is first written to redo log buffer, and then at a later point in time, multiple records are written at once. Operation records are written to redo log file. This technology of writing logs first and then writing to disk is the WAL (Write-Ahead Logging) technology often mentioned in
MySQL.
In computer operating systems, buffer data in user space (user space) generally cannot be written directly to the disk, and must pass through the operating system kernel space (kernel space) buffer (OS Buffer).
Therefore, redo log bufferwriting redo logfile actually writes OS Buffer first, and then calls through the system fsync()Flash it to redo log file
, the process is as follows:
mysqlSupport Three timings for writing redo log buffer to redo log file can be configured through the innodb_flush_log_at_trx_commit parameter. The meaning of each parameter value is as follows:
As mentioned earlier, redo logactually records changes to the data page, and this It is not necessary to save all the change records, so redo log is implemented using a fixed size and cyclic writing method. When writing to the end, it will return to the beginning to write the log in a loop. As shown below:
At the same time, we can easily know that in innodb, there are redo log that need to be flushed, and also There are data pages that also need to be flushed. The main significance of redo log is to reduce the requirement for data pages to be flushed**.
In the above figure, write pos represents the LSN (logical sequence number) position of the redo log current record, check point indicates the LSN (logical sequence number) position corresponding to redo log after the data page change record is flushed.
write posThe part between check point is the empty part of redo log, used to record new records;## Between #check point and write pos is the redo log change record of the data page to be written to the disk. When write pos catches up with check point, it will first push check point forward, vacate the position, and then record a new log.
innodb, no matter whether it was shut down normally or abnormally last time, the recovery operation will always be performed. Because redo log records the physical changes of the data page, the recovery speed is much faster than the logical log (such as binlog).
innodb, it will first check the LSN of the data page in the disk. If the LSN of the data page is less than the in the log LSN, the recovery will start from checkpoint.
checkpoint is in progress before the downtime, and the disk brushing progress of the data page exceeds the disk brushing progress of the log page. At this time, data will appear. The LSN recorded in the page is greater than the LSN in the log. At this time, the part that exceeds the progress of the log will not be redone, because this itself means that what has been done does not need to be redone. Do.
binlog and redo log: The binlog log is only used for archiving, and relying solely on binlog does not have the crash-safe capability.
But only redo log will not work, because redo log is unique to InnoDB, and the records in the log will be overwritten after being written to disk. Therefore, both binlog and redo log need to be recorded at the same time to ensure that when the database is down and restarted, the data will not be lost.
One of the four major characteristics of database transactions is atomicity. Specifically, atomicity refers to a series of operations on the database, either all succeed or all fail. There may be partial success.
In fact, the bottom layer of atomicity is achieved through undo log. undo log mainly records the logical changes of data. For example, an INSERT statement corresponds to a undo log of DELETE, for each # The ##UPDATE statement corresponds to an opposite UPDATE's undo log, so that when an error occurs, you can roll back to the data state before the transaction.
undo log is also the key to MVCC (multi-version concurrency control) implementation.
The above is the detailed content of What is the difference between binlog/redolog/undolog in MySQL?. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
