1. 背景
前段时间, 由于运维同事的一次误操作, 清空了内网核心数据库, 导致了公司内部管理系统长时间不可用, 大量知识库内容由于没有备份险些丢失.
结合这两天微盟的删库跑路事件, 我们可以看到, 数据库的备份与恢复显得尤为重要.
本文将对此次内网数据恢复过程做一些整理, 介绍删库后的抢救方案.
同时, 引发对数据库稳定性的思考.
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 (历史文章查阅非常方便)
来源: https://www.cnblogs.com/awan-note/p/12437071.html