MySQL数据备份方法的选择与思考

       从事DBA的行业也有两年多了，在数据备份上无论是理论和实践上，都积累了一些经验，恰逢这两天又出现一些数据备份方面的问题，这里，我将之前遇到过的数据备份方法简单做个整理。

       我们都知道，保障数据库的稳定、安全、高效运行，是DBA的工作职责所在。对于DBA来讲，要想实现数据安全，数据备份可能是至关重要的一个环节。

       我曾经就遇到过一个案例，业务方误删数据引发故障，要求DBA恢复数据，结果发现当天的数据没有备份，场面一度十分尴尬，本来这个故障是业务引发的，但是由于没有数据备份，最后业务和DBA各打五十大板，一起背锅。如果业务没有要求DBA恢复数据，那么DBA完全可以后续悄悄的将数据备份，最后就可以免于被牵连，当然，生产环境没有如果。

       备份的重要性，自然不言而喻，那么我们常见的备份思路，都可以有哪些呢？根据备份是否影响线上环境，大体可以分为冷备、热备2种方法，其中冷备可以理解是对线上业务有影响，需要离线备份，而热备是对线上业务没有影响或者影响比较小。

       我自己总结了以下方法：

1、rsync、cp拷贝文件

这种方法比较暴力，就是直接停止MySQL数据库，然后通过cp、rsync这种Linux物理文件复制命令，来实现数据的备份。

其中：

cp特指的是备份到当前服务器的其他目录

rsync特指的是备份到其他服务器上

这种方法，要注意下面几点：

a、那对于线上环境来讲，rsync的方法会更好，因为如果服务器宕机了，cp方法备份也会不可用。

b、rsync和cp的方法，都需要在主从架构的从库上，或者是指定备份库上进行。(这里我推荐线上环境使用一主一从一备份的复制架构)

冷备份的最大的优点是速度快、操作简单。

适合大数据库的日常备份。

2、select xxx into outfile语法

    这种方法，其实往往不能叫做备份，因为它其实只备份了一个表的数据，但是它非常有用。

    试想这样一种场景，业务方让你update几百条数据，而表中的数据有上千万条，这个时候，如果备份全表，就显得不那么灵活，而且耗费的时间较长。如果我们使用select的语法，将这些需要修改的数据，先保存到一个txt的文件中，即使update之后，业务反馈和预期不符，也能快速的找到update之前的样子，可以极大的缩短你恢复数据的时间。

这种备份方法适合单个表的某一部分数据变更前的备份。

3、延时从库

    在MySQL中，这种备份方案相对比较少，在MongoDB中，延时从库非常常见。但是延时从库是一种比较好的在线备份手段，它最主要的特点是恢复的可能性高。

    有些时候，你辛苦备份的数据，在其他服务器上，因为各种依赖或者版本问题，导致无法还原一个MySQL实例，这就比较尴尬，而延时从库可以很好的解决这个问题，因为本身从库是运行中的，所以不用担心库起不来的情况。

    延时从库的备份方案中，要控制从库的延时时间，如果设置的过短，可能在主库上引发问题的SQL已经在从库上执行过了，那么就起不到延时的效果，那延时从库就失去意义了。

4、逻辑备份mysqldump

    这可能是最常见的一种MySQL备份方式了，mysqldump这个官方提供的备份工具，可以提供给你某个时间点的一致性快照，可以很清楚的知道当前的时间点，MySQL数据库执行到了那个binlog的位点，恢复的精确性很高。而且，它支持指定库表备份等，功能非常强大。

     它适合数据量在50G以下的数据库备份，超过50G，恢复的时候会特别慢。

     这个不必多说，大家都知道。

     记得加--single-transaction,要不然可能会出现锁表，业务无法写入的问题，曾经有个小兄弟在这里栽倒了。

     它的特点是能够给你某个时间点的数据库快照，而且备份文件总体比较小。

5、xtrabackup备份

    这是另外一种热备份的方式，xtrabackup备份方式可以在不影响数据库写入的情况下对数据库进行热备，本质其实还是物理文件拷贝，比mysqldump的速度要快。

    如果主库读写压力比较小，则可以在主库上直接备份。不过还是建议不要在主库上使用，因为曾经出现过线上主库写入压力比较大，xtrabackup直接把主库备份宕机的情况出现，从库上不停库进行xtrabackup才是相对比较安全的方法。

 它的特点是备份速度快，备份对线上影响比较小。

6、binlog备份

  binlog备份本质上还是SQL语句的备份，类似mysqldump的结果，不过binlog中保留的数据比mysqldump保留的数据多一些。

   如果你拥有这个数据库从启动开始所有的binlog，毋庸置疑，你可以将这个数据库还原出来。但是所有的binlog必定是一个比较比较大的数据量，一般很难保留全量日志，所以binlog备份一般情况下需要搭配快照备份。

    我们可以在一个从库上线停掉复制关系，然后flush log新生成一个binlog，记录为binlog0，然后将这个从库完整的备份拷贝一份，之后保存binlog0往后的所有binlog，这样就能利用从库的完整备份+binlog的方法来恢复从库的数据。

    binlog备份适用于那些binlog写入速度一般的数据库，如果你的数据库binlog刷新的速度很快，那数据容量可能会成为瓶颈。

7、clone plugin

   clone plugin是8.0的一个亮点功能，既可以支持数据备份到本地，也可以支持快速远程拉起一个数据库的从库，是一个值得研究的备份方法。之前的文章中也有详细些过，有兴趣可以去看。也可以参考官方文档。

    但是目前，线上环境使用的比较少，原因是大部分国产数据库目前都停留在MySQL5.7版本，当然，8.0是趋势，没升级的赶快升级吧。

来源：https://cloud.tencent.com/developer/article/1792709