Implementation of database transactions-fault recovery (2) (undo log checkpoint) _ MySQL

Implementation of database transactions-fault recovery (2) (undo log checkpoint) bitsCN.com

In the previous article on implementation of database transactions (I) fault recovery (undo log), we introduced the application of undolog in data recovery. This article will continue to introduce undolog, however, we will introduce how to use undolog to recover data.

At the end of the previous chapter, we left a problem: in the model described in the previous chapter, the recovery manager must scan the entire undolog for log recovery through the entire article, this is obviously not necessary, because the system interruption must be affected in the last few transactions, and the previous transaction should have completed the commit or rollback, so there will be no abort, so how do we know which transactions are affected? if we know which transactions are affected, we don't need to scan the whole article, only a small part of the scan can be done. The following describes how the database knows which transactions are affected. for this purpose, the database introduces the checkpoint concept.

Checkpoint

Checkpoint, that is, the checkpoint. Writing a checkpoint in undolog indicates that the transactions before the checkpoint have completed the commit or rollback, that is, the transactions before the checkpoint do not have the data consistency problem. How to implement this checkpoint. In fact, the implementation mechanism is very simple, that is, periodic writing to undolog. Of course, this write is definitely not just written in. when writing in, you must check whether the previous transaction is complete.

This may cause a problem because the database is always running, that is, the transaction is continuously started, and n transactions may already be in the starting state. New transactions may start when writing the checkpoint in, if it is difficult to make the checkpoint wait until no new transaction is started and all the previous transactions have been committed, the basic checkpoint does not need to be written in. Therefore, in this case, the new transaction can only be stopped when the checkpoint is written in. wait until the started transaction is committed, and then the checkpoint write is completed. Then accept the new transaction. Similar to this: for example, if there are currently two T1 T2 transactions, write them in undolog:

Undolog
Start T1
Start T2

When the checkpoint cycle is reached, you have to wait until T1 and T2 are all submitted, and then write the checkpoint chkpoint. That is, if there is a T3 to be enabled, it cannot be enabled. The system is stuck. After writing, enable T3. the log record is as follows:

Undolog
Start T1
Start T2
End T1
End T2
Chkpoint
Start T3

At this time, if the system fails, the fault recovery manager will scan forward from the end of undolog. after scanning to the checkpoint, it will not scan forward, because the previous transactions have been committed, there is no data consistency problem. Therefore, you only need to redo it from the checkpoint.

This is certainly good, saving the trouble of undolog scanning from the beginning, but the disadvantage is also obvious, that is, in the process of writing the checkpoint, the system is in a hold state and all writes must be paused. Can there be a better way to write the checkpoint without the need to suspend the system? yes, of course, this is the non-static checkpoint to be discussed below.

Non-static checkpoint

Non-static checkpoints are relative to static checkpoints. as mentioned above, they are static checkpoints, because the system cannot write at the same time as the checkpoint is written. The introduction of non-static checkpoints is to solve this problem.

The non-static checkpoint policy records the active transactions while writing data to the chkpoint. For example, if T1 and T2 are both active in the current status, start checkpoint (T1, T2) will be written to the undolog, and the overall system will still write normally, that is to say, after this log is written, other transactions can still be started. After T1 and T2 are completed, the end checkpoint record is written. For example:

Undolog
Start T1
Start T2
Start checkpoint (T1, T2)
Start T3
End T1
End T2
End chkpoint
Start checkpoint (T3)
End T3
End chkpoint

The preceding log record indicates that after T1 and T2 start, the start checkpoint (T1, T2) checkpoint is written to the undolog, and the start of other transactions can still be accepted, at this time, the T3 transaction is enabled.

This mechanism can effectively avoid the disadvantages of stopping the service when the checkpoint is written. but now the problem arises, so writing The checkpoint is good, but how does the restoration manager perform data recovery through such undolog? Because, if the checkpoint is static, you do not have to look forward after finding the checkpoint, but now it is different, because after finding the end checkpoint, there may still be unfinished transactions, then how is data recovery restored?

In this case, after the database goes down, the recovery manager will still scan undolog from the end. if "end chkpoint" is encountered ", this does not mean that all the transactions before the checkpoint have been committed, but we can know that all the uncommitted transactions are after the previous start checkpoint, so we will continue to find the start checkpoint, after the start checkpoint is found, for example, start checkpoint (T1, T2). because the end chkpoint has been found previously, the T1 and T2 transactions can ensure data consistency, what needs to be redone is the non-T1 and T2 transactions between start checpoint (T1, T2) and end chkpoint, which need to be redone, so we need to redo them.

Another case is that the recovery manager first encounters the start checkpoint (T1, T2) log when scanning. in this case, we first know T1, t2 may be an unfinished transaction. in this case, you need to find the end statement for a transaction after start checkpoint. if so, it indicates that the transaction is completed. if not, it indicates that it is not completed, then we need to look back from check point, find the start of the transaction, and then redo it after start. Let's look at this situation in the previous example.

For example, after the database goes down, start scanning undolog and get the following snippet:

Undolog
Start T1
Start T2
Start checkpoint (T1, T2)
Start T3
End T1

At this time, the recovery manager obtains this segment and then scans it. before encountering the end chkpoint, it encounters start checkpoint (T1, T2). This shows that T1 and T2 may not complete the transaction, before that, we encountered the start of T3, no end T3, and no start of the T3 checkpoint. This shows that T3 must have not completed the transaction, so T3 must be redone. Previously, why does T1 and T2 fail to complete the transaction? Because start checkpoint (T1, T2) is encountered, and end chkpoint is not met, it does not mean that T1 and T2 must be incomplete, and one may have already been commit, because neither of them has a commit, the end chkpoint is absent. Therefore, the log under start is searched and "end T1" is found, indicating that the transaction at T1 has been completed. You only need to find T2 to enable and start to redo it. then you can use start checkpoint (T1, T2) to locate start T2, and then start to redo T2, that is, in this log, T2 and T3 need to be redone and then redone. (Note: I have just talked about T3. then I have talked about redo T2. this does not mean that the real order is like this. In fact, the recovery manager is used to analyze the transactions to be redone first, .)

Well, this article is written, and it's time to end. the undolog description is here. I hope this will help you.

In the next article, we will describe redolog, undolog, and redolog are both Database fault recovery mechanisms, but they are not the same as the implementation and principles of undolog. Next we will introduce it.

This article comes from my personal blog http://www.log4myself.info/archives/293

BitsCN.com