mysql备份与恢复策略

 引用官方文档：(所有的文档只有官方最权威)

Assume that we make a full backup of all our <code>InnoDB</code> tables in all databases using the following command on Sunday at 1 p.m., when load is low:

Full backups are necessary, but it is not always convenient to create them. They produce large backup files and take time to generate. They are not optimal in the sense that each successive full backup includes all data, even that part that has not changed since the previous full backup. It is more efficient to make an initial full backup, and then to make incremental backups. The incremental backups are smaller and take less time to produce. The tradeoff is that, at recovery time, you cannot restore your data just by reloading the full backup. You must also process the incremental backups to recover the incremental changes.

The dump file contains all changes made before any changes written to the <code>gbichot2-bin.000007</code> binary log file or newer.

All data changes logged after the backup are not present in the dump file, but are present in the <code>gbichot2-bin.000007</code> binary log file or newer.

The MySQL binary logs take up disk space. To free up space, purge them from time to time. One way to do this is by deleting the binary logs that are no longer needed, such as when we make a full backup:

Note

    本文转自marbury 51CTO博客，原文链接：http://blog.51cto.com/magic3/1140161，如需转载请自行联系原作者