前天，，客户来电说gps巡线系统的后台数据库挂了，原因是原来分配给图片存储磁盘的空间不够了，他调整了一下分区。我让他把整个mysql目录的文件备份下来（后来发现这是多么重要），然后重装一下数据库试试。重装以后发现不行。于是给我让他发了mysql下面的data目录文件给我，还有今年二月份用后台软件备份下来的数据备份也发了过来。
网上查询发现mysql的数据存储在data目录下的ibdata1文件中，使用ue打开该文件，发现全是0，显然不能包含数据，对比公司内部测试使用的mysql服务器，确认该文件用于存储数据库数据。看来只能是使用二月份的备份数据了。
打开二月份备份数据，发现数据库的字符集用的是binary，这是当时不太清楚字符集该怎么设，从别人那里继承来的。试图重装一个mysql，设定为binary，恢复还是有错误。在mysql命令行中手动执行恢复操作，提示是数据库字段宽度不够，手动调整数据库字段大小，成功走完恢复过程，但是恢复出来的数据显示是乱码。
用ue打开备份文件，发现前面是feff，utf的编码标记，后面是有规律的一个字节数据，一个字节的零，手动提取字节数据，恢复出来时可读的，于是想利用程序提取出来非零数据，然后恢复。结果，发现程序死活不能读到标记字节feff。想可能vc2008+win7可能自动给你处理了feff，于是上vmware+dos622+tc2，结果还是一样，查到网上有一篇文章how not to skip bom info (ff fe) when using fread or ifstream? 这个现象一摸一样。就是没有解答。
早晨又想到一个方法，利用文件传输，这下该啥码都出来了吧，于是上串口互联，一个串口打开串口调试软件，另一个串口copy，发现接收出来数据不对，mode命令设之，发现收到的数据和ue的还是不一样啊。对比利用emeditor二进制打开的文件，却发现串口接收的和emeditor的一样。对比emeditor的字节数和文件属性字节数，一致。验证c程序，一致。用emeditor给文件加上utf编码标记，c程序读取，可以读取到bom数据。最后验证ue中间做了手脚，天啊。哎，太相信ue了。
mysql最终恢复却都没用到这些，呵呵。今天客户又打电话过来，问我怎么样了，我交流以后发现，他还是按我说的备份了全部的mysql安装目录，还有，他提到其他盘有一个ibdata1文件，时间太长了，我都忘了，应该是当时我为了数据安全，安装的时候将数据文件放到别的分区中了。这下好了，分析客户发过来的全部资料，清楚了原来安装mysql的原始结构，并且发现原来的mysql配置文件的mysql自动备份存在mysql目录中。于是就超级简单了。停止mysql服务，移掉mysql相关目录，解压客户发过来的数据到mysql安装目录中，修改配置文件，在相应的路径中放置ibdata1，重启服务，ok，一切正常。
想想，linux系的软件还是好啊，恢复起来赶紧利落。