Chinaunix

标题: mysql cluster纯属招摇撞骗(结贴) [打印本页]

作者: la19850302 时间: 2010-02-22 12:41
标题: mysql cluster纯属招摇撞骗(结贴)
本帖最后由 la19850302 于 2010-02-25 19:03 编辑

三个月之前,我抱着将mysql cluster成功应用于生产环境的雄心烈志,期望成为国内mysql cluster应用权威 .

三个月的摸索,多方位的稳定性测试,多方位的性能测试,bug跟踪,阅遍官方手册,NDB API,终日混迹于cluster官方论坛.

三个月之后,我只有这个想法:mysql cluster就是个早产的婴儿, 谁养谁折腾.看看从7.0.0到7.0.9的changehistory ,这些改变特性和bug有多么的严重,用于线上纯属YY.

现在,我只想在论坛里吼一嗓子:你们有谁将mysql cluster成功的应用于生产环境,或者见过哪个公司应用在生产环境上应该mysql cluster技术,甭管是自主定制的还是由付费给mysql官方定制的.我叫您一声爷,你回答一句:是或不是?.

不要再随便贴个mysql cluster初级安装贴,然后装得像个大师似的贴那么几句官方的宣传语来忽悠大众了,文字机巧,有什么意思呢.

我敢说,真正可靠的mysql cluster的技术足够写一本几斤重的书,我测试这么久,配置部署,稳定性,性能,日常管理操作的文档都几个M了.可惜到目前为止,我测出来的只是一个让人失望的结果.

各位爷,你们真的有用过mysql cluster吗?

作者: Coolriver 时间: 2010-02-22 13:36
感觉MySQL Cluster的结构就是一个鸡肋产品。产品定位设计都有点山寨做法。

不过，真的可以用。需要比较了解才行。问题也比较多。

所以我也从不建义别人用MySQL Cluster。

作者: la19850302 时间: 2010-02-22 13:47
终于有版主大人回应了,

希望权威人士能给后来者在cluster实际应用方面提些建议

是啊,同感啊,我之所以发出这样的尖锐的批评是希望其他的DBA不要被市面上的一些话冲昏了头脑,在官方都没有成熟的资料发布之前,要自己来发现这些问题,解决这些问题,成本极大,时间,精力,能力的要求都很高.

目前情况下,了解下基本原理尚可,真刀真枪的干那可得有心理准备.

当然,我会秉承务实的态度继续研究新版本,若能解决各类问题,上线使用,出书都可以了.

作者: bluenight_angel 时间: 2010-02-22 16:07
顶！

作者: 聪明笨小孩 时间: 2010-02-22 16:24
没有亲自测试过，不清楚路过

作者: ruochen 时间: 2010-02-22 18:06
可以看出：LZ也是个务实的人

我也从来没有用这个，也没有建议别人用这个，据说能达到99.99%的可用性

作者: 阿辉 时间: 2010-02-23 09:34
mysql cluster 四年前是这样，现在还是这样，没有一点进步。

作者: yueliangdao0608 时间: 2010-02-23 11:19
说实话，MYSQL CLUSTER的应用的范围跟MYSQL本身是不可同日而语的。所以，在你测试的时候，不妨想下自己的测试用例是否适合MYSQL CLUSTER？而不要一概而论！

作者: 5sky 时间: 2010-02-23 11:57
楼主能否提供一些有说服性的数据出来呢? 毕竟有数据才能证实你辛苦测试的结果，免得大家再走弯路

作者: cugb_cat 时间: 2010-02-23 14:10
所以，我们自己做mysql cluster了，呵呵，自己做一套分布式引擎。

作者: la19850302 时间: 2010-02-23 16:54
本帖最后由 la19850302 于 2010-02-24 09:20 编辑

回复 9# 5sky

可以, 篇幅有限,我针对几个比较严重的问题列出测试结果,也是我正在力图解决的问题

1 稳定性和可靠性:平均无故障时间等指标是说明系统的可靠性的。

cluster的核心宗旨是为了解决高可用问题,所以这稳定可靠性对cluster是最高准则.要让系统稳定可靠,就应该对系统的出错机率、性能劣化趋势有足够的了解.

具体问题:	测试原因
a mysql-cluster 重启非常慢的问题	随着数据量的增大,数据节点的重启时间随着数据量的增大而增加,这个特性影响以下方面: 1 重新配置数据节点参数 2 需重启数据节点的其他重要操作
b ndbd进程消耗巨大内存,大量内存目前未知用途,回收困难	NDB数据全部存放在内存中,如果在上线前无法估算系统使用的内存,而任其无法预测的增长,那么系统毫无稳定性可言,实际因为内存问题导致系统crash的各类bug层出不穷
c 各类目前无法解决的bug	测试这段时间,极少的数据量情况下Mysql节点自重启多次,单个数据节点失败每周一次,错误日志抽象深涩,严重bug举例: Bug#

下面是内存超额分配的测试, 系统内存越大超支使用表现越严重

初始化 ndbd --initial

[config]

noofreplicas=2

DataMemory=500M

IndexMemory=250M

ndbd进程实际分配内存1.0g

疑点一 DataMemory+IndexMemory=750M< 实际使用1.0g

插入总量在140M的数据后(根据原理估算到的所有节点DataMemory+IndexMemory总量,这个有做过测试,估算结果基本正确),进程使用内存增加到1.1g

疑点二:已经预分配DataMemory+IndexMemory的还没用完,这么小的数据量为何还需分配100M的内存.用到哪里了?

2 性能

这里我不将测试方案贴出来,主要从数据量,访问类型(查询或更新),并发这3个方面做的对比测试,在粗放的参数配置下(即只针对cluster的主要参数做调整配置,不可能精细的测试每个参数不同值下的性能),相同的硬件配置,性能不及innodb的1/10.

当然,性能测试不是重点,这项任务弹性很大,需要投入更多的时间.同时,软硬件环境不同,这个结果的参考性意义也不大,但纵观讨论cluster性能的文章,其性能情况一点也不乐观,话说到这里,想到cluster用了这么多内存,我又忍不住想骂了.

3 管理成本:

1 文件系统:数据节点空间消耗非常大,同样不可预测的文件大小.对于cluster的文件系统结构和作用,只在NDB API第5章中简单的介绍了下,实际情况下空间使用多的过分,完全不知道为什么这么的文件空间.

2 备份方式:NDB有自己的备份命令,简单测试过,备份时间较长,备份文件较大,恢复方式更加恶心,居然要对每个数据节点进行恢复操作.

3 自带管理工具使用文档简陋.对这些工具命令参数和输出内容的说明很少,使用不便

总结:在一个以高可用为最高目标的系统里,如此贫乏的技术支持,以及尚不成熟的产品质量,实在难以让人接受.

作者: la19850302 时间: 2010-02-23 17:04
回复 8# yueliangdao0608

当初希望使用mysql-cluster的时候,就是希望利用这个产品的高可用性

我们计划使用的仅仅就是它的这个特性,希望用到部分支付业务上,数据量不大,对性能要求也不高,只希望他高可用,稳定可靠,这个应该是符合cluster的宗旨的.

而至于他的复制特性,分区特性,自带备份,磁盘数据等等特性都不会使用到.

作者: justlooks 时间: 2010-02-24 08:45
看了你总结的几点，我觉得你还是应该认认真真的读手册

作者: la19850302 时间: 2010-02-24 09:12
回复 13# justlooks

英文手册我是有点走马观花,中文手册通读下来,不知道哪里可以回答下面几个问题,楼上提点下就可以了

1  NDBD节点上ndbd进程的内存如何使用规划,我希望可以详尽到oracle内存结构的程度

2  NDBD重启时间过长是在7.0.9才改正的特性,不知道哪里有错

3  NDBD的文件空间之巨,我插入不到1G的数据居然在ndb_nodeid_fs达到20G,这如何解锁

希望楼上详解,无论是非,我希望客观详尽的答案

作者: lys0212linux 时间: 2010-02-24 09:35
留贴等精彩的“论剑”

作者: maque0312 时间: 2010-02-24 09:35
围观。

作者: 枫影谁用了 时间: 2010-02-24 09:53
具体的还需要看看测试方案与细节啦。

虽然不就很如意，但也没有如此差啦。

作者: 小木虫子 时间: 2010-02-24 09:55
我以前看过一本书。是网易出的。

mysql集群没有浮动IP的理念，当一个节点挂了，得手工修改php程序，把链接数据库的IP改成其他节点的IP。

这样就做不到7*24*365。很不方便。

作者: la19850302 时间: 2010-02-24 10:01
回复 18# 小木虫子

这个用lvs+keepalive倒是可以实现其可靠性

本贴的重点是想探讨NDB的高可用性,至于性能和管理方式,解决方式很多,可以不用追究

作者: 小木虫子 时间: 2010-02-24 10:06

回复小木虫子

这个用lvs+keepalive倒是可以实现其可靠性

本贴的重点是想探讨NDB的高可用 ...
la19850302 发表于 2010-02-24 10:01

oracle就不存在这个问题吧，自身就解决了。

作者: la19850302 时间: 2010-02-24 10:24
回复 20# 小木虫子

必须滴,Oracle就像一个上了40的中年男人,沉稳有力(稳定成熟),不苟言笑(管理操作严谨),严肃冷漠(没钱滚开).Mysql整体感觉是90后的小姑娘,只要你能搞定我,我就让你泡.

作者: 小木虫子 时间: 2010-02-24 10:34

lol

作者: liang3391 时间: 2010-02-24 10:36
回复 21# la19850302

分析的太精辟了

作者: unixpm 时间: 2010-02-24 14:03
回复 21# la19850302

作者: cst05001 时间: 2010-02-24 15:52
求楼主实际数据以供学习

作者: la19850302 时间: 2010-02-24 17:09
哈哈,下午新安装了ndb7.0.9,干净清爽啊,曙光乍现.

反正还有一个多月的测试时间,现在测试出来的问题还是非常多,不能发出来误认子弟

待下个月最后总结,帖子大大的有.

其实ndb没有我喷的这么烂,之所以采用标题党,是想吸引下眼球,找出大鸟来指点迷津

作者: yueliangdao0608 时间: 2010-02-24 22:38

回复 yueliangdao0608

当初希望使用mysql-cluster的时候,就是希望利用这个产品的高可用性

...
la19850302 发表于 2010-02-23 17:04

既然你要用到CLUSTER的高可用性，那我想，你的测试就没有任何对比意义了。

作者: la19850302 时间: 2010-02-25 09:20
本帖最后由 la19850302 于 2010-02-25 09:21 编辑

回复 27# yueliangdao0608

高可用测试方面我没有和其他引擎做对比,高可用测试的测试内容一直都是cluster本身的稳定性特性

在性能测试的时候才做过对比

作者: yaoaiguo 时间: 2010-02-25 09:26
我2006年底尝试用过，那时候觉得很不可靠，当然只研究了很短时间，也许是水平不够，就没再研究了。

现在这么多年过去了，mysql cluster还没有进步吗？

作者: lovechina 时间: 2010-02-25 10:16
la19850302
~~~~~~~~~兄弟，在solaris10下面测试过吗？我根本跑不起来，我发帖子在
http://bbs.chinaunix.net/thread-1669300-1-1.html

请帮忙解决!万分感激！！！

我随时在线，我的msn：ybxiang81@hotmail.com

其他朋友，如果能帮我解决的话，也非常感谢！！！

作者: la19850302 时间: 2010-02-25 11:21
本帖最后由 la19850302 于 2010-02-25 11:24 编辑

回复 30# lovechina

帖子看了,没在solaris下部署过

/usr/local/mysql/bin/perror ndb 157
OS error code 0:  Success
MySQL error code 157: Could not connect to storage engine

帖子中有

  [ndbd(NDB)] 2 node(s)
id=2 @10.80.1.15 (mysql-5.1.39 ndb-7.0.9, starting, Nodegroup: 0)
id=3 (not connected, accepting connect from 10.80.1.16)

不知道你的NDBD节点是否完全启动,必须等NDBD全部起来的  ps -ef|grep ndbd

作者: albeta 时间: 2010-02-25 13:04
有没有折腾PostgreSQL的啊

作者: huzi1986 时间: 2010-02-25 13:35
继续等待

作者: babyyellow 时间: 2010-02-25 14:17
国内好像有个人用

我记得官网是有一个介绍的，不是7.xx

好像是跟出版系统或者版权系统有关系的部门。

从oracle 迁过来的。

没有你说的那么烂，移动好像在用吧？

去年，参加mysql的技术日，那个日本的顾问说，移动系统用，

最先是mysql坚持3分钟，就挂了，经过优化后，=
mysql 坚持了20分钟，sqlserver 坚持了7分钟，
总后是mysql拿到了单子

作者: babyyellow 时间: 2010-02-25 14:23
ndb引擎，建议是用api访问的

国内的在用的，我知道的：上海贝尔

作者: la19850302 时间: 2010-02-25 14:32
电信也有用,可惜部署方案文档都十分简陋

是没我说的这么烂,还是很有希望弄起来的,交流下还是好多了

作者: foxpro7 时间: 2010-02-25 17:34

电信也有用,可惜部署方案文档都十分简陋

是没我说的这么烂,还是很有希望弄起来的,交流下还是好多了
la19850302 发表于 2010-02-25 14:32

愿闻其详，是哪个电信系统在用?电信系统大的小的量级可差很多，小的还不如个网站量大，大的。。。我就不细说了。

作者: la19850302 时间: 2010-02-25 18:32
本帖最后由 la19850302 于 2010-02-25 18:34 编辑

回复 37# foxpro7

爱可生公司为电信做过集群,具体信息见他们的公司主页,我看过他们的部署文档,简陋的很.

作者: la19850302 时间: 2010-02-25 19:06
回复 1# la19850302

散了吧,反正还有一个月的时间测试,到时总结吧,再回下去就有点以讹传讹了.

作者: mywander 时间: 2010-02-25 21:25
replication不错。
个人认为如果单纯为了插入性能不如用replication.

作者: bs 时间: 2010-02-26 00:08
莫非只有nosql 才是王道...

作者: bigseacat 时间: 2010-02-26 01:36
测试环境用了，性能不行。还不如主从，读写分离上做文章。

作者: la19850302 时间: 2010-02-26 09:18
我们公司现在几乎所有的业务都有主从

由于是5.1版本的mysql,主从还是有些缺陷

1 资源消耗较大,一个业务两台数据库服务器

2 其逻辑同步设计本身不够严谨,可能导致数据错误

3 不是实时同步,有延迟,最新版本的mysql 6新特性说实现了虚拟的实时同步.

主要是裁剪资源,主从模式确实非常消耗机器的,一台机器两万/年,我们slave就上百台了

作者: libertine3 时间: 2010-02-26 10:09
3年前也想过用mysql cluster，不过测试后认为根本不能用

性能非常的低下，随着节点增多，性能是越发的低

所以当时做的结论是：

mysql cluster 可以适用于数据量非常庞大但却没有什么查询，或者说不做什么查询的应用场合

而如果要大量查询的还是用异步同步吧

作者: la19850302 时间: 2010-02-26 11:11
本帖最后由 la19850302 于 2010-02-26 11:16 编辑

哇哈哈,号外,号外,突破性进展！突破性进展！突破性进展！两三个星期的困扰啊,

终于弄明白NDBD的内存分配机制了,总结:只有猪能想的到,实在太傻了.

结论是:datamemory+indexmemory和ndbd进程的初始内存使用没有关系,而是随数据的增长动态分配的.也就是说这个内存不是预分配的.

那么ndbd节点初始化的时候为哪些pool预分配了内存呢,主要是预分配给了元数据.可以根据下面系列参数算出预分配的内存使用大小:MaxNoOfAttributes,MaxNoOfTables,MaxNoOfOrderedIndexes...

Metadata objects. The next set of [ndbd] parameters defines pool sizes for metadata objects, used to define the maximum number of attributes, tables, indexes, and trigger objects

并非没有看到手册上这段话,后面也有具体的内存使用计算方法,实在是太不敢相信,哥好歹也有点智商吧,根据一个可能达到最大值预分配这么多内存,而不是根据实际元数据分配,这太脑残了吧,我分库分表256*16,这么分配,根本就用不上cluster了,那我还混个屁

作者: la19850302 时间: 2010-02-26 11:14
可能oracle干扰的,其databuffer都是预分配的,元数据也是从数据字典载入,根本没有什么MaxNoOfTables这么个设置,有必要么,再说,动态分配个元数据内存会死人啊.

作者: boean 时间: 2010-02-26 11:30
升华了

作者: 小木虫子 时间: 2010-02-26 13:10
换ORACLE吧，这才是王道。

作者: hwlinux 时间: 2010-02-27 10:36
MySQL当然不能喝Oracle相比,毕竟一个是免费小型的,不能过分要求他的功能,也不能这样骂他是吧。

MySQL cluster 也没有你们说的那么烂.至于说占文件系统.这些内容主要是记录redolog用的。当然这个可以通过配置文件来修改。
一个MySQL集群实际上也存放不了多少数据，存放数据量主要是由内存的大小决定的。
大家在管理节点上执行.all dump 1000.这样你们就可以大概可以计算出你的集群存放了多少数据,还可以存放多少数据。
关于节点容易后从其.我很不赞同，目前我还没看到过哪个节点重启过。

关于数据量大了，集群速度变慢。这是因为启动过程中,mysql先检查日志。日志文件过大，当然速度变慢了。如果你希望快一点的话，你可以配置跳过对日志的check。

用MySQL集群我们主要是为了实现它的高可用性。

关于sql节点不可用时需要更改程序的问题。我们大可用keepdalive+lvs来实现。

最后,我承认MySQL cluster并不是多么多么好，但是我反对大家说MySQL cluster多么垃圾。最后我想问问大家,你们都看过MySQL cluster的官方文档(不是MySQL5.1中文文档,是专门的MySQL cluster文档)吗。

作者: bigarade 时间: 2010-02-27 11:46
将来会有改进的，现在不用就可以了

作者: wolfop 时间: 2010-02-27 22:50
你如果不需要ACID，有必要搞cluster么？自己应用调整调整，适应多个MYSQL主机不挺好。

作者: yueliangdao0608 时间: 2010-02-28 21:09

回复 yueliangdao0608

高可用测试方面我没有和其他引擎做对比,高可用测试的测试内容一直都是clu ...
la19850302 发表于 2010-02-25 09:20

既然知道高可用性是CLUSTER本身的稳定性特征就行了。

性能方面看你怎么测试了，你应该仔细阅读下文档，看看CLUSTER在哪种情况下性能最好！

作者: ecloud 时间: 2010-03-01 12:02
呼唤BJ大神进来喷你

作者: ygl23 时间: 2010-03-01 13:49
MySQL NDB 6.3.20集群安装
http://ginge.javaeye.com/blog/320205

MySQL Cluster(MySQL 集群) 初试
http://imysql.cn/?q=node/96

作者: bbjmmj 时间: 2010-03-01 13:51

呼唤BJ大神进来喷你
ecloud 发表于 2010-03-01 12:02

本大神来也！
MYSQL CLUSTER主要针对的是高可用的应用，比如你需要5个9的可靠性，这个时候ORACLE就只能靠边站了。当然，MYSQL CLUSTER同样也适用高性能应用，MYSQL CLUSTER的性能优势在业务生命周期内会发挥得淋漓尽致，你可以经常性地更换硬件提高集群系统速度，而且不用影响业务运行，你的系统上线第一年可能比不上配置奢侈的ORACLE，但是三年以后，MYSQL的优势就会充分发挥出来。所以说如果需要高性能的话，MYSQL CLUSTER要比其它商用数据库好得多。
另外你也要想到一个很重要的问题，你跟世界最顶级的技术人员PK，三五个月的工夫肯定是不够的，所以你还要从你自身角度考虑一下MYSQL CLUSTER为什么会慢。

作者: ecloud 时间: 2010-03-01 14:18

我知道咋回事了，你没用过，或者虽然用过也没仔细琢磨过，然后你又假象别人不懂，于是就没法沟通了。有些东西要是不会用的话，真的用不好
MYSQL那个CLUSTER是有窍门的，菜鸟上阵当然会碰壁。

大神语录

我觉得告诉他有窍门比直接把窍门告诉他更好些，如果他真的肯钻的话，他会知道得更多。

作者: la19850302 时间: 2010-03-01 14:42
哈哈,大神出现啦

之初做的性能测试之所以烂,可能跟前期很多配置不够仔细深入有关,所以我在性能上都没有仔细追究,我说了性能问题是需要更长的时间投入的

主要的是高可用性测试,我讨论的重点也是高可用性.再深入点,我正在研究的是NDBD节点上ndbd进程内存的分配使用问题,不单是datamemory这些个参数,学习时使用默认参数,看不出啥毛病,后来我导入真实环境的数据,测试了一个多月,长期调整各个参数,发现ndbd进程的内存非常庞大和混乱,无法控制,导致系统的问题.

现在终于明白了是什么原因影响其内存的.升级后重启速度也是飞奔.稳定性问题基本上解决了75%.目前感觉还是不错的,有希望上线.

各位大湿不要喷我啦,我激愤陈词只是想看看cluster应用范围和研究的水平.要和谐.

作者: la19850302 时间: 2010-03-01 14:49
回复 55# bbjmmj

大神已然成道,达则兼济天下,有啥宝贝,比如mysql-cluster性能调整配置等,拯救下还在苦海挣扎的后来者吧,耶稣会记得你的.God bless You !

作者: yueliangdao0608 时间: 2010-03-01 15:01
再跟贴的话就是废话了！

哈哈，估计LZ可能是用激将法来搞大家的。

作者: yueliangdao0608 时间: 2010-08-27 11:24

回复 justlooks

英文手册我是有点走马观花,中文手册通读下来,不知道哪里可以回答下面几个问题,楼 ...
la19850302 发表于 2010-02-24 09:12

中文手册以后尽量少°

作者: ruochen 时间: 2010-08-27 14:11
LS的挖坟了

作者: gogo407 时间: 2010-08-28 01:54
我也来挖下

作者: jerrymy 时间: 2012-05-15 11:43
现在7.2的手册都300多页了。快2年了，不知道楼主的系统运行的怎么样了。

作者: kerlion 时间: 2012-05-15 12:25
提示: 作者被禁止或删除内容自动屏蔽

作者: yuhongchun 时间: 2012-05-15 14:34
提示: 作者被禁止或删除内容自动屏蔽

作者: chinafenghao 时间: 2012-05-30 18:30
这个神贴被挖起来了，我也来挖一下，看看有多少人用CLUSTER的。很多招聘需求都写着熟悉 MYSQL CLUSTER。到底现在有没有大公司在用？有的爷站出来说两句。

作者: anonymous0502 时间: 2012-05-30 18:56
学习了，顶

作者: devilkin0312 时间: 2012-05-31 10:08
楼主分享下数据

作者: anonymous0502 时间: 2012-05-31 10:19
我也觉得很好奇，看招聘要求貌似不少单位都写着要会mysql集群，如果都没人用那要求这个干什么？这似乎也不太合逻辑啊。

作者: Coolriver 时间: 2012-06-04 17:08
在顶一下。
同时说一下自已的看法. cluster不适合用分表的方式，目前测试觉的稳定的可用的也就API方式靠谱了。
BTW: 如果数据节点较多，建议做一个HASH或是别的方式的访问策略。不能建议随机访问数据节点。

作者: lemoncandy 时间: 2012-08-06 19:07

la19850302 发表于 2010-02-22 12:41
三个月之前,我抱着将mysql cluster成功应用于生产环境的雄心烈志,期望成为国内mysql cluster应用权威 . :em ...

干活，学习一下，不过现在的MySQL cluster貌似性能还不错了

作者: horizonhyg 时间: 2012-08-07 10:25
@lemoncandy经测试，限制太多，还是很鸡肋，不如用mongo了

作者: lemoncandy 时间: 2012-08-08 09:04

horizonhyg 发表于 2012-08-07 10:25
@lemoncandy经测试，限制太多，还是很鸡肋，不如用mongo了

总的来说，要看需求的场景吧，前些日子，还有人倒mogodb的后台呢，就是那个10gen公司

作者: horizonhyg 时间: 2012-08-08 10:24
@lemoncandy恩，也是有很多用的，我不才，用不好，总觉得在mysql和mongo之间，这需求太狭窄，有点不伦不类。

作者: bzcat 时间: 2012-08-09 15:58
半年前测过mysql cluster,问题不断，最后还是不上了

作者: action08 时间: 2012-08-10 13:22
Oracle就像一个上了40的中年男人,沉稳有力(稳定成熟),不苟言笑(管理操作严谨),严肃冷漠(没钱滚开).Mysql整体感觉是90后的小姑娘,只要你能搞定我,我就让你泡.

作者: cuyunwu321 时间: 2012-08-13 12:24
mysql cluster网上确实少见部署文档

作者: leimingbuaa 时间: 2014-05-16 11:52
现在呢？快过去2年了7.2集群了，有人测试过稳定性和性能吗？结果如何

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)