MySQL数据库无完整备份删库,除了跑路还能怎么办?

2019/04/10 10:10
阅读数 11

1.背景

前段时间,由于运维同事的一次误操作,清空了内网核心数据库,导致了公司内部管理系统长时间不可用,大量知识库内容由于没有备份险些丢失。

结合这两天微盟的删库跑路事件,我们可以看到,数据库的备份与恢复显得尤为重要。

本文将对此次内网数据恢复过程做一些整理,介绍删库后的抢救方案。

同时,引发对数据库稳定性的思考。

 

MySQL数据库无完整备份删库,除了跑路还能怎么办?

 

 

2.数据抢修

这份内网数据事先没有特意备份,所以一开始认为需要从磁盘恢复数据了。所以紧急联系了数据恢复公司,希望过来恢复磁盘数据。

这里需要注意,数据恢复公司建议马上关机,避免磁盘数据被覆盖。

联系数据恢复公司的同时,运维同事在内网找到了几个残缺的备份文件,包括去年4月份的一个全量备份数据、今年2月初一个半全量备份数据(备份到r开头的表就失败了,剩余表没有备份),以及近7天到binlog日志文件。

所以立刻进行另一套恢复方案:

1)用今年2月初的半全量数据恢复一个库A

2)用去年4月份的全量数据恢复一个库B

3)将B数据库中r开头之后的表拷贝一份到数据库A中

4)数据库A中重放近3天的binlog。(注意,binlog回放时间截止到drop命令时间之前)

2.1 dump文件恢复

一开始想通过阿里云,把dump文件恢复到rds上。

结果发现需要super权限,而这个权限是阿里云高权限账号(另外还有普通账号)也不具备的,问了阿里云也不提供。因此,无法恢复到rds。

所以我们只能把dump文件恢复到本地数据库。

在ECS上建立一个mysql数据库,然后就是dump文件恢复。

有两种方式:

1)命令行恢复

mysql -u root xxxdb < xxxx-backup.sql

2)在mysql客户端中恢复

用root登陆后

use xxxdb;

source /data/xxxx-backup.sql

2.2 binlog文件重放恢复

基于起止时间恢复数据

sudo mysqlbinlog --start-datetime="2020-02-16 17:00:01" --stop-datetime="2020-02-20 17:00:00" —database=xxxdb mysql-bin.000218 | mysql -f -u root xxxdb

--database 指定了使用binlog中的哪个数据库进行导入,否则,如果binlog中有多个库的操作记录,会大量报错。

更多binlog命令参数见:

https://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html#option_mysqlbinlog_database

-f 用于mysql命令,重建过程中如果遇到问题会继续执行而不是中断退出。

Actually mysqlbinlog does not stop after error, mysqlbinlog just converts log file to text format, nothing more. The problem is that mysql client stops after error. Please try 'mysql -f'.

3 数据备份

数据备份可以有多种方式,这里介绍三种

3.1 本地dump备份数据文件

比较方便存储,不过用起来限制也比较多,容易中断。

mysqldump --max_allowed_packet=1024M -u root xxxxdv > 20200219.sql

3.2 阿里云dts迁移备份

可以在阿里云上建一个dts迁移任务(迁移任务基本免费,同步任务收费),然后通过dts将源数据库直接迁移到rds、ecs自建数据库、vpc网络下到自建数据等地方。

可以避免dump还原的过程。

需要有个目标库,备份不是以简单的数据文件形式,而是一个备份数据库的形式。

3.3 xtrabackup(简称xbk)

https://www.percona.com/software/mysql-database/percona-xtrabackup

基于拷贝物理文件和redo来实现备份。

4. 数据库稳定性思考

不管是运维的误操作,还是像微盟这样的恶性事件,从根本上反映了企业数据库稳定性管理的不足。

任何事后抢救的措施,都比不上事前的谨慎防范。

如何提高企业数据库的稳定性,避免出现类似这样的事情呢?

1)统一技术栈,使用云厂商的云数据库

从现在云技术的发展来看,以阿里云、华为云等大厂提供的云数据库,能大大降低企业数据库的运维成本。

虽然云数据库可能比自建数据库的价格贵一点,但是,云数据库提供的完整的配套设施,如备份恢复、监控报警、技术支持、数据库高可用等,都会给企业数据库稳定性带来巨大帮助。从长期来看,能够大大节约企业的运维成本和人力成本。

另外,我特意去看了下阿里云的rds数据库,有完整的备份恢复机制,而且七天内的备份数据是不可删除的。

所以,如果使用了云数据库,那基本上不需要担心数据丢失或者被人恶习删除的问题了。

2)自建数据库的完善备份机制

当然,有的公司虽然使用了云数据库,但是出于数据安全性的角度,还是会有自建数据库的可能。

如果使用了自建数据库,那么一定需要有完善的备份机制。

我司自从发生了误操作删除内网数据的事件后,立刻引起重视,重新盘点梳理了核心数据的备份机制,包括云数据库、自建数据库,对于核心数据(包括但不限于生产数据、内部核心数据等)必须实施定期全量备份,同时考虑末日容灾,实施跨机房、跨云厂商的数据备份。

3)更健全的权限管理系统

除了数据备份外,我们还可以看到,数据库权限管理的重要性。

尤其中小企业,数据库权限要么没有管理,开发人员可以任意操作;要么是集中在少数几个运维同事手上。

无论哪种,都不安全。

最好的方式,还是开发一个统一数据库管理操作平台(或者购买类似阿里云DMS产品),在系统层面进行数据库的权限管控。

所有人员都只能通过这个平台操作数据库,同时,禁用危险命令,对高危操作进行分级审核。

 

看到这里了,原创不易,点个关注、点个赞吧,你最好看了~

知识碎片重新梳理,构建Java知识图谱:https://github.com/saigu/JavaKnowledgeGraph(历史文章查阅非常方便)

扫码关注我的公众号“阿丸笔记”,第一时间获取最新更新。同时可以免费获取海量Java技术栈电子书、各个大厂面试题。

阿丸笔记

原文出处:https://www.cnblogs.com/awan-note/p/12437071.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部