mysql备份数据策略及恢复

备份

一般备份数据的时候，我们可能会是这样做：

mysqldump -u root -p database1 > backup.sql;

这样把数据库database1备份，得到backup.sql
但是有一个问题，就是在备份的同时，数据库在进行数据更新的时候，可能会导致备份的数据不具备一致性。所以要加下面的参数：

mysqldump -u root -p --single-transaction database1 > backup.sql;

使用了选项--single-transaction保证了数据的一致性读，这样备份的数据才是完整的。

mysql如果要使用增量备份，那么就需要启动选项：--log-bin.当然，mysql并不是马上就把执行的sql操作直接打印了二进制文件里面。

增量备份的恢复是：某时间点A的全量备份+时间点A之后的二进制文件。所以，在做时间点A的全量备份的时候，我们要让mysql把二进制日志输出到日志文件里，而不是让它缓存到磁盘里。

mysqldump -u root -p --single-transation --flush-logs --master-data=2 database1 > backup.sql;

--flush-log选项会导致mysql把在内存的日志输出到二进制文件里，这样子，使增量备份的二进制日志是正确的。
经过上面的操作，会发现，backup.sql有类似下面的提示：

-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;

这里说明backup.sql包含了gbichot2-bin.000007之前的数据，从gbichot2-bin.000007开始，后面的都是增量更新；

随着数据累积，二进制的文件也会越来越多，占据大量的磁盘空间。所以可以添加选项，把老的二进制文件删除：

mysqldump --single-transaction --flush-logs --master-data=2 database1 --delete-master-logs > backup.dql

上面的语句会把全量备份之前的二进制日志文件删除。

但是这里有个问题，就是如果数据库集群采用了主从配置，可能会导致从数据库没有同步到主库的数据。要慎用！

恢复

恢复全量数据：

mysql < backup.sql;

恢复增量数据：

mysqlbinlog < gbichot2-bin.0007 gbichot2-bin.0008 ... | mysql

gbichot2-bin.0007 gbichot2-bin.0008 ...为二进制日志文件。