What are the differences between redo log and binlog in mysql

I want to talk to you about two small knowledge points in mysql: redo log and binlog.

redo log: InnoDB storage engine layer log, so if the storage engine you use is not InnoDB, then there is no redo log at all.

binlog: The log recorded by the MySQL Server layer, so no matter what storage engine is used, as long as it is MySQL, there will be a binlog. When doing MySQL master-slave replication, What is used is binlog.

Next, let’s take a closer look at what they do?

redo log

Why do we need this redo 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 a query operation. You must first find this data. , and then perform the update operation, right?

If the amount of data is relatively small, it’s fine, and it can be found and updated quickly. But what if the amount of data is relatively large, with 100 million pieces of data in it? Moreover, the update operation must be written to the disk, so what is the IO cost in the middle?

What if I have dozens of update statements updated one after another? If you think about it this way, you can imagine that the cost of these operations is very high. So can these costs be reduced?

At this time, redo log comes into play. 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 data is updated successfully.

But at this time, it has not been updated to the disk, right? Don't worry, InnoDB will update this record to disk at the appropriate time.

This kind of thinking or technology has a proper name: WAL technology, which is WriteAheadLogging. The core is to write the log first and then write to the disk.

redo log Can’t keep writing?

The size of the redo log is fixed, and the previous content will be overwritten. Once it is full, the synchronization of the redo log to the disk will be triggered to make room for recording subsequent modifications.

If the database is down or restarted, the data will not be lost.

Because of the redo log, the previously submitted records are still there. You only need to restore them accordingly based on the records in the redo log.

binlog

Binlog is the recording log of the MySQL Server layer.

The difference between redo log and binlog:

• redo log is unique to the InnoDB engine; binlog is implemented by the Server layer of MySQL and is available for all engines.

• redo log is a physical log, which records “XXX modifications were made 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 performed to write to the disk before it can continue; the binlog can be appended Writing, that is, 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, it is a logical log) and can be used as the main From replication and data recovery.

When the binlog function is turned on, we can export the binlog into SQL statements and replay all operations to achieve data recovery.

After having these two logs, let’s take a look at how an update statement is executed (redo cannot be written at once):

For example, a statement: update user set name='Xiao Ma' where id=1;

• Query this data first, if there is Cache, cache will also be used.

• Change the name to 小马, then call the engine’s API interface, 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 completed and can be submitted at any time.

• After receiving the notification, the executor records the binlog, then calls the storage engine interface and sets 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-stage commit". Why is it this way?

Both redo log and binlog can be used to represent the commit status of a transaction, and Two-phase commit is to keep the two states logically consistent.

You can assume that if you don’t use this method, but write redo log first and then binlog, what will happen? If an exception occurs when writing binlog and the update operation has been carried out in the redo log, but the binlog is not updated at this time, is there data inconsistency?

The same goes for writing binlog first and then redo log. Therefore, when writing, first put the redo log in the prepare state, and after the binlog is finished writing, put the redo log in the commit state, thus maintaining logical consistency.

The above is the detailed content of What are the differences between redo log and binlog in mysql. For more information, please follow other related articles on the PHP Chinese website!