foreword
Today I want to talk to you about two small knowledge points in mysql: redo log 和 binlog.
redo log: The log of the InnoDB storage engine layer, so if the storage engine you use is not InnoDB, then there is no redo log at all.
binlog: The log recorded at the MySQL Server layer, so no matter what storage engine is used, as long as MySQL is used, there will be binlog. When doing MySQL master-slave replication, binlog is used.
Next, let's take a closer look at what they do respectively.
redo log
Why is there this redo log log file?
Here, we can give an example. Now we want to modify the data in the database. Now an update statement comes. Generally, the update operation is accompanied by the query operation. We must first find this data and then perform the update operation, right?
If the amount of data is relatively small, it’s okay, it can be found and updated quickly, but if the amount of data is relatively large, with 100 million pieces of data in it, what should I do? And the update operation must be written to the disk, so what about the IO cost in the middle?
What if I have dozens of update statements updated successively? If you think about it this way, you can think that the cost of these operations is too high, so can you reduce these costs?
At this time, redo log plays a role.
When a record is updated, the InnoDB engine will first write the record to the redo log and update the memory at the same time, so that the update of this data is successful.
But at this point, it's not updated to disk, right? Don't worry, InnoDB will update this record to disk at the right time.
This kind of thinking or technology has a proper term: WAL technology, that is, WriteAheadLogging, the core is to write the log first, and then write to the disk.
Can't redo log be written all the time?
The size of the redo log is fixed, and the previous content will be overwritten. Once it is full, it will trigger the synchronization of the redo log to disk to make room for subsequent modifications.
Even if the database goes down or restarts, the data will not be lost.
Because of the redo log, the records submitted before are still there, and you only need to restore them according to the records in the redo log.
binlog
binlog is the logging of the MySQL Server layer.
The difference between redo log and binlog:
-
The redo log is specific to the InnoDB engine; the binlog is implemented by the MySQL server layer, and all engines are available.
-
Redo log is a physical log, which records "XXX modification on XXX page"; binlog is a logical log, such as "add 1 to the c field of the row with id = 2".
-
The redo log has a fixed size, so its space will be used up. If it is used up, some operations must be written to the disk before continuing; the binlog can be appended, that is, the binlog has no concept of space. Just keep writing.
Binlog records all DDL and DML statements in the form of events (because it records operations rather than data values, which belong to logical logs), and can be used for master and data recovery .
When the binlog function is enabled, we can export the binlog into SQL statements and replay all operations to achieve data recovery.
With these two logs, let's take a look at how an update statement is executed (redo cannot be written once):
For example a statement:update user set name='小马' where id=1;
-
Query this data first, and if there is a cache, the cache will also be used.
-
Change the name to
小马, then call the API interface of the engine, write this line of data to the memory, and record the redo log at the same time. At this time, the redo log enters the prepare state, and then tells the executor that the execution is complete and can be submitted at any time. -
The executor records the binlog after receiving the notification, and then calls the storage engine interface to set the redo log to the commit state.
-
update completed.
You can find that the redo log is in the prepare state first, and after the binlog is written, it is in the commit state. This method is called "two-phase commit". Why is there such a way?
Both redo log and binlog can be used to represent the commit status of the transaction, but 两阶段提交to keep the two states logically consistent.
It can be assumed that if this method is not used, but the redo log is written first, and then the binlog is written, what will happen? If an exception occurs when writing the binlog, the update operation has already entered the redo log, but the binlog has not been updated at this time, is there data inconsistency?
It is the same reason to write binlog first and then redo log. Therefore, when writing, let the redo log be in the prepare state first, and then let the redo log be in the commit state after the binlog is written, so as to maintain logical consistency.
summary
The above is the relevant knowledge about redo log and binlog in mysql. I think it is helpful, remember to like it, and let's work together! talk less and do more~