数据库恢复方案

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:

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)

正时序恢复案例,

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 dbname3.sql。gz | mysql -u user -p pass -h localhost yourdb
zcat dbname2.sql。gz | mysql -u user -p pass -h localhost yourdb
zcat dbname1.sql。gz | mysql -u user -p pass -h localhost yourdb
			

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

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);
				

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 INTO tbl_name_new SELECT * FROM tbl_name_old WHERE name = 'netkiller';
INSERT INTO db_new.tbl_name SELECT * FROM db_old.tbl_name WHERE id > '10000';
			

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

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
存储 SQL 关系型数据库
大数据量下数据库分页查询优化方案汇总
当需要从数据库查询的表有上万条记录的时候,一次性查询所有结果会变得很慢,特别是随着数据量的增加特别明显,这时需要使用分页查询。对于数据库分页查询,也有很多种方法和优化的点。下面简单说一下我知道的一些方法。
454 2
|
4月前
|
中间件 关系型数据库 Java
MySQL数据库分库分表方案
MySQL数据库分库分表方案
238 0
MySQL数据库分库分表方案
|
1月前
|
关系型数据库 MySQL 数据库
|
1月前
|
存储 机器学习/深度学习 自然语言处理
LangChain与向量数据库:高效的信息检索方案
【8月更文第4天】随着自然语言处理技术的发展,特别是深度学习的进步,我们能够更加高效地处理大量的文本数据。LangChain 作为一种强大的工具链,旨在简化和加速构建复杂的自然语言处理应用程序。结合向量数据库,LangChain 可以实现高效且精准的信息检索功能。本文将探讨这一组合的工作原理,并通过一个具体的实现案例来展示其在实际应用中的效果。
164 2
|
2月前
|
关系型数据库 MySQL 数据库
|
存储 负载均衡 容灾
MySQL数据库的分布式架构和数据分片方案
MySQL数据库的分布式架构和数据分片方案
|
3月前
|
canal 缓存 关系型数据库
高并发场景下,6种方案,保证缓存和数据库的最终一致性!
在解决缓存一致性的过程中,有多种途径可以保证缓存的最终一致性,应该根据场景来设计合适的方案,读多写少的场景下,可以选择采用“Cache-Aside结合消费数据库日志做补偿”的方案,写多的场景下,可以选择采用“Write-Through结合分布式锁”的方案,写多的极端场景下,可以选择采用“Write-Behind”的方案。
587 0
|
4月前
|
存储 SQL NoSQL
关系数据库与非关系数据库:选择适当的数据存储方案
关系数据库与非关系数据库:选择适当的数据存储方案
|
4月前
|
SQL 存储 关系型数据库
向 MySQL 数据库插入 100w 条数据的优化方案
向 MySQL 数据库插入 100w 条数据的优化方案
76 1
|
4月前
|
关系型数据库 数据库 PostgreSQL
postgresql|数据库|恢复备份的时候报错:pg_restore: implied data-only restore的处理方案
postgresql|数据库|恢复备份的时候报错:pg_restore: implied data-only restore的处理方案
182 0
下一篇
DDNS