Shulou(Shulou.com)06/01 Report--

Backup principle:

XtraBackup is based on the crash-recovery function of InnoDB. It will copy the data file of innodb, because the table is not locked, the copied data is inconsistent, and crash-recovery is used during recovery to make the data consistent.

InnoDB maintains a redo log, also known as transaction log, a transaction log that contains all changes to innodb data. When InnoDB starts, it checks data file and transaction log first, and does two steps:

When XtraBackup backs up, it copies innodb data page by page without locking the table. At the same time, XtraBackup has another thread monitoring transactions log, and once the log changes, it copies the changed log pages away.

Why the rush to copy away? Because the size of the transactions log file is limited, when it is full, it will start all over again, so the new data may overwrite the old data.

During the prepare process, XtraBackup uses the copied transactions log to crash recovery the backed up innodb data file.

Official principle:

A redo log file, which we can also call a transaction log file, is maintained within InnoDB. The transaction log stores recorded changes to each InnoDB table data. When InnoDB starts, InnoDB checks the data file and transaction log

And perform two steps: it applies (rolls forward) the committed transaction log to the data file and rolls back the modified but uncommitted data.

Xtrabackup remembers log sequence number (LSN) at startup and copies all data files. The replication process takes some time, so if there are any changes to the data file during this period, it will put the database in a different position.

The point in time. At this point, xtrabackup runs a background process that monitors the transaction log and copies the latest changes from the transaction log.

Xtrabackup must do this continuously because the transaction log rotates repeated writes and can be reused. So xtrabackup keeps recording changes to each data file in the transaction log since it starts.

This is the backup process of xtrabackup. The next step is the prepare process. In this process, xtrabackup uses the previously replicated transaction log to perform disaster recovery on individual data files (just as MySQL would have done when it first started).

When this process is over, the database can be restored.

The above process is implemented in the compiled binary program of xtrabackup. The program innobackupex allows us to back up MyISAM tables and frm files, adding convenience and functionality. Innobackupex starts xtrabackup until xtrabackup replicates

After the data file, then execute FLUSH TABLES WITH READ LOCK to prevent new writes and brush the MyISAM data to the hard disk, then copy the MyISAM data file, and finally release the lock.

The backup MyISAM and InnoDB tables will eventually be consistent, and at the end of the prepare process, the InnoDB table data has been rolled forward to the point where the entire backup ended, rather than where it was at the beginning of xtrabackup. This point in time has nothing to do with the execution of FLUSH TABLES WITH READ LOCK

, so the MyISAM table data is synchronized with the InnoDB table data Similar to Oracle, the prepare process of InnoDB can be called recover.

The data replication process of MyISAM can be called restore (restore).

Both xtrabackup and innobackupex provide many features that were not mentioned earlier. There is a detailed description of each function in the manual. In a brief introduction, these tools provide streaming backup, incremental backup, etc.

Various compound backup methods are realized by copying data files, copying log files and submitting logs to data files (roll forward).

Implementation details:

XtraBackup opens the data file of innodb in read-write mode, and then copies it. In fact, it will not modify this file. In other words, the user running XtraBackup must have read and write access to the data file of innodb.

The reason for adopting read-write mode is that XtraBackup uses its built-in innodb library to open files, while the innodb library opens files with rw.

XtraBackup replicates large amounts of data from the file system, so it uses posix_fadvise () as much as possible to tell OS not to cache read data to improve performance. Because the data will not be reused, OS is not so smart.

If you want to cache for a while, a few gigabytes of data will put a lot of pressure on the virtual memory of OS, and other processes, such as mysqld, are likely to be swap, so the system will be greatly affected.

In the process of backing up innodb page, XtraBackup reads and writes 1MB data, 1MB/16KB=64 page at a time. This is not configurable. After reading the 1MB data, XtraBackup traverses the 1MB data page by page, using innodb's buf_page_is_corrupted ()

Function to check whether the data on this page is normal, and if the data is abnormal, reread the page for a maximum of 10 times. If it still fails, the backup fails and exits. When copying transactions log, read and write the data of 512KB each time.

It is also not configurable.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.