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

时间:2021-09-19 08:10:44

       从事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是趋势,没升级的赶快升级吧。

以上就是MySQL数据备份方法该如何选择的详细内容,更多关于MySQL 数据备份的资料请关注服务器之家其它相关文章!

原文链接:https://cloud.tencent.com/developer/article/1792709