Undo log and redo log must be clear this time

Business and ACID

When we study databases, we often see transactions and ACID That's what I'm saying .

What is business ？

In the database system , A transaction is ： A complete logical process composed of a series of database operations .

For example, bank transfer ：
1. Deduct the amount from the original account ;
2. Add amount to target account .

The sum of these two database operations , Constitute a complete logical process , It's not divisible . This process is called a transaction , have ACID characteristic .

What is that? ACID Well ？

On Wikipedia ACID Is defined as follows ：

ACID, Database management system （DBMS） In the process of writing or updating data , For the sake of security （transaction） Is correct and reliable , Four characteristics required ： Atomicity （atomicity, Or indivisibility ）、 Uniformity （consistency）、 Isolation, （isolation, Also called independence ）、 persistence （durability）.

• Atomicity （Atomic）： In the same business process , Transactions guarantee multiple modifications to data , Or at the same time , Or be revoked together . For example, transfer accounts. , Or transfer succeeded , Or transfer failed , There is no such thing as a half turn .
• Isolation, （Isolation）： In different business processes , Transactions ensure that their respective businesses are reading 、 The data written are independent of each other , It doesn't affect each other . Databases generally have four isolation levels ： Read uncommitted （Read Uncommitted）、 Read submitted （Read Committed）、 Repeatable （Repeatable Read）、 Serializable （Serializable）.
• persistence （Durability）： Transactions should ensure that all successfully committed data changes are correctly persisted , That is, it is saved to the disk , No loss of data .
• Uniformity （Consistency）： Ensure that the data in the system is correct , There is no contradiction between different data , The results are consistent .

In fact, atomicity 、 Isolation, 、 The ultimate goal of persistence is data consistency .

How to achieve atomicity and persistence

Atomicity ensures that multiple operations in a transaction either succeed , Or they all failed , There is no half the battle . Persistence ensures that once a transaction takes effect , The data will not be modified or lost for any reason .

So what if we can achieve atomicity and persistence ？

It's easy to think of , The database writes data to the disk ？

Yes , This is the right way , But the problem is “ Write to disk ” This operation is not atomic , A write operation can start writing 、 Write in 、 Write successfully , There are even write failures .

And a transaction often contains multiple operations , For example, we go online to order and buy things , These operations are generally involved ： Deduct money from our account 、 Increase the payment in the merchant's account 、 Reduce the inventory of goods, etc . These operations are in a transaction , That is to say, either all of them succeed , All or nothing .

Crash recovery

If we deduct... From our account 100 Yuan , This operation successfully wrote to the disk , And it is adding to the business 100 The system crashed when the money was （ Such bad luck ？）, Or there's a blackout （ Won't! ？）, Cause write failure （ It often happens ？）.

To avoid that , The database must find a way to know how the complete operation was before the system crashed , After the server is restored , The database should rewrite the part of data that has not been written to the disk in time , Add... To the merchant's account 100 Yuan , Finish the unfinished business .

So here comes the question , How does the database know all the information about previous transactions after system recovery ？

Better a good memory than a bad pen , Let's just write it down ？

Redo Log

This requires the database to record all transactions before writing to the disk , For example, modify the data 、 Which memory page and disk block does the data physically reside in 、 From what value to what value, etc , Write to disk first in the form of log .

Only when all log records are safely dropped , Then write at the end “Commit Record” after , It means that I have finished writing all the operation records .

At this time, the database will use the information in the log , Modify the real data , After the modification is completed , Add an entry in the log “End Record”, It means that I have completed all the steps in the log , The task of transaction persistence is finished .

This transaction implementation method is called “Commit Logging”.

This approach enables data persistence 、 The principle of atomicity is as follows ：

First , Once the log is successfully written Commit Record, That means that all the transaction related information has been written to the log , If the system crashes during data modification , After restart, just re operate according to the contents of the log , This ensures persistence .

secondly , If the system crashes before the log is written , After the system restarts , Once the database looks at the log, there is no Commit Record, This shows that the log is incomplete , Not finished yet , Then mark this part of the log as rollback status , The entire transaction is rolled back , This ensures atomicity .

In other words , I will first record what I want to change in my diary , I will write to the disk according to the logs , In case I faint while writing to the disk , When I wake up , Let me check the integrity of the log first .

If the log is complete , There are Commit Record, I will do it again according to the log , In the end, you can succeed . If the log is incomplete , There's no Commit Record, I'll roll back the entire transaction , Don't do anything? .

This log is called Redo Log, That is to say “ Redo log ”, A database that crashes halfway , Redo the transaction based on the log .

Undo Log

however Redo Log There is a problem , The efficiency is too slow .

Because the database makes all real changes to the data , Must occur after the transaction is committed , And write in the log Commit Record Not until later , Not finished Redo Log, The database does not dare to be written first .

Even before the transaction is committed, the disk I/O Have enough free time 、 Even if the amount of data modified by a transaction is very large , Take up a lot of memory buffer , Whatever the reason , It is never allowed to modify the data on the disk before the transaction is committed , In case the system crashes , Who is responsible for data travel ？

But when there is a large amount of data in a transaction , Wait for all changes to be written into Redo Log Then write to the disk uniformly , The performance is not very good , It's going to be slow , The boss will be unhappy .

Can we do this before the transaction is committed , Secretly write some data to the disk first （ Sneak away ）？

The answer is yes , This is it. STEAL Strategy , But the problem is , You secretly wrote the data , In case the transaction needs to be rolled back , Or the system crashes , The data written in advance becomes dirty data , We must find a way to restore it .

This needs to be introduced Undo Log（ Rollback log ）, Before stealthily writing data , You have to be in Undo Log What data is written in the record , What has been changed , At that time, the transaction is rolled back , Just follow Undo Log journal , One by one, they return to their original appearance , It's like you haven't changed .

Undo Log There's another function , This is to implement multiple line version control (MVCC), When a read row is locked by another transaction , It can come from Undo Log Get the previous data of the row record in , To provide the version information of this line , Let the user read .

summary

Undo Log（ Redo log ） and Redo Log（ Rollback log ） The difference between , Not that deep , We just have to take it literally .

Redo Log（ Redo log ） It is used to recover data after system crash , Let the database follow the log , Do the things you didn't do well again . With Redo Log, It can ensure that even if the database crashes and restarts , No records submitted before will be lost , This ability is called crash-safe.

Undo Log（ Rollback log ） For rollback . Start writing data before the transaction is committed , In case the transaction is not submitted at the end , To roll back , Or the system crashes , The data written in advance becomes dirty data , At this time, we have to use Undo Log To restore the .

This method of writing logs before writing to the disk is called ：Write-Ahead Logging（WAL）,WAL It makes the performance even higher , But it's also more complicated , Although it's complicated , But the effect is very good ,mysql、sqlite、postgresql、sql server Wait for the database to be realized WAL Mechanism? .