记两次“删跑路”经历

“MySQL从删库到跑路”听起来很不可思议很难发生，但是无奈的事情事实上很容易发生，可能没那么严重而已。

第一次：

1. 旧的服务器版本不好使，并且想修改运维方案，需要给云服务器换系统。
2. 于是使用一个开源的SSH客户端finalshell从服务器上备份网站到本地，wordpress二次开发的网站，一些微信公众号网页小应用，一些用户图片等等，总共有两三百兆的零碎文件。选择了整个文件夹进行传输，经过了很久时间，传输完毕，finallshell没提示错误，点开看了看下载到桌面的文件夹，各个目录都在，点开后下一级目录结构也如预期，看了看文件夹大小，确实有几百M，于是认为备份成功了。
3. 于是就放心的重置了滕腾讯云服务器系统，从ubuntu变为centos。
4. 重新部署，上传备份下来的代码，运行。
5. 发现出事了，运行不了，一通404,503,500错误，于是去找自己编写的代码，发现没了，几百M的文件，只是一些WordPress的备份+某些项目的依赖+部分图片+所有的目录结构，注意是目录结构，目录结构都在，可是里面的文件没有了，再看桌面备份的文件，发现确实没有那些文件。
6. 由于代码没有本地的备份，没有放在任何别的代码托管平台，云服务器没有快照，那几个月开发出来的代码，就这样没了，血淋淋的教训（也不算finallshell的锅吧，文件数目过多，公司网络不稳定等因素都可能是导致备份失败的原因，我依旧是finallshell的忠实用户）。

教训：

1. 当时一个人开发，所有没有使用git做版本控制和代码托管，这是个大隐患（自己电脑坏了，丢了怎么办？）。
2. 为了能随时随地做法开发，我使用开源的可道芒果云在服务器上搭建了一个云桌面，可以浏览器登陆上去修改代码进行调试，非常方便（这是我在本地没有源代码的原因）。
3. 关于文件的备份，只是简单的检验了一下备份是否成功，没有检验备份下来的文件目录的完整性，以后备份应该在服务器上压缩好后再传输，在对云服务器系统进行大的操作以前，一定要创建快照（玩意有什么重要东西备份漏了，还有方法溯源）。

第二次：

1. 项目上线一两个月后，某个MySQL数据库表有近10W条数据了，里面有大的文本字段，这张表dump出sql文件，体积接近300M，可以说很大了。
2. 有一个查询通过长度20位的单号查询，这个单号是char类型的，并且没有建立唯一索引，一次检索需要大约10s时间，太慢了，对表进行切片比较费时间，想建立索引临时提高检索速度，先治标以后再治本。
3. 单号是纯数字的，于是想改成int(20) ,这样建立唯一索引检索起来更快，想着改一下数据类型，应该不会丢失数据，出错了有日志，有回滚机制，况且阿里云的RDS数据库设置了定期快照备份，出问题了恢复应该不难吧，这么想着就操作完了。
4. 回头一看：惨了，改了的这个字段都变成了2147483647，下意识的意识到，这是触碰到了int类型的最大值了吗？
5. 果然是这样，mysql中有符号int类型最大只能存放2147483647这么大的数字，学的不扎实，忽略了这一茬，这个字段数据丢失不恢复，就相当于用户的数据就乱了，重大事故呀，怪自己太马大哈，只能删库跑路了吗？?国庆节加什么班呐，加班准没好事，一首凉凉送给自己。
6. 程序员要冷静鸭～?，时间是凌晨3:00，理论上2:30-6:00之间没人会用我们的系统，时间有限，必须争分夺秒恢复数据。
7. 去看看阿里云RDS镜像，最近的备份在三天前，这要是恢复了，最近三天的这部分数据也没办法拯救。
8. 通过数据库的rollback或者日志来恢复呢？DDL语句自动commit，rollback没意义了； 那么通过日志可以恢复吗？一来阿里云的RDS提供的DMS也没有开放给用户操作日志的控制台，二来理论上日志也就只有一条修改字段的记录信息，不会有丢失前的数据，通过近三天的插入日志找该字段的信息似乎难度也大的可怕。
9. 焦灼之时，忽然发现救命稻草，我的每一条数据有冗余，通过解析大的文本字段，可以找到足够的信息拼接计算出这个字段来，说干就干，吃一堑长一智，这次操作之前先把真个数据库dump下来，然后把这个表dump下来，然后写存储过程，逐条解析文本数据来恢复（存储过程学过之后就没用过，算是复习了一把）。
10. 奋斗一宿快到5:00时恢复好了数据 ，很庆幸数据有冗余，感谢之前没有对数据冗余较真的自己。

教训：

1. 上线项目，一定要勤做备份，没出问题时不要紧，出了问题没那个备份就完蛋了，就像买保险一样。
2. 没有试过的事情，不能算作有把握，就得谦逊的做个备份。
3. 基础要打牢固，我连int类型只能到int(11)，只能存10位数字都不知道，并且已经开始忽略DDL语句自动commit了。
4. 关键性数据冗余有时也是好事。

---

前同事也发生过误删项目数据的问题，吃牢饭的心理准备都有了，所以面对上线项目时，谨慎再谨慎！！多想个万一。