MySQL数据库Drop Down后的紧急处置

数据库 MySQL
本文作者维护着一个日均3000人在线的网游,近日因为一次复制数据库的过程中没有修改数据库名,导致第二个数据库被全部丢失。这可怎么办?且看摊上大事的作者如何应对。

前言

今天下午3点,我按照惯例,打开游戏服务器,开新服部署嘛,游戏在腾讯开放平台,简单。闭着眼睛都OK。于是一轮子的复制黏贴拷贝,把服务器加起来,然后启动查看日志。

。。。。突然发现不断的有Exception?搞什么?丢失表Usr_user??刚才不是导了数据库吗?不存在?怎么会?

我瞬间意识到。我摊上事了,我摊上大事了。。检查刚才的复制黏贴,发现我没改数据库名,这一下子把第二个服的数据库整个干掉了。

我擦!!不会吧??背后一凉就软滩在凳子上了。

备份?没有。

数据库还有渣吗?select count(*) ....  0!

备份?真的没有。

怎么能没备份啊!

怎么办?几十个玩家充值了几千元。连个影子也没了。

找玩家求饶?送礼包?? 你觉得玩家会放过你?天真。

linux服务器 + mysql数据库 + 游戏缓存 + flash的as3前端。怎么搞。。。我完蛋了。

HOLD住!

我要HOLD住!冷静,虽然大脑一片空白。马上Google找mysql有无自动备份的。。。没看到。问同事,求助。我靠,他们怎么好像没反应啊。。。

这个时候,有个哥们提示我,用 mysqlbinlog。

这玩意是什么。马上google,知道mysql自身会有个操作的备份。我靠!希望来了。赶快进入mysql目录,查看下。果然看到几十个bin文件。

网上继续搜。大概知道mysql会保存30天内的数据库操作在bin文件。OK。

 

我们达洛克2服才刚运行了2天,算起来应该就是最后2个bin文件。还好。用

 

  1. mysqlbinlog --no-defaults mysql-bin.000026 > mysql-bin.000026.txt 

导出了SQL,检查下:

  1. at 472331597 
  2. #130619 18:04:23 server id 1  end_log_pos 472331772     Query   thread_id=2657  exec_time=0     error_code=0 
  3. SET TIMESTAMP=1371636263/*!*/; 
  4. UPDATE USR_RESOURCE SET MODIDATE = '2013-06-19 18:04:23',SILVER = 283 WHERE USERCODE='001UR1371634524003511' 
  5. /*!*/; 
  6. at 472331772 
  7. #130619 18:04:23 server id 1  end_log_pos 472331799     Xid = 226001034 
  8. COMMIT/*!*/; 
  9. at 472331799 
  10. #130619 18:04:23 server id 1  end_log_pos 472331871     Query   thread_id=2657  exec_time=0     error_code=0 
  11. SET TIMESTAMP=1371636263/*!*/; 
  12. BEGIN 

大概是这种结构。

冷静下来,分析了。我还原数据库,只要从建库开始第一个sql重新执行到最后一个。理论上数据库就会被还原。但是bin文件里面是所有的SQL操作,我要筛选出 达洛克战记2服 的。网上说用 cat / more / less 等命令。我靠,这他妈也太复杂了把?

于是我zip了所有bin文件,回传到本地,用c#写了个过滤代码,找到 use darok2_2,知道这段内容都是 达洛克战记2服 的数据。

  1. public void test() 
  2.     FileStream stream = File.OpenRead(@"E:\玩转中国\程序设计\达洛克战记\xtar-backup\svn\达洛克战记2x\svn\server-deploy\mysql-bin.000027.txt\mysql-bin.000027.txt"); 
  3.     StreamReader reader = new StreamReader(stream, Encoding.GetEncoding("GBK")); 
  4.  
  5.     FileStream streamO = File.Create(@"E:\玩转中国\程序设计\达洛克战记\xtar-backup\svn\达洛克战记2x\svn\server-deploy\mysql-bin.000027.txt\000027.out.txt"); 
  6.     StreamWriter writer = new StreamWriter(streamO, Encoding.GetEncoding("GBK")); 
  7.  
  8.     Encoding gbk = Encoding.GetEncoding("GBK"); 
  9.     Encoding utf = Encoding.Default; 
  10.  
  11.     string strLine = reader.ReadLine(); 
  12.  
  13.     while (strLine != null
  14.     { 
  15.  
  16.         if (!strLine.StartsWith("use darok2_2", StringComparison.OrdinalIgnoreCase)) 
  17.         { 
  18.             strLine = reader.ReadLine(); 
  19.             continue
  20.         } 
  21.  
  22.         do 
  23.         { 
  24.             if (strLine == null
  25.                 break
  26.  
  27.             if (strLine.StartsWith("use", StringComparison.OrdinalIgnoreCase) && !strLine.StartsWith("use darok2_2", StringComparison.OrdinalIgnoreCase)) 
  28.             { 
  29.                 strLine = reader.ReadLine(); 
  30.                 break
  31.             } 
  32.  
  33.             if (strLine.StartsWith("INSERT", StringComparison.OrdinalIgnoreCase) || strLine.StartsWith("DELETE", StringComparison.OrdinalIgnoreCase) || strLine.StartsWith("UPDATE", StringComparison.OrdinalIgnoreCase)) 
  34.             { 
  35.                 writer.Write(strLine); 
  36.                 writer.WriteLine(";"); 
  37.             } 
  38.             else 
  39.             { 
  40.             } 
  41.             strLine = reader.ReadLine(); 
  42.  
  43.         } 
  44.         while (true); 
  45.     } 
  46.  
  47.     writer.Flush(); 
  48.     writer.Close(); 
  49.  
  50.     reader.Close(); 

这样,我就得到过滤出来的SQL文件了。本地我建了个数据库测试下,发现第一句就卡死了??HOLD住!!!

再细心看看,发现中文到了txt全部是乱码了。安静思考了下:

linux数据库用的是GBK。因此bin文件导出的格式一定是GBK。那么代码用GBK读取,然后GBK写入就ok了(代码里面已经修复了)

再导入,顺利了。

进入数据库在看,发现中文还是乱码。。。。奇怪。那可能是mysql设置的问题了,和linux环境下不一致。我只要把这些过滤的SQL在达洛克服务器上走一遍应该就ok了。

上传SQL,运行脚本:

  1. mysql -uxxxx -pxxxx darok2_2 <  000027.out.txt. 

等了10分钟。。。进入腾讯朋友网,开启游戏。一切又光明了。

总结:

各位看官,别看我洋洋洒洒几句废话貌似几分钟的事情。在那个接近崩溃,连数据库渣都没的条件下。我是多么惨的度过了2个小时。

 mysqlbinlog

各位真心要记在心里。如果有全量备份+这个增量备份,基本上数据是不会丢失的。嗨。真实虚惊一场啊。

原文链接:http://www.cnblogs.com/zc22/p/3145080.html

【编辑推荐】

 

 

  1. MariaDB 5.3将支持ALTER TABLE的进度提示
  2. MySQL创始人打造MariaDB 全面兼容MySQL 5.1
  3. MariaDB 2周年了
  4. 教你五步优化你的MongoDB
  5. NoSQL在企业中的发展历程

 

责任编辑:彭凡 来源: 博客园
相关推荐

2017-03-14 14:09:08

数据库Oracle备份

2011-03-30 14:08:27

MySQL数据库删除恢复

2018-08-02 11:04:41

数据库迁移数据

2018-03-06 09:54:48

数据库备份恢复

2024-04-10 07:16:17

JDBC驱动MySQL数据库

2011-03-24 11:14:46

2010-06-04 18:45:00

MySQL数据库

2011-05-17 14:46:38

Oracle数据库故障

2018-04-28 15:28:44

数据库MySQL误删除

2011-03-08 08:49:55

MySQL优化单机

2011-05-13 09:42:21

2010-06-09 15:40:59

MySQL数据库文件

2019-08-20 14:02:07

MongoDB数据库恢复数据

2011-03-30 14:19:56

MySQL数据库修改恢复

2011-02-22 14:26:04

ProFTPD

2011-02-22 14:26:04

ProFTPD

2011-08-23 17:45:54

MySQL丢失root密码

2009-05-08 09:56:37

MaxDBMySQL数据库管理

2011-03-09 08:53:02

MySQL优化集群

2017-09-26 13:35:40

Mysql数据库设计树状数据
点赞
收藏

51CTO技术栈公众号