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，如需轉載請自行聯系原作者