MySQL备份恢复设计思路

背景

首先交代一下背景,由于某些因素的限制,我们公司目前的备份策略采用的是隔天全备的方案,增量备份则使用的是binlog server的方式,那么如何快速恢复就成为了我们需要思考的问题

恢复需求

根据我以往的一些经验来说,通常需要从备份恢复数据的场景有如下几种:

1.被误删库了

2.被误删表了,类型为TRUNCATE或者DROP

3.被误删列了,类型为ALTER ... DROP COLUMN

4.被误删数据了,类型为DELETE或者UPDATE或者REPLACE

5.表空间损坏或出现坏块了

根据场景来说,我们可以大致分为两类:

  • 第一类为不可逆恢复,也就是通常的DDL,比如上述的1、2、3、5等场景
  • 第二类为可逆的恢复,通常可以利用binlog进行回滚(要求binlog格式为ROW,binlog_image为FULL),也就是对应上述的场景4

对于第二类的恢复需求一般来说都比较容易处理,可以利用binlog回滚工具,例如业界比较著名的有binlog2sql以及MyFlash等,这里暂不赘述,我们重点来讨论第一类需求。

为了达到快速恢复的目的,业界DBA经常会采用的方式就是部署一个延迟从库来解决,我们公司目前 所有的核心DB都部署了延迟从库。但是即便有了延迟从库,假设我们错过了延迟的时间,或者在后续利用延迟从库恢复的时候指定错了位点,导致了误删DDL同样应用到了从库,这个时候我们就没有办法利用延迟从库这根救命稻草了。

全备恢复(异机恢复)

此时,我们只能通过备份来进行数据恢复了。首先我们需要恢复全备,通常来说就是xtrabackup备份的物理备份了。假设你的备份在远程的机器上,那么你可能需要做如下几步动作来进行全备恢复:

  1. 将备份scp或者rsync到目标实例机器上
  2. 假设备份文件是压缩的情况下,需要解压
  3. 解压完成后,需要apply redo log
  4. 更改文件权限
  5. 假设你直接将文件拷贝到的目标实例的datadir目录下,那么这一步你就可以直接启动mysqld,假设不是,那么你还需要将数据文件move-back或者copy-back到目标实例的datadir
  6. 实例启动

增备恢复

到这里,全备已经恢复完成了,接下来需要做的就是增量恢复了。按照我们之前的备份方案,我们需要通过binlog来完成增量数据的恢复。对于binlog恢复,我们通常需要以下几个步骤

  1. 确定全备对应的binlog位点,也就是需要恢复的起始点
  2. 解析主库的binlog,确定误删数据的位点,作为我们恢复的终点
  3. 利用mysqlbinlog —start-position —stop-position+管道的方式,将binlog恢复到目标实例上

binlog恢复的方式有很多种,你可以用的是原先master上的binlog,也可以用binlogserver上的binlog,需要做的就是找到binlog恢复的终点即可。

增备恢复优化

到这里,你可能会觉得,利用binlog恢复有点麻烦。确实是这样的,利用mysqlbinlog命令并没有办法指定恢复到哪个GTID,只能通过解析binlog,找到需要恢复到的GTID对应的pos位点才行,这对于自动化来说实现起来会比较麻烦。另外,如果利用mysqlbinlog命令恢复,属于单线程恢复,假设需要恢复的binlog量比较多的话,那么这个增量恢复的时间可想而知。

那么有什么办法能加速binlog应用呢?这里我们就想到了MySQL5.7的并行复制,如果我们能用到sql thread的并行复制,是不是这个问题就解决了呢?

master上binlog恢复

我们回到全备恢复的位点,我们将新实例作为原先的master的slave,然后恢复到指定的GTID位置就可以了呢?没错,这是一种非常简便又轻松还不容易出错的方式,并且还可以利用并行复制的原理来加速binlog应用的目的。但是这种方式的一个要求就是原先的master最老的binlog包含了我们需要的起始恢复位点,这个很容易想到,所以,这将成为我们首选的恢复方式。

binlogserver上binlog恢复

假设原先master上的binlog已经被purge了,那么我们那需要从binlog上去恢复。有人可能会想到将binlogserver上的binlog拷贝到原先的master上,然后通过修改binlog index来达到注册的目的,实际上这并不可取,具体原因可以见《手动注册binlog文件造成主从异常》。

我们可以采取的方式是什么呢?就是利用binlogserver做成伪装master,然后将从库change上去,其思想就是欺骗slave,让slave的io_thread将缺失的binlog拉取过来,sql_thread并行应用binlog event(我们将在下一节具体演示这种方式)。

优化后的恢复流程

经过优化以后,我们的增备恢复流程就变成了,首先通过master上的binlog进行恢复,如果发现master上的binlog已经被purge了,那么通过binlogserver上的binlog进行恢复,这样一来我认为是比较科学合理的恢复流程。

各种恢复方式时效性对比

业务恢复

到这里,我们已经完成了全量+增量的备份数据恢复,这个时候需要同研发确认数据,确认完成以后将对应的表恢复到原先的master,通常采用的方式有:

  1. mysqldump导出+导入目标实例
  2. 表空间传输

总结

本节主要介绍了备份恢复的设计流程,在我们没有办法优化全备恢复的情况下,我们通过优化增量备份方式和流程达到缩短恢复时间的目的。并且需要说明的一点是,本节介绍的目前我还没有完全测试,不保证每个点都是正确的,还需要进一步验证,验证通过以后我也会通知大家,并且结合到现有的数据库运维平台,做到自动化恢复

最后还是提醒几点:

  1. 数据是无形的财产,请广大DBA朋友务必做好备份并做好备份验证
  2. 如果有条件的情况下,尽量部署延迟从库
  3. 做好恢复预案,免得恢复的时候手忙脚乱,菊花打紧
  4. 根据场景选择合适的恢复手段,尽量缩短恢复时间

以上就是MySQL备份恢复设计思路的详细内容,更多关于MySQL备份恢复的资料请关注我们其它相关文章!

(0)

相关推荐

  • MySQL数据库备份恢复实现代码

    数据库的备份 #语法: # mysqldump -h 服务器 -u用户名 -p密码 数据库名 > 备份文件.sql #示例: #单库备份 mysqldump -uroot -p123 db1 > db1.sql mysqldump -uroot -p123 db1 table1 table2 > db1-table1-table2.sql #多库备份 mysqldump -uroot -p123 --databases db1 db2 mysql db3 > db1_db2_mys

  • mysql增量备份及断点恢复脚本实例

    简介 增量备份是指在一次全备份或上一次增量备份后,以后每次的备份只需备份与前一次相比增加或者被修改的文件.这就意味着,第一次增量备份的对象是进行全备后所产生的增加和修改的文件:第二次增量备份的对象是进行第一次增量备份后所产生的增加和修改的文件,如此类推. 目的 解决完全备份中时间长.恢复慢的问题,采取了增量备份 特点 优:无重复数据,备份量不大,时间短 缺:需要上次完全备份及完全备份后的增量备份才能恢复,需对增量备份逐个反复恢复,操作繁琐 实现方式 通过mysql的二进制日志间接实现增量备份:

  • 从MySQL全库备份中恢复某个库和某张表的方法

    在Mysqldump官方工具中,如何只恢复某个库呢? 全库备份 [root@HE1 ~]# mysqldump -uroot -p --single-transaction -A --master-data=2 >dump.sql 只还原erp库的内容 [root@HE1 ~]# mysql -uroot -pMANAGER erp --one-database <dump.sql 可以看出这里主要用到的参数是--one-database简写-o的参数,极大方便了我们的恢复灵活性. 那么如何从

  • shell脚本实现mysql定时备份、删除、恢复功能

    mysql备份脚本: 脚本实现:按照数据库名称,全量备份mysql数据库并定期删除 #!/bin/bash #全备方式,一般在从机上执行,适用于小中型mysql数据库 #删除15天以前备份 #作者:lcm_linux #时间:2019.08.06 source ~/.bash_profile #加载用户环境变量 set -o nounset #引用未初始化变量时退出 set -o errexit #执行shell命令遇到错误时退出 #备份用户---需要在mysql中提前创建并授权 #GRANT

  • mysql全量备份和快速恢复的方法整理

    一个简单的mysql全量备份脚本,备份最近15天的数据. 备份 #每天备份mysql数据库(保存最近15天的数据脚本) DATE=$(date +%Y%m%d) /home/cuixiaohuan/lamp/mysql5/bin/mysqldump -uuser -ppassword need_db > /home/cuixiaohuan/bak_sql/mysql_dbxx_$DATE.sql; find /home/cuixiaohuan/bak_sql/ -mtime +15 -name

  • mysql数据备份与恢复实现方法分析

    本文实例讲述了mysql数据备份与恢复实现方法.分享给大家供大家参考,具体如下: 本文内容: 复制文件法 利用mysqldump 利用select into outfile 其它(列举但不介绍) 首发日期:2018-04-19 有些时候,在备份之前要先做flush tables ,确保所有数据都被写入到磁盘中. 复制文件法: 对于myisam存储引擎的数据库,它的表结构(.frm).数据(.myd)和索引(.myi)都单独成文件,可以直接复制这三个文件到备份空间就可以成功备份了. 至于还原,只需

  • mysql8.0.20配合binlog2sql的配置和简单备份恢复的步骤详解

    第一步 安装 1.安装MySQL 2.安装Python3 [root@localhost /]#yum install python3 3.下载binlog2sql文件到本地(文件在百度云盘) [root@localhost /]#mkdir tools [root@localhost /]#cd tools [root@localhost tools]# ll total 317440 -rw-r--r--. 1 root root 317440 Sep 21 23:55 binlog2sql

  • MySQL使用全库备份数据恢复单表数据的方法

    前言 备份数据库时,采用了全库备份,但是因为某些原因需要回滚一个表的数据到备份数据库上,如果回滚整个库就比较费时间,因为可能这个表只有几十M,但是其它表可能有十几上百G,这时候就需要将需要恢复的表提取出来了 我们在实际工作中都遇到过这种情况,一个MySQL实例中可能有多个database.而我们备份时,通常采用完全备份,将所有database都备份到一个文件中. 但是,偶尔会遇到只恢复一个database或者一个表的情况.怎么解决呢? 现在有备份库fdcsqlmysql-2018_11_30-0

  • 浅析MySQL 备份与恢复

    1.简介 数据无价,MySQL作为一个数据库系统,其备份自然也是非常重要且有必要去做.备份的理由千千万,预防故障,安全需求,回滚,审计,删了又改的需求等等,备份的重要性不言而喻.除了备份本身, 如何使用备份来恢复 服务也是一项重点内容,不能用来恢复的备份没有意义.本文主要会针对备份和恢复这两方面做一些简单的介绍. 本文为<高性能MySQL>备份相关章节的读书笔记. 2.备份和恢复的简单定义 正如简介所说,备份人尽皆知,也很容易引起人的重视.根据需求写定期脚本,或者使用其他方式都是比较常见的.但

  • C#实现MySQL命令行备份和恢复

    MySQL数据库的备份有很多工具可以使用,这两天写了一个使用C#调用MYSQL的mysqldump命令完成MySQL数据库的备份与恢复的小工具 先来说一下mysqldump命令备份MySQL数据库的使用方法 mysqldump -hhostname -uusername -ppassword databasename > backupfile.sql 直接将MySQL数据库压缩备份 mysqldump -hhostname -uusername -ppassword databasename |

  • 详解mysql的备份与恢复

    前言: 前面几篇文章为大家介绍了 MySQL 各种语句语法的用法及用户权限相关知识.本篇文章将主要讲解 MySQL 数据库数据备份与恢复相关知识,主要聚焦于逻辑备份,介绍mysqldump工具的使用以及恢复方法. 这里简单讲下物理备份和逻辑备份的概念: 物理备份:备份数据文件,转储数据库物理文件到某一目录.物理备份恢复速度比较快,但占用空间比较大,MySQL中可以用 xtrabackup 工具来进行物理备份. 逻辑备份:对数据库对象利用工具进行导出工作,汇总入备份文件内.逻辑备份恢复速度慢,但占

随机推荐