Implementation of database transactions (I) fault recovery (undo log) _ MySQL

Implementation of database transactions (I) fault recovery (undo log) bitsCN.com preface

Transactions are an important part of the database. For the introduction of transactions, you can write other articles on google. The purpose of this article is not to introduce what transactions are, but to describe how transactions are implemented. Therefore, this article and the following articles describe the implementation of transactions in the database system. I hope to summarize my knowledge through these articles, it is the best to bring benefits to your friends. If there is something wrong with the article, you are welcome to correct it.

Introduction

Ensuring data consistency is one of the most basic functions of the database. how can we ensure database data consistency when the database goes down or encounters other accidents? This article focuses on this topic to introduce the undo log and redo log mechanisms to maintain data consistency. Undolog and redolog are two types of log files in the database. The database uses these two types of log files to achieve data consistency.

Database Architecture Overview

To introduce the implementation mechanism of database consistency, we need to introduce the overall architecture of the database. here we will draw a brief diagram to introduce the database architecture.

We simplify the database, mainly including the following:

• The query processor is mainly responsible for SQL parsing and execution plan selection.
• Transaction Manager, which is the smallest unit of database operations. Transaction Manager is mainly used to manage the allocation of transaction IDs and so on.
• Log Manager
• Recovery Manager
• Buffer Manager. you know that all write operations in the database are completed in the buffer and then flushed to the hard disk.
• Hard disk data, logs, both database data and log files, are ultimately written to the hard disk for persistent storage.

The following describes how the database performs disaster recovery based on the components mentioned above. This article focuses on undolog, and the next article focuses on redolog.

Undo log introduction

The undo log, as its name implies, is the undo log, that is, the log records the related undo operations. Based on the database architecture diagram, we can also see that data writing and other processing are mainly performed in the memory, data loss may occur due to machine downtime. How does the database ensure data consistency through the undo log?

To describe this problem, we need to define several operations first. Suppose we want to do this now, we need to read a piece of data X from the database, then change its value to Y, and then write it back. Well, for such an operation, the database may need to follow these steps. First, it will check whether there is any in the buffer zone. if there is one, it will directly return the data. We call this process Read (X ), if there is no buffer, read the buffer from the hard disk first and then return it to the user. then we define the process of reading the buffer from the hard disk as Input (X), that is, if there is no buffer, the database must first pass through a Read (X), then an Input (X), and then Read (X ). The same is true for the modification. if the database wants to modify the buffer content, this operation will become Write (Y ). it also goes through the process of flushing from memory to disk, which is output (Y ). Well, with these definitions, we will analyze these processes one by one. if the database goes down in the middle, how can we ensure data consistency.

Before introduction, briefly describe the format of undolog. the format of undolog is as follows: T represents the transaction ID, A represents A column in A row, and X represents the original value. That is to say, this log represents the transaction T, when A's original value is X, right, undolog only records the original value, he does not care about how much you change it, he cares about the original amount, because in the future, he will only do the withdrawal work. In addition to this, undolog also records start, which means to start a transaction, commit, and commit a transaction. In general, we can first abstract them into these.

For example, if we want to solve the problem above, that is, to read a value and modify it (assuming it is not in the buffer), we need to take the following steps:

See the table below:

No.	Operation	Undolog
1	-	Start
2	Read (X)	-
3	Input (X)	-
4	Read (X)	-
5	Write (Y)	-
6	-
7	Flush undolog
8	Output (Y)	-
9	...	...
10	Commit	-
11	-	End
10	Flush undolog

Let's look at the table above. I will explain it below. First, we need to make it clear that, whether operating data in the database or logs, they are first operating in the memory and then flushed to the hard disk. There is no doubt about this.

The first four steps should be easy to understand. at first, a start flag must be recorded in undolog, and then steps 2, 3, and 4 read the database content, in step 2, write data to the memory, change the value of X to Y, and then in step 3 undolog, record that the original value of A in transaction T is X. What about step 2? Should undolog be flush first or output before flush?

Let's Make a hypothesis, assuming that the log is flushed after the output, and if the database is down after the output, the result is obvious, undolog is not recorded in the log file (because it is not flushed to the hard disk) and cannot be redone. Therefore, data inconsistency may occur. Therefore, undolog flush cannot be performed after output.

Let's take a look at the meaning of the above sequence. assume that the machine goes down between step 6 and step 7, that is, the machine is down before the undolog is flushed. this will not affect data consistency, because the data is not written to the hard disk. If the database data is not written to the hard disk, but the log is flushed, it will be redone through the flush log, because the system does not know whether the log has been done or not, even redo does not affect the final data consistency. it only re-writes the original data, it is written from X to X, which does not affect database consistency. undolog is idempotent, that is, the result of several times is the same. Therefore, the above order is reasonable.

Restore data through undolog

Now that undolog is available, let's take a look at how the database recovers data through undolog. At this time, the recovery manager in the architecture diagram above plays a role. The Recovery Manager will scan undolog to find the start with no end, as we can see from the above sequence, the "end" record flush to log is flush only after the transaction is committed. Therefore, as long as the end record exists, it indicates that the transaction has ended, data consistency can be ensured. Therefore, the recovery manager scans the start with no end coordinate, and then rewrites it from start to undolog based on the previous values recorded in the undolog. However, according to the model we just found that when the recovery manager retries, there cannot be other writes, that is, the current writes should be stuck. There is another problem. The recovery manager needs to scan undolog from the beginning. In fact, this is not necessary. it can have a checkpoint (meaning that the data before this can ensure data consistency) the recovery manager only needs to find the last checkpoint, and then proceed from the checkpoint.

For the above two problems, we will discuss the implementation of database transactions in the next article-fault recovery (II) (undo log checkpoint). This article will first come here. You have to do something else.

I hope this article will help you.

This article from http://www.log4myself.info/archives/287

BitsCN.com