记一次MySql灾难性事件

2023年8月8日,本来系一个风和日丽的夏天中的平凡一天,但这种平凡,注定住佢一定唔平凡,唉...现在回忆起都阵阵咁痛!!!

重要嘅事情讲三次,唔好手贱,唔好手贱,唔好手贱

事日,如常上班,本人系一名小小的程序员,经历咗口罩三年,还有一份工作,都觉得系日子过得去吧,所以日常除了常规性嘅系统维护,硬件排障,都无乜其他事情做,当然老细突然加钟,有其他新需求,咁可能都要氪肝完成嘅,做人为两餐,工作求稳定嘛,扯得有D远了,讲返正题,返到办公室,打开系统,睇咗下日志,发现都无乜问题,重点来啦...唔知点解,心血来朝,觉得MySql每次重启之后,都要运行一个批处理,来设置local_infile,以及max_connections有D麻烦,想根治佢,其实这个系统建设初期,我哋就发现MySql就算用语句设置了,重启后,设置项都系会复原嘅.前提系因为我唔知道可以在My.ini设置.都属于老旧问题了.

就系呢个批处理文件:

咁我就去度娘咗一下,了解到可以在My.ini设置.咁我就在服务器找到咗My.ini并用笔记本打开,进去写入,并保存....(一切就从呢度开始了)

就设置了如下图两项

然后我就对MySql服务进行重启(恶梦开始了...这是错误的第一步)

我即刻成个人呆咗...发生咗咩事...点解会咁样...天啊...个个系实时库来架...宜家起唔倒,即系代表系统瘫痪咗,成村人等紧开饭啊.镇定D,镇定D,镇定D...可能系一时嘅假像来,我再去服务控台个度重新试咗下,MySql服务都系启动唔倒...

死了,死了,死了...点算好,系唔系因为我改咗My.ini导致,我写错了???我即刻去打开My.ini将写入那项local_infile=1删除,以及改回那项max_connections=151,并保存My.ini,再去服务控台个度重新试咗下,

无了...无了...无了...呢锅大大锅了.无办法了,先稳住个势先,咁啱系统提示有个windows更新...我就去总务个度报备,话windows更新可能需要时间处理...(此刻我都仲系认为情况可控嘅),然后我就回到岗位,查度娘....试来试去,还是不能令服务启动起来....完了,我坐在岗位上,很无助,很彷徨,点解我会心血来朝,点解我会咁冲动去改My.ini文件.唉...怨恨系无用嘅,啦啦声处理目前嘅问题先,我翻咗下备份日志,发现有一个7月24日的备份文件,(系统都系15天左右一个备份),退而求其次,还原环境用这个备份,令系统可以先跑起来先(`这里是错误的第二步,为什么我不再努力努力,而选择立刻还原环境,恢复备份`)

我先将目前Data里的ibd文件复制出来,好多人可能会问,点解唔系frm和ibd一齐呢,因为我嘅库选择咗innodb_file_per_table=1,会将innodb表从系统共享表空间移动到独立的.ibd文件。上阿里云,重置服务器,安装数据库,还原备份,一顿操作落来都已经中午过后了（呢个期间，总务来催过好多次，我都推微软更新……。哈……。）...呢度不得不讲一下阿里云重置就系快。

现在系统系可以运行了，业务数据却只到7月24日，要谂办法搞返到8月8日啊……。继续度娘，具体嘅方法如下：

`

1. 按照ibd对应的表结构，创建新表；

2. 执行：

ALTER TABLE tablename DISCARD TABLESPACE;

或者

停止mysql服务后，删除对应的 xxx.ibd 文件，然后再启动mysql服务；

1. 执行

ALTER TABLE tablename IMPORT TABLESPACE;

注意：

如果mysql服务启动失败，可在my.ini文件里面配置一下innodb_force_recovery，默认为0，从1开始最高为6，从1开始逐渐尝试。

`

睇上边步骤的操作意义，就系建立与原来相同的表结构，然后再用旧的ibd文件代替新表的，从而恢复数据。重点有几个：

1.相同的表结构。

2.替换旧的ibd文件。

3.innodb_force_recovery值应与旧表一致。

（呢度仲有一个我忽略咗嘅重点：数据库版本应与原来的版本一致）

咁样应该就可以恢复了。啦啦声去另一台云服务器做实验，复制粘贴个D就唔讲了，唯独讲下遇到嘅问题：

1.找不到表空间。



这个是因为细节问题，应该先DISCARD TABLESPACE再IMPORT TABLESPACE如果直接IMPORT TABLESPACE就会报这个错了。

2.复制替换好旧的ibd文件后，IMPORT TABLESPACE时报错



呢个最值钱了，我系揾咗好耐好耐先揾倒呢个方法，原因系：MySql开启了表的统计信息。需要将其关闭先可以再IMPORT TABLESPACE。方法亦很简单：在My.ini文件里边，加入innodb_stats_persistent=OFF

3.问题又回归到事件嘅原点，修改完My.ini文件之后，为什么启动唔倒MySql服务？



呢个就是万恶之源了，其实系当用记事本打开My.ini文件，修改之后补存，存入嘅文件格式唔啱导致嘅，记事本默认保存格式为：UTF-8。方法亦好简单：将My.ini文件另存为ANSI格式。如下图：

致此，所有嘅ibd文件都恢复返了，唉……。总结以下几点人为错误：

1.自己衰手贱。

2.没有彻底找到问题嘅症结点，盲目且失去镇定。

3.由于迫于业务压力，错误选择补救措施。

4.术业能力唔够，有待进一步提高

以此文鞭策自己！