数据库恢复方案

数据库恢复方案

摘要

这里所谈的内容是对备份数据的恢复,不是对损坏数据表的恢复,或者说灾难恢复。

目录

  • 1. 背景
  • 2. 备份方式分析
  • 3. 恢复方案
    • 3.1. 第一种
    • 3.2. 第二种
    • 3.3. 第三种
    • 3.4. 第四种
  • 4. 手工恢复

1. 背景

我们来假设一个场景。

你是否适用 mysqldump 每隔一段时间备份一次数据库,每个备份一个数据文件。

公司决策你是不是因为数据持续增加,有些数据已经不会再查询,会删除旧的历史数据。

有时公司突然说要恢复历史数据,有可能全补回复,有可能部分恢复。

你将怎么做?

2. 备份方式分析

首先看看备份方式,你是不是采用这种方法备份

我使用一串数字表述数据库数据递增情况,数据的增长变化

垂直轴表示备份时间轴

最常见的备份方法,完全备份

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ...
|.......| 第一次备份
|.................| 第二次备份
|...........................| 第三次备份
|......................................| 第四次备份
|................................................| 第五次备份		

下面这种备份方式也比较常见,这种方式很有规律。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ...
|.......| 第一次备份
        |..........| 删除上一次以备份内容,第二次备份
                   |..........| 删除上一次以备份内容,第三次备份数据库
                              |..........| 删除上一次以备份内容,第四次备份
                                         |.........| 删除上一次以备份内容,第五次备份		

更复杂的情况,无规律可循

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ...
|.......| 第一次备份
|..................| 第二次备份
        |......................| 删除一部分数据后同时做第三次备份数据库
                   |......................| 又删除一部分数据,第四次备份
                   |.............................| 第五次备份,没有删除数据
                   |......................................| 第六次备份,依然没有删除数据
                                          |..........................| 删除很多数据,第七次备份		

以此类推,删除原因有多种,如空间不足,改善查询性能...等等

最杂的情况,无规律可循,同时交叉数据可能会有更新

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ...
|...o...| 第一次备份
|.....o............| 第二次备份
        |....o...o.............| 删除一部分数据后同时做第三次备份数据库
                   |.o..o..o..............| 又删除一部分数据,第四次备份
                   |....o......o.......o.........| 第五次备份,没有删除数据
                   |.......o.......o.........o............| 第六次备份,依然没有删除数据
                                          |.o....o......o............| 删除很多数据,第七次备份		

我用'o' 表示与上次备份中有差异的部分。

3. 恢复方案

,最好恢复,第二种。

上面所提三种备份方式

  • 第一种
  • 最好恢复,100% 都能搞定.
  • 第二种
  • 恢复起来稍复杂,仍能搞得定.
  • 第三种
  • 比较复杂,因为本档案中存在重复记录,费点脑筋
  • 第四种
  • 最复杂,看似复杂,其实也不复杂,跟第三种差不多.

3.1. 第一种

这种备份非常简单,菜鸟也搞搞定

文本格式回复

cat dbname.sql | mysql -u user -p pass -h localhost yourdb			

压缩格式恢复

zcat dbname.sql.gz | mysql -u user -p pass -h localhost yourdb			

或者先使用gunzip解压,再恢复数据

gunzip dbname.sql.gz
cat dbname.sql | mysql -u user -p pass -h localhost yourdb			

提示

很多人喜欢用tar打包,我不见这样做,一个文件时无需使用tar打包的,画蛇添足

仅使用gzip压缩,可以方便使用zcat直接操作文件。

3.2. 第二种

这种备份是连续有规律的,只要依次按顺序恢复即可。

zcat dbname1.sql.gz | mysql -u user -p pass -h localhost yourdb
zcat dbname2.sql.gz | mysql -u user -p pass -h localhost yourdb
zcat dbname3.sql.gz | mysql -u user -p pass -h localhost yourdb
...
...
zcat dbname10.sql.gz | mysql -u user -p pass -h localhost yourdb			

也可以跳跃恢复数据

zcat dbname2.sql.gz | mysql -u user -p pass -h localhost yourdb
zcat dbname3.sql.gz | mysql -u user -p pass -h localhost yourdb
zcat dbname5.sql.gz | mysql -u user -p pass -h localhost yourdb
zcat dbname10.sql.gz | mysql -u user -p pass -h localhost yourdb			

反向恢复数据

zcat dbname20.sql.gz | mysql -u user -p pass -h localhost yourdb
zcat dbname15.sql.gz | mysql -u user -p pass -h localhost yourdb
zcat dbname13.sql.gz | mysql -u user -p pass -h localhost yourdb
zcat dbname1.sql.gz | mysql -u user -p pass -h localhost yourdb			

总之怎么恢复都可以

3.3. 第三种

这种恢复建议按照顺序进行,因为重叠数据没有变化,所以即可以顺时间轴恢复也可以逆时间轴,条件是表结构需要有主键(PK)

insert 方式有要求

必须是

INSERT INTO dbtable(f1, f2, f3...) value (v1, v2, v3);
INSERT INTO dbtable(f1, f2, f3...) value (v1, v2, v3);
INSERT INTO dbtable(f1, f2, f3...) value (v1, v2, v3);				

不能是

INSERT INTO dbtable(f1, f2, f3...) value (v1, v2, v3), (v1, v2, v3), value (v1, v2, v3);				

这种备份参数如下

mysqldump -C -hlocalhost -ubackup -p1AyBoc5mp02LDJki5wJ8 --skip-extended-insert -t db_name tbl_name				

这种方式备份,备份文件尺寸会比较大。

正时序恢复案例,

zcat dbname1.sql.gz | sed 's/^INSERT INTO/INSERT IGNORE INTO/' | mysql -u user -p pass -h localhost yourdb
zcat dbname2.sql.gz | sed 's/^INSERT INTO/INSERT IGNORE INTO/' | mysql -u user -p pass -h localhost yourdb
zcat dbname3.sql.gz | sed 's/^INSERT INTO/INSERT IGNORE INTO/' | mysql -u user -p pass -h localhost yourdb			

逆时序恢复数据

zcat dbname3.sql.gz | sed 's/^INSERT INTO/INSERT IGNORE INTO/' | mysql -u user -p pass -h localhost yourdb
zcat dbname2.sql.gz | sed 's/^INSERT INTO/INSERT IGNORE INTO/' | mysql -u user -p pass -h localhost yourdb
zcat dbname1.sql.gz | sed 's/^INSERT INTO/INSERT IGNORE INTO/' | mysql -u user -p pass -h localhost yourdb			

因为有主键,所以已存在的重复记录不会被重复插入。

3.4. 第四种

这种恢复必须按照顺序进行,即可以顺时间轴恢复也可以逆时间轴,但处理上稍有不同.一旦操作错误数据就会损坏,同时也有很多条件。

顺时序恢复数据, 只需将 insert 替换为 replace 即可

replace into dbtable(f1, f2, f3...) value (v1, v2, v3);
replace into dbtable(f1, f2, f3...) value (v1, v2, v3);
replace into dbtable(f1, f2, f3...) value (v1, v2, v3);			

新数据总会覆盖旧数据

但逆向就不同了,逆时序恢复数据与上面第三种相同, 恢复过程中旧数据在 insert 的时候不会覆盖现有的新数据。仅仅将失去的数据恢复到数据库中。

操作要十分谨慎,理解正向与逆向的不同,方能操作。

4. 手工恢复

有时上面所讲的四种恢复方法不能满足你需求,我们模拟一个场景,假如你需要恢复一个时间段的数据,或者ID字段去一个范围等等,上面所举例子均为一刀切。该怎么办呢?

不用担心方法总是有的

INSERT ... SELECT

INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]
    [INTO] tbl_name [(col_name,...)]
    SELECT ...
    [ ON DUPLICATE KEY UPDATE col_name=expr, ... ]		

REPLACE ... SELECT

REPLACE [LOW_PRIORITY | DELAYED]
    [INTO] tbl_name
    [PARTITION (partition_name,...)]  
    [(col_name,...)]
    SELECT ...		

例 1. INSERT ... SELECT

INSERT IGNORE INTO tbl_name_new SELECT * FROM tbl_name_old WHERE name = 'netkiller';
INSERT IGNORE INTO db_new.tbl_name SELECT * FROM db_old.tbl_name WHERE id > '10000';			

IGNORE 将忽略 ERROR 1062 (23000) at line 24: Duplicate entry '100' for key 'PRIMARY'

这里仅给一个简单实例,因为每个人的需求都不同,你只需灵活变通,发挥你的想象力。

原文发布于微信公众号 - Netkiller(netkiller-ebook)

原文发表时间:2017-04-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java架构师历程

MYSQL 浅谈MyISAM 存储引擎

       mysql中用的最多存储引擎就是innodb和myisam。做为Mysql的默认存储引擎,myisam值得我们学习一下,以下是我对《高性能MYSQ...

3632
来自专栏「3306 Pai」社区

关于MySQL 8.0的几个重点,都在这里

在MySQL8.0中重新设计了redo log,主要改进fsync,使得效率更高,减少锁,优化flush机制,不会频繁flush。同时,支持更高用户并发请求。

1000
来自专栏Rgc

mysql数据库优化(四)-项目实战

在flask项目中,防止随着时间的流逝,数据库数据越来越多,导致接口访问数据库速度变慢。所以自己填充数据进行测试及 mysql优化

1253
来自专栏数据和云

如何保持Oracle数据库SQL性能的稳定性

使用Oracle数据库的应用系统,有时出现SQL性能突然变差,特别是对于OLTP类型系统执行频繁的核心SQL,如果出现性能问题,通常会影响整个数据库的性能,进而...

3017
来自专栏架构师之路

数据库中间件cobar调研笔记

13年底负责数据库中间件设计时的调研笔记,拿出来和大家分享,轻拍。文章很长,可提前收藏,转发。 一,cobar是什么 开源的mysql的中间件服务 使用mysq...

3946
来自专栏JavaEdge

MySQL的锁1 MySql的三种锁2 表锁的锁模式3 MyISAM的并发锁4 InnoDB锁问题5 关于死锁6 总结7 索引与锁

6476
来自专栏杨建荣的学习笔记

MySQL断电恢复的一点简单分析

今天有个网友问我一个MySQL的恢复问题。提供的截图如下。 ? 对于这个问题,在一些断电的场景下还是可能出现的。我首先是要确认是否为线上业务还是测试环境...

49110
来自专栏乐沙弥的世界

Percona XtraDB Cluster 的一些使用限制(PXC 5.7)

Percona XtraDB Cluster有众多的优秀特性,使得mysql集群得以轻松实现。但是不要忽略了它的一些限制。如果你无法接受,或者你的应用程序或数据...

1093
来自专栏GreenLeaves

select for update和select for update wait和select for update nowait的区别

CREATE TABLE "TEST6" ( "ID" VARCHAR2(30), "NAME" VARCHAR2(30), "...

21610
来自专栏吴伟祥

为什么子查询比连接查询(LEFT JOIN)效率低

MySQL从4.1版本开始支持子查询,使用子查询进行SELECT语句嵌套查询,可以一次完成很多逻辑上需要多个步骤才能完成的SQL操作。子查询虽然很灵活,但是执行...

1292

扫码关注云+社区