记一次 MySQL 数据库单表恢复事故处理

mar11

公司 web 服务架设在阿里云全家桶上,数据库用的也是 RDS

记一次MySQL数据库单表恢复事故处理

昨晚 10 点,运营同事在社区发文章,提示创建失败,查看接口项目的日志,是 detail 字段的类型为 text,可能是不够,需要加长,我选择了 mediumtext 类型。

数据类型 长度
TINYTEXT 256 bytes
TEXT 65,535 bytes~64kb
MEDIUMTEXT 16,777,215 bytes~16M
BLONGTEXT 4,294,967,295 bytes~4GB

然后执行一个 DDL 语句,如下:

ALTER TABLE `databasename`.`tablename` CHANGE COLUMN `question_detail` `question_detail` mediumint  DEFAULT NULL COMMENT '内容';

执行完了,好的,告诉运营同事,看下可以发文章了么?

image

还是不行,哦,DDL 写错了,应该是【mediumtext】,这里错了,把正确的 DDL 语句执行一遍,再问下运营同事

ALTER TABLE `databasename`.`tablename` CHANGE COLUMN `question_detail` `question_detail` mediumtext  DEFAULT NULL COMMENT '内容';

记一次 MySQL 数据库单表恢复事故处理

基于一个好的习惯,我再去社区确认下,运营同事的新帖子内容挺不错,在随便点点别的帖子。

嗯?我凑???社区全部帖子的内容变成 0 了,如下

记一次MySQL数据库单表恢复事故处理

懵逼了,生产事故吖,看看咋回事,一个想法闪过,sql 有问题,我用 navicat 生成的 sql 语句,更新后的数据类型应该是【mediumtext】,结果我敲到 med 的时候,他就主动补全了【mediumint】,没有看清,就放到生产执行了,一下子把所有 detail 的内容,强制转换成了数字??

黑人问号脸.jpg

ok,开始想办法恢复数据,中间各种想办法,最后依靠阿里云提供的数据备份管理功能,和本人一瞬间暴涨的工作效率和好运气,在今天凌晨 1 点搞定了。

记一次MySQL数据库单表恢复事故处理

记一次MySQL数据库单表恢复事故处理

记一次MySQL数据库单表恢复事故处理

记一次 MySQL 数据库单表恢复事故处理

至此,我得到了这个表本来的数据了,好在备份时间和发成事故的时间很相近,又是过年期间发帖频率很低,查一下表内行数,好的,备份库的贴子表只差一个生产库一行,应该就是运营那一篇了,哈哈哈。

执行一个兜底命令,重命名帖子表,先不要删掉这个表,避免一错再错

RENAME TABLE  aws_question to aws_question_bak;

然后把导出来的.sql 文件上传到可以连接生产库的服务器,然后把这个.sql 执行下,导入到生产库里

$ mysql -h hostname -u username -p < restore.sql 
Enter password:   #输入root用户的密码。

再回来看看贴子,好的,数据恢复了。

记一次 MySQL 数据库单表恢复事故处理

回过头来,我们在执行一遍更新字段数据类型的 sql

ALTER TABLE `databasename`.`tablename` CHANGE COLUMN `question_detail` `question_detail` mediumtext  DEFAULT NULL COMMENT '内容';

把运营同事新写的文章,从 bak 表拿出来,导入到本表中,至此,数据完全存进去了。

?Happyending?

记一次 MySQL 数据库单表恢复事故处理

阅读 1.9k

WebArtist
专栏包括但不限于linux命令解析和组合使用,日志分析,性能测试,docker,laravel,redis,composer组件...

随我阅尽繁华 归来不忘初心

209 声望
19 粉丝
0 条评论

随我阅尽繁华 归来不忘初心

209 声望
19 粉丝
文章目录
宣传栏