DalianSky's Blog

5月24日下午消息，针对5月19日的网络阻塞事件，暴风公司今日向网易科技发来公开信，承认由于其产品和服务上存在缺陷导致事件影响扩大，并称暴风影音已经对软件进行机制修改，程序开发已于今日完成，会马上投入测试和用户更新中。“产品服务的方面，暴风软件的升级机制，存在在网络环境异常情况（如DNS中断）下的考虑不足，”暴风影音在公开声明中表示，“暴风公司立刻开始进行机制的修改。暴风已于本周日完成程序开发，并马上投入到测试和用户更新中。”
这是暴风公司首次承认其软件更新机制有问题，也是在5月19日断网事件发生以后，首次表示承担事件部分责任。

2009年5月19日晚，全国部份省市互联网一度瘫痪，而中国电信第一时间公布的数据显示，在导致网络瘫痪的巨大域名解析诉求中，来自暴风影音的流量高达40%。

不过，一位资深业界人士对网易科技表示：“暴风影音的公开信避重就轻，从根本上来看还是一个公关托辞。并没有对关键问题进行说明，包括发生断网当时40%来自暴风的数据量到底是怎么产生的，以及为什么暴风软件会在未开启的时候也悄然在后台运行程序。”（张娟）

以下是暴风影音公司发来的公开信全文：

暴风公司关于断网事件向网民和新老用户的公开信

各位网民及暴风的新老用户：

在“5.19网络阻塞”事件中，网民和众多暴风影音新老用户的正常生活和工作都受到了影响。在这一事件当中，和众多受害者一样，暴风影音也蒙受了巨大的损 失，但作为事件涉及的重要一方，同时，特别是当有声音质疑暴风并未承担起对用户的责任，暴风意识到需要再次对广大网民和用户表示歉意和进行说明。

在事件发生后，暴风进行了反思，该事件因涉及暴风而扩大了影响，表现出公司在提供的产品和服务上存在不足，需要我们及时完善。暴风公司高度重视这一点，并立刻展开了相关工作，在此也感谢用户和网民及时提出的任何建议和意见。

自19日晚以来，暴风公司几乎倾注全面精力，进行了以下工作：

1、19日晚开始，就在工信部领导下，配合电信、网通，以及dnspod，积极应对处理网络中断问题。协助恢复网络正常服务。工信部已于20日晚发布正式通告，表示“截至20日凌晨1时20分，受影响地区的互联网服务基本恢复正常”。

2、积极收集证据，配合dnspod报案，配合工信部网络安全保障局和公安局网监处调查案情，争取早日捉拿对dnspod发起攻击的事件始作俑者。5月23日晚，dnspod和暴风公司已经将整理好的相关材料和服务器数据上交公安局网监处，正式完成报案程序。

3、在19日晚暴风域名解析服务器发生中断时，迅速协调替代方案，转移DNS域名解析地址。同时，开始紧急部署备份域名解析服务器，并于5月22日完成部署上线，由此杜绝此类问题的再次发生。

4、产品服务的方面，暴风软件的升级机制，存在在网络环境异常情况（如dns中断）下的考虑不足。暴风公司立刻开始进行机制的修改。暴风已于本周日完成程序开发，并马上投入到测试和用户更新中。

最后，暴风一直以来受到广大用户、业界人士和媒体的关注和支持，在此，暴风表示深深的感谢。断网事件发生以来，众多的用户、媒体包括产业人士给予了暴风很大的理解和支持，对于你们的安慰、建议，暴风更是感激。暴风会尽全力配合司法部门尽早缉拿犯罪分子。

暴风网际科技有限公司
2009年5月24日

【网易科技呼吁大家齐动手 展开桌面软件清理行动】此次断网事故或许只是一次意外，但是却是一个比较典型的爆发，我们的报道并非要故意和哪家企业过不去，只是希望借此，网民们都行动起来彻底杜绝此类网络现在习以为常的暗藏后门行为。

刚才同事打电话说家园的mysql数据库报错,登录服务器一看,原来是家园数据库中的某个表出现问题了,具体报错如下：

1

Table './uchgbk/uchome_space' is marked as crashed and should be repaired

提示说家园的帖子表uchome_space被标记有问题，需要修复。我记得以前也出现过类似的问题,但是只要点击Phpmyadmin上的repair按纽就自动修复了,但是这次很绝,什么都没有.于是赶快上网查找原因。最终将问题解决。解决方法如下：

找到mysql的安装目录的bin/myisamchk工具，在命令行中输入：

1

myisamchk -c -r ./uchgbk/uchome_space.MYI

然后myisamchk 工具会帮助你恢复数据表的索引。好象也不用重新启动mysql，问题就解决了。

问题分析：

1、
错误产生原因，有网友说是频繁查询和更新dede_archives表造成的索引错误，因为我的页面没有静态生成，而是动态页面，因此比较同意这种说法。
还有说法为是MYSQL数据库因为某种原因而受到了损坏，如：数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致
MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。

问题的编号为145

2、问题解决办法。

当你试图修复一个被破坏的表的问题时，有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立，删除信息所指出的文件并再试一次–这通常是上一次修复操作遗留下来的。
这三种修复方法如下所示：

1
2
3

% myisamchk --recover --quick /path/to/tblName
% myisamchk --recover /path/to/tblName
% myisamchk --safe-recover /path/to/tblName

第一种是最快的，用来修复最普通的问题；而最后一种是最慢的，用来修复一些其它方法所不能修复的问题。

检查和修复MySQL数据文件
如果上面的方法无法修复一个被损坏的表，在你放弃之前，你还可以试试下面这两个技巧：
如
果你怀疑表的索引文件(*.MYI)发生了不可修复的错误，甚至是丢失了这个文件，你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生
成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上，使用下面的命令删除表的内容：

1

 mysql> DELETE FROM tblName;

在
删除表的内容的同时，会建立一个新的索引文件。退出登录并重新关闭服务，然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。
最后，使用myisamchk执行标准的修复(上面的第二种方法)，根据表的数据的内容和表的格式文件重新生成索引数据。

如果你的表的
格式文件(tblName.frm)丢失了或者是发生了不可修复的错误，但是你清楚如何使用相应的CREATE
TABLE语句来重新生成这张表，你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题，使用上面的方法重建一个新的)一
起使用。首先制作一个数据和索引文件的拷贝，然后删除原来的文件(删除数据目录下有关这个表的所有记录)。

启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了，但是最好你还是执行一下标准的修复(上面的第二种方法)。
3、myisamchk工具介绍（见mysql的官方手册）

可以使用myisamchk实用程序来获得有关数据库表的信息或检查、修复、优化他们。myisamchk适用MyISAM表(对应.MYI和.MYD文件的表)。

调用myisamchk的方法：

1

shell> myisamchk [options] tbl_name ...

options指定你想让myisamchk做什么。在后面描述它们。还可以通过调用myisamchk –help得到选项列表。

tbl_name
是你想要检查或修复的数据库表。如果你不在数据库目录的某处运行myisamchk，你必须指定数据库目录的路径，因为myisamchk不知道你的数据
库位于哪儿。实际上，myisamchk不在乎你正在操作的文件是否位于一个数据库目录；你可以将对应于数据库表的文件拷贝到别处并且在那里执行恢复操
作。

如果你愿意，可以用myisamchk命令行命名几个表。还可以通过命名索引文件(用“ .MYI”后缀)来指定一个表。它允许你通过使用模式“*.MYI”指定在一个目录所有的表。例如，如果你在数据库目录，可以这样在目录下检查所有的MyISAM表：

1

shell> myisamchk *.MYI

如果你不在数据库目录下，可通过指定到目录的路径检查所有在那里的表：

1

shell> myisamchk /path/to/database_dir/*.MYI

你甚至可以通过为MySQL数据目录的路径指定一个通配符来检查所有的数据库中的所有表：

1

shell> myisamchk /path/to/datadir/*/*.MYI

推荐的快速检查所有MyISAM表的方式是：

1

shell> myisamchk --silent --fast /path/to/datadir/*/*.MYI

如果你想要检查所有MyISAM表并修复任何破坏的表，可以使用下面的命令：

1
2
3
4

shell> myisamchk --silent --force --fast --update-state \
-O key_buffer=64M -O sort_buffer=64M \
-O read_buffer=1M -O write_buffer=1M \
/path/to/datadir/*/*.MYI

该命令假定你有大于64MB的自由内存。关于用myisamchk分配内存的详细信息，参见5.9.5.5节，“myisamchk内存使用”。

当你运行myisamchk时，必须确保其它程序不使用表。否则，当你运行myisamchk时，会显示下面的错误消息：

1

warning: clients are using or haven't closed the table properly

这说明你正尝试检查正被另一个还没有关闭文件或已经终止而没有正确地关闭文件的程序(例如mysqld服务器)更新的表。

如果mysqld正在运行，你必须通过FLUSH TABLES强制清空仍然在内存中的任何表修改。当你运行myisamchk时，必须确保其它程序不使用表。避免该问题的最容易的方法是使用CHECK TABLE而不用myisamchk来检查表。