Article Directory
1. Why MySQL needs disaster recovery
- InnoDB's table data is stored in innodb_buffer_pool, but after the data is modified, it will not be written to the disk immediately, but the log will be written first. This log is the transaction log (Redo log). This method is called pre-written log. (Write-Ahead Logging, WAL) method, because writing to disk is random writing, and writing logs is much faster when writing sequentially. The writing efficiency can be greatly improved by using WAL method, that is, the log is written first, and the data is actually written to the The disk is deferred and can be executed when the system is not busy.
- The fact is that InnoDB will flush dirty data to disk in batches according to a certain mechanism. If there is a sudden power failure, InnoDB cannot guarantee that the data has been flushed to the disk, so after the database restarts, it is necessary to perform disaster recovery based on the Redo log (all transaction logs) and the Undo log (uncommitted transaction logs).
2. The steps of MySQL disaster recovery: Redo+Undo
The disaster recovery process can be divided into two steps: redo (redo) and undo (rollback):
- MySQL checks the Redo log and compares it with the database data file, so as to know which committed transactions have not been flushed to the data file on the disk during the downtime, find a certain point in the Redo log, and save this point After that log rerun it again.
- The redo process will cause a problem, that is, it will execute all transactions including uncommitted transactions, but in fact, uncommitted transactions do not need to be executed. Therefore, it will determine which transactions are not committed based on the undo log, and roll back these transactions. Through the two stages of Redo+Undo, disaster recovery is perfectly realized.