MySQL选择合适的备份策略和备份工具

目录
  • 一、多地部署
  • 二、备份的常见分类
    • 1、物理备份 VS 逻辑备份
      • 1)物理备份
      • 2)逻辑备份
    • 2、离线备份 VS 在线备份
    • 3、全量备份 VS 增量备份
  • 三、MySQL中的备份工具
    • 1、物理备份
    • 2、逻辑备份
  • 四、mysqlbackup VS mysqldump
  • 五、如何检测备份的有效性
  • 六、RTO 和 RPO
    • 1、RTO
    • 2、RPO
  • 七、总结

前言:

在确定备份策略和选择备份工具时,应从业务的RTO和RPO出发,结合存储成本综合考虑。数据库备份的重要性毋庸置疑,可以说,它是数据安全的最后一道防线。鉴于此,对于备份,我们通常会做以下要求:

一、多地部署

对于核心数据库,我们通常有两地三中心的部署要求。对于备份来说,也是如此。一个备份应该有多个副本,每个副本存储在不同区域。

多介质部署:

一个备份的多个副本应存储在不同介质上,如磁盘和磁带,防止单一介质失效。

定期检查备份的有效性:

备份只是在做正确的事情,有没有把事情做对,还得依靠备份的有效性检查。前两项,在条件允许的情况下,建议做。第三项必须做。

接下来,我们聊聊备份的相关话题,主要包括以下五方面的内容:

  • 备份的常见分类。
  • MySQL中的备份工具。
  • mysqlbackup与mysqldump的备份恢复速度对比。
  • 如何检测备份的有效性。
  • RTO和RPO 。

二、备份的常见分类

1、物理备份 VS 逻辑备份

1)物理备份

顾名思义,就是备份物理文件。其优缺点如下:

① 优点

  • 备份、恢复速度快。尤其是恢复速度,直接关系着数据库服务的RTO。
  • 无需实例在线。在实例关闭的情况下,可直接拷贝文件,不用担心备份的一致性。关闭实例进行备份,也称之为 “冷备” 。

② 缺点

  • 备份文件大。
  • 恢复时,对平台、操作系统、MySQL版本有要求,必须一致或兼容。
  • 只能在本地发起备份。
  • 因为是拷贝物理文件,即使文件中存在很多“空洞”(大量DELETE导致),也无法通过恢复来收缩 。
  • 对表的存储引擎有要求,无法备份MEMORY表。

2)逻辑备份

备份表的逻辑记录。其优缺点如下:

① 优点

  • 可移植性强。恢复时,对平台、操作系统、MySQL版本无要求。
  • 灵活。尤其是在恢复时,可只恢复一个库或一张表。
  • 对表的存储引擎没有要求,任何类型的表都可备份。
  • 备份文件较小。
  • 可远程发起备份。
  • 恢复后,能有效收缩空间。

② 缺点

  • 备份、恢复速度慢。实际上,单论备份速度,多线程备份其实也不慢。但恢复速度呢,即使是多线程恢复,也很慢。
  • 备份会"污染"Buffer Pool。业务热点数据会被备份数据驱逐出Buffer Pool。

2、离线备份 VS 在线备份

离线备份,又可称之为 "冷备",即实例关闭的情况下进行的备份。此时,只能进行物理备份,即全量拷贝物理文件。在线备份,又可称之为 "热备",即实例运行过程中进行的备份。此时,既可进行物理备份,又可进行逻辑备份。因对业务侵入较小,线上一般使用在线备份。

3、全量备份 VS 增量备份

  • 全量备份,即备份整个实例的全量数据。
  • 增量备份,即只备份上次备份以来,那些发生了"变化"的数据。

通常来说,基于物理备份来实现增量备份较为简单,以MySQL为例,只需判断数据页的LSN是否发生了变化。而对于逻辑备份,就很难实现,如常见的基于某个时间字段来进行增量备份,但其实,很难保证某个时间段之前的数据不被修改或删除。

三、MySQL中的备份工具

1、物理备份

物理备份相关的工具有:

1)XtraBackup

Percona公司开源的备份工具,适用于MySQL、MariaDB、Percona Server。

XtraBackup目前维护的大版本有两个:

  • XtraBackup 2.4,适用于MySQL 5.6和5.7。
  • XtraBackup 8.0。适用于 MySQL 8.0。

之所以要维护两个版本,是因为MySQL 8.0中的redo log和数据字典的格式发生了变化。

2)mysqlbackup

MySQL企业级备份工具( MySQL Enterprise Backup ),适用于MySQL企业版。

3)Clone Plugin

MySQL 8.0.17引入的克隆插件。初衷是为了方便Group Replication添加新的节点。有了Clone Plugin,我们也能很方便的搭建一个从库,无需借助其它备份工具。

三者的实现原理基本相同,都是在备份的过程中,拷贝物理文件和redo log ,最后,再利用InnoDB Crash Recovery,将物理文件恢复到备份结束时的一致性状态。

2、逻辑备份

逻辑备份相关的工具有:

1)mysqldump

MySQL安装包自带的备份工具,单线程备份。

2)mydumper

由Facebook、SkySQL、Oracle和Percona开发人员维护的一个多线程备份工具,可实现行级别的并行备份。

3)mysqlpump

MySQL 5.7引入的备份工具,可实现表级别的并行备份。

4)MySQL Shell

MySQL Shell 8.0.21引入了一个工具-util.dumpInstance(),可实现行级别的并行备份。

这个工具对备份实例和恢复实例的版本有要求:备份实例 >= 5.6,恢复实例 >= 5.7。

5)SELECT ... INTO OUTFILE

SQL命令,可将表记录直接导出到文件中。

下面说说这几个工具的异同点:

  • 从实现原理来看,mysqldump、 mydumper、mysqlpump、 MySQL Shell可归为一类,本质上都是通过SELECT * FROM TABLE的方式备份数据,只不过在此基础上,通过全局读锁 + REPEATABLE READ事务隔离级别,实现了数据库的一致性备份。
  • SELECT ... INTO OUTFILE 充其量只是一个命令,算不上工具,更不用说数据库的一致性备份。
  • 从导出的内容来看,mysqldump、mydumper、mysqlpump 会以INSERT语句的形式保存备份结果,如:
INSERT INTO `t1` VALUES (1,'aaa'),(2,'bbb'),(3,'ccc');

而 MySQL Shell和SELECT ... INTO OUTFILE 是以CSV格式的形式保存备份结果,如,

1       aaa
2       bbb
3       ccc

在恢复,各个工具对应的恢复工具也不一样。具体来说,

mysqldump、mysqlpump对应的恢复工具是mysql客户端,所以是单线程恢复。mydumper对应的恢复工具是myloader,支持多线程恢复。util.dumpInstance()对应的恢复工具是util.loadDump(),该工具实际调用的是LOAD DATA LOCAL INFILE命令,支持多线程恢复。SELECT ... INTO OUTFILE对应的恢复命令是LOAD DATA。

四、mysqlbackup VS mysqldump

下面是MySQL官方提供的一组数据,对比了mysqlbackup和mysqldump备份恢复时间。

第一张图比较的是备份时间,mysqldump是mysqlbackup的49倍。

第二张图比较的是恢复时间,mysqldump是mysqlbackup的80倍。

借此,我们也能看到逻辑备份工具相对于物理备份工具在备份、还原速度上的差距。不过可惜的是,这里没有测试mydumper。毕竟,针对数据量较大的实例,如果一定要使用逻辑备份,大家一般倾向于使用mydumper,而不是mysqldump。

五、如何检测备份的有效性

为什么要检测备份的有效性,原因主要有两个:

  • 验证整个备份环节的可靠性。包括备份参数是否完备,备份集是否有效,备份介质是否损坏等。
  • 通过检查备份的有效性,搭建一套完整的自动化恢复体系。

很多时候,影响数据库恢复时间的并不是备份集太老,而是手动恢复过程中,因为命令、环境、流程的不熟悉,所带来的额外耗时。

如何检测备份的有效性,常用的方法有三个:

  • (1)基于备份恢复实例,看实例能否起来。并在此基础上,进行随机查询。

这种检测方法最简单。一般来说,实例能起来,且随机查询也没问题,就意味着这个备份集是可用的。但备份集可用,并不意味着这个备份集能满足我们的需求,譬如常见的,搭建从库。而且一些常见的问题,如备份中断、参数没指定准确,也无法通过这种方式检测出来。

  • (2)在1的基础上,建立复制。

如果从库在追主库的过程中,没有报错,大概率意味着主从数据是一致的。当然,也只是大概率,并不是100%。

  • (3)在2的基础上,利用pt-table-checksum检查主从数据的一致性。

如果检查结果没问题,则意味着主从数据是一致的,也就间接证明了备份的有效性。但因为pt-table-checksum在运行的过程中,会在chunk级别对表加S锁,对更新频繁的业务,还是有一定的影响。一般来说,线上使用方法2足矣。方法3,因为要检查主从数据的一致性,耗时相对较久,如果要检测的备份集很多,反而会影响检测的效率。

六、RTO 和 RPO

衡量一个数据中心的容灾能力时,有两个常用的指标:

  • RTO:Recovery Time Objective,恢复时间目标。

指的是灾难发生后,必须在这个时间内恢复数据。在恢复数据的这段时间内,服务是不可用的,所以RTO也是服务可允许的最大不可用时间。如果我们要求服务的最大不可用时间是30分钟,那么RTO就是30分钟。RTO 越小,代表容灾系统的恢复能力越强。

  • RPO:Recovery Point Objective,数据恢复点目标。

指的是灾难发生后,数据可以恢复到的时间点。

譬如,我有一个系统,每天0点进行一次全备。当系统出现故障后,会基于上一次的备份来恢复。如果系统在凌晨3点出现故障,我们会丢失3个小时的数据。极端情况下,系统在23:59出现故障,我们会丢失24个小时的数据。这里的24小时就是这个系统的RPO 。

RPO越小,代表系统越能保证数据的完整性。

RTO、RPO与灾难在时间轴上的关系如下图所示:

可以看到,RPO针对的是数据丢失,RTO针对的是服务宕机时间,两者之间没有必然的联系。

最理想的情况是RTO和RPO都为0,这就意味着当灾难发生时,系统会立即恢复,而且数据不会丢失。当然,RTO、RPO越小,需要投入的成本也越高。

具体到MySQL中,为了降低RTO和RPO,我们可以从以下几个方面着手:

1、RTO

  • 增加备份频率,缩短备份周期。
  • 选择物理备份,而不是逻辑备份。
  • 添加延迟从库。
  • 恢复流程的自动化。

2、RPO

  • 增加备份频率,缩短备份周期。
  • 搭建Binlog Server备份Binlog。当出现故障时,我们可以基于备份和Binlog做基于时间点的恢复。
  • 添加延迟从库。

七、总结

从RTO的角度出发,应尽量选择物理备份,而不是逻辑备份。如果要使用逻辑备份,应尽量选择多线程备份工具和多线程恢复工具。

从RPO的角度出发,应尽量增加备份频率,缩短备份周期。但 every coin has two sides,使用物理备份或者增加备份频率,无疑会增加存储成本。所以,在确定备份策略和选择备份工具时,应从业务的RTO和RPO出发,结合存储成本综合考虑。大多数公司会采取一个统一的备份策略,如一天一个全备。虽然灾难情况很少出现,开发和DBA童鞋也应充分理解到这里面的风险,并制定相应的预案及业务兜底方案。另外,对于线上核心业务,如果只有备份,还是很难有效降低数据库服务的RTO和RPO,建议部署延迟从库。

到此这篇关于MySQL选择合适的备份策略和备份工具的文章就介绍到这了,更多相关MySQL备份策略和工具内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 星外科技每天自动备份SQL2000/Mysql的工具

    复制代码 代码如下: @echo off C: CD "C:\Program Files\WinRAR" net stop MSSQLserver winrar.exe a -ag"-[YYYY-MM-DD-HH-MM-SS]" -k -r -s -ibck -inul "E:\SQL2000备份生成的文件.rar" "E:\SQL2000所在数据库的Data目录的位置\*.*" net start MSSQLserver n

  • MySQL数据库备份以及常用备份工具集合

    一.数据库备份种类 按照数据库大小备份,有四种类型,分别应用于不同场合,下面简要介绍一下: 1.1完全备份 这是大多数人常用的方式,它可以备份整个数据库,包含用户表.系统表.索引.视图和存储过程等所有数据库对象.但它需要花费更多的时间和空间,所以,一般推荐一周做一次完全备份. 1.2事务日志备份 事务日志是一个单独的文件,它记录数据库的改变,备份的时候只需要复制自上次备份以来对数据库所做的改变,所以只需要很少的时间.为了使数据库具有鲁棒性,推荐每小时甚至更频繁的备份事务日志. 1.3差异备份 也

  • MySQL的备份工具mysqldump的基础使用命令总结

    MySQL数据库的备份工具有很多,不过这里介绍的是一个小巧好用的mysqldump工具,位于数据库目录下bin/mysqldump.exe.这几天用phpMyAdmin备份数据库的时候出现乱码,反复在本地跟远程的Dreamhost空间上测试了数据库,但是还是导出数据库会出现乱码,应该是phpMyAdmin出现的问题,数据库本身没有问题.扯远咯,呵呵.我Google到的关于mysqldump工具的相关用法. 如果主机主机支持 Shell 的话,可以 SSH 登陆主机,执行如下的命令实现备份与恢复,

  • CentOS7.x 安装mysql5.7 XtraBackUp备份工具使用命令详解

    目录 mysql安装 1.mysql下载 2.安装mysql 3.配置mysql 4.数据库备份 4.1备份的种类 4.2备份时数据库的状态 4.3备份文件的格式 4.4备份内容 4.5备份工具 4.6OUTFILE命令 4.7使用mysqldump进行备份 5.物理备份工具XtraBackUp 5.1实现物理+热备份+全量 备份思路 5.2实现物理+热备份+增量 备份思路 5.3如何实现物理还原 5.4ibbackup工具 5.5XtraBackup工具 6.XtraBackup安装方法 7.

  • Mysql主从同步备份策略分享

    环境:主从服务器上的MySQL数据库版本同为5.1.34主机IP:192.168.0.1从机IP:192.168.0.2一. MySQL主服务器配置1.编辑配置文件/etc/my.cnf# 确保有如下行server-id = 1log-bin=mysql-binbinlog-do-db=mysql  #需要备份的数据库名,如果备份多个数据库,重复设置这个选项即可binlog-ignore-db=mysql  #不需要备份的数据库名,如果备份多个数据库,重复设置这个选项即可log-slave-up

  • 利用Xtrabackup工具备份及恢复(MySQL DBA的必备工具)

    Xtrabackup------MySQL DBA的必备工具 注意: 1)文档参照http://www.percona.com/docs/wiki/percona-xtrabackup:start 2)mysql要使用5.1.50版本或以上. 一.Xtrabackup简介及安装 1.Xtrabackup  是percona的一个开源项目,可以热备份innodb ,XtraDB,和MyISAM(会锁表),可以看做是InnoDB Hotbackup的免费替代品. Percona Support fo

  • 小型Drupal数据库备份以及大型站点MySQL备份策略分享

    中小站点简单备份策略 基于drupal的中小行网站,我们可以使用backup_migrate模块,该模块提供了定期备份的功能,备份的时间.保留多少个备份等等设置,设置好之后,定期执行cron即可备份成功. 一般的Drupal小站,我们只需使用svn即可,在服务器端,我们把备份好的数据提交到svn,就可以达到备份的目的.由于Drupal的备份模块可以设置备份保留的文件份数,因此不会造成太多的备份文件,从而导致svn很大. 下面是一个简单的备份脚本,放置到站点根目录,然后加到crontab每天执行即

  • 貌似很强的mysql备份策略分享

    每日凌晨2:00进行dump对相应数据库进行备份,同时对相应数据库进行binlog日志文件更新.如果发现数据库错误,只需要先恢复上一个dump的备份,然后再还原当天的binlog日志文件. 举例:每日12:00执行: 复制代码 代码如下: mysqldump database --flush-logs -uroot -p --opt > database_20020601.sql 按照日期规则执行. 如果想恢复到今早10点的数据库,那么: 1.完整备份整个当前数据库 复制代码 代码如下: cd

  • mysql备份策略的实现(全量备份+增量备份)

    目录 设计场景 技术点 服务器信息 准备工作 编写全量备份脚本(Mysql-FullyBak.sh) 编写增量备份脚本 设置定时任务crontab 恢复操作 最近项目需要对数据库数据进行备份,通过查阅各种资料,设计了一套数据库备份策略,通过调试运行一周后,目前已经处于平稳运行状态.现在将思路分享出来,同时感谢gredn大佬. 设计场景 1)增量备份在周一到周六凌晨3点,复制mysql-bin.00000*到指定目录: 2)全量备份则使用mysqldump将整个数据库导出,每周日凌晨3点执行,并会

  • MySQL选择合适的备份策略和备份工具

    目录 一.多地部署 二.备份的常见分类 1.物理备份 VS 逻辑备份 1)物理备份 2)逻辑备份 2.离线备份 VS 在线备份 3.全量备份 VS 增量备份 三.MySQL中的备份工具 1.物理备份 2.逻辑备份 四.mysqlbackup VS mysqldump 五.如何检测备份的有效性 六.RTO 和 RPO 1.RTO 2.RPO 七.总结 前言: 在确定备份策略和选择备份工具时,应从业务的RTO和RPO出发,结合存储成本综合考虑.数据库备份的重要性毋庸置疑,可以说,它是数据安全的最后一

  • MySQL 选择合适的存储引擎

    对于数据库这一块询问比较多的就是在 MySQL 中怎么去选择一种何时当前业务需求的存储引擎,而 MySQL 中支持的存储引擎又有很多种,那么 MySQL 中分别又有那些,怎么优雅的使用呢? 划分引擎原因 在文件系统中,MySQL 将每个数据库(也可以称之为 schema )保存为数据目录下的一个子目录.创建表时,MySQL 会在数据库子目录下创建一个和表同名的 .frm 文件保存表的定义.例如创建一个名为 DebugTable 的表,MySQL 会在 DebugTable.frm 文件中保存该表

  • SQL Server数据库设置自动备份策略的完整步骤

    先了解一下:为何要做备份? 数据备份是容灾的基础,是指为防止系统出现操作失误或系统故障导致数据丢失,而将全部或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程.传统的数据备份主要是采用内置或外置的磁带机进行冷备份.但是这种方式只能防止操作失误等人为故障,而且其恢复时间也很长.随着技术的不断发展,数据的海量增加,不少的企业开始采用网络备份.网络备份一般通过专业的数据存储管理软件结合相应的硬件和存储设备来实现. 一. 简单介绍 SQL Server自带的维护计划是一个非常有用的维护工具,

  • mysql数据库备份设置延时备份方法(mysql主从配置)

    一 为什么需要延时备份percona-xtrabackup是一个优秀的用于增量备份的工具.今天我们讲到的延时备份也是使用他们的产品.以前在MySQL AB复制一文中提到了AB复制.我们首先回顾下MySQL复制的相关要点.AB复制又称主从复制,实现的是数据同步.经过以下步骤: 1)主服务器把数据更改记录到二进制日志中,这个操作叫做二进制日志事件: 2)从服务器把主服务器的二进制日志事件拷贝到自己的中继日志(relay log)中: 3)从服务器执行中继日志中的事件,把更改应用到自己的数据上. 在生

  • mysql全量备份、增量备份实现方法

    mysql全量备份.增量备份.开启mysql的logbin日志功能.在/etc/my.cnf文件中加入以下代码: [mysqld] log-bin = "/home/mysql/logbin.log" binlog-format = ROW log-bin-index = "/home/mysql/logindex" binlog_cache_size=32m max_binlog_cache_size=512m max_binlog_size=512m 重启mys

  • mysql mysqldump数据备份和增量备份

    本篇文章主要讲如何使用shell实现mysql全量,增量备份.增量备份在周一-周六凌晨3点,会复制mysql-bin.00000*到指定目录:而全量备份则使用mysqldump将所有的数据库导出,每周日凌晨3点执,并会删除上周留下的mysq-bin.00000*.然后对mysql的备份操作会保留在bak.log文件中.如下图:开始:2013年05月02日 15:10:57 结束:2013年05月02日 15:12:16 20130502.sql.tgz succ是由DBFullyBak.sh产生

随机推荐