查看原文
其他

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

CSDN云计算 2020-10-16

The following article is from 阿丸笔记 Author 阿丸笔记

来源 | 阿丸笔记

责编| Carol
封图| CSDN│下载于视觉中国

“删库跑路”这个词儿,经常被挂在嘴边当玩笑,是因为大家都知道,一旦真的发生这样的事情,企业损失是无比惨重的。
本文作者为 CSDN 博客的一位博主, 他的描述中得知前段时间作者所在的公司,由于运维同事的一次误操作,清空了内网核心数据库,导致了公司内部管理系统长时间不可用,大量知识库内容由于没有备份险些丢失。
结合近期的删库跑路事件,我们可以看到,数据库的备份与恢复显得尤为重要。
本文将对此次内网数据恢复过程做一些整理,介绍删库后的抢救方案。同时,引发对数据库稳定性的思考。
接下来让我们从作者的角度,来看看他们是如何对数据库进行抢救的。


数据抢修


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

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

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

所以立刻进行另一套恢复方案:
1)用今年2月初的半全量数据恢复一个库A
2)用去年4月份的全量数据恢复一个库B
3)将B数据库中r开头之后的表拷贝一份到数据库A中
4)数据库A中重放近3天的binlog。(注意,binlog回放时间截止到drop命令时间之前)

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、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’.


数据备份


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

1、本地dump备份数据文件

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

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

2、阿里云dts迁移备份

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

可以避免dump还原的过程。

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

3、xtrabackup(简称xbk)

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

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


数据库稳定性思考


不管是运维的误操作,还是删库跑路的事件,从根本上反映了企业数据库稳定性管理的不足。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

无论哪种,都不安全。

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

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

《原力计划【第二季】- 学习力挑战》正式开始!即日起至 3月21日,千万流量支持原创作者!更有专属【勋章】等你来挑战

推荐阅读:真香,朕在看了!

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存