标 题: [合集] MySQL创始人提醒使用MySQL 5.1仍需谨慎 zz
发信站: 水木社区 (Fri Dec 26 12:55:04 2008), 站内
☆─────────────────────────────────────☆
kabbesy (Arthas) 于 (Wed Dec 24 00:01:03 2008) 提到:
[转]MySQL创始人提醒使用MySQL 5.1仍需谨慎
2008-12-01 19:28:16 分类：数据库 | 浏览(206)
历经3年的开发，MySQL 5.1总算前几天得以发布，没料到才过两天，MySQL的创始人之一Monty就对新版的MySQL的质量提出了严重的质疑，而且例举了非常详细的理由，这对于MySQL 5.1的应用可谓非常不利。前段时间有传闻说Monty可能会离开Sun，虽然目前事实没有发生，但现在看来Monty与MySQL团队目前的关系确实比较紧张。
Monty建议，如果你正在用MySQL 5.0，想换成5.1但不打算用5.1中的新功能，那么必须进行充分的测试和试运行，最好是等5.1再发布几个更新修正版后才用。如果你想用5.1中的新功能，你最好认为这些新功能的质量只能算beta水平，因此每用一个功能之前都必需仔细测试。如果从来没有用过MySQL的话，可以直接用5.1，因为5.0版毕竟已经too old了。
Monty说5.1的质量并不令人满意，比如说目前仍然有50多个将导致系统crash或产生错误结果的bug、近200个P2优先级的bug和300多个一般的bug未被处理。Monty例举了一些他认为比较严重的bug，接下来对5.1中的新功能的质量一一进行了分析，结果表明这些新功能目前也都还有严重的问题。比如分区有20个左右的bug，存在对分区表进行ALTER TABLE操作时系统crash会导致数据丢失并且通常无法repair、重命名失败时也会导致数据被破坏等严重问题。行级复制则有近30个已知bug，其中最严重的是UPDATE主键将导致行级复制失败（这个问题确实太严重了）问题。其它如Event也有会导致死锁的问题，日志表功能则会导致数据库性能严重下降，以致于官方的公告里都不好意思把这点说出来。
Monty认为导致MySQL 5.1质量不能令人满意的原因并不是因为MySQL的开发团队不够努力，而是很多策略上存在问题。在我看来，MySQL 5.1所范的这些策略性失误对于很多软件开发公司来说都有很好的借鉴意义：
1、MySQL 5.1早早的就标上beta和rc标志，官方这样做是想吸引更多的人来试用5.1（tmd我们一开始还真的被骗，在06年的时候看到5.1已经是beta了，以为马上就会出正式版，所以直接就用了5.1，不过不到三个月发现5.1不行又回退到5.0）。这一策略不怎么成功，但却导致了早在06年5.1的特性就被过早冻结，无法进行大的调整；
2、决定什么时候发布5.1不再取决于产品的质量，而是出于营销的需要。MySQL管理层要求5.1在这个时间发布那就得发布，因为标上GA总比RC好推销，所以在发布5.1时，根据就没有按照既定的发布策略行事（按MySQL的发布策略，GA版应该没有已经的严重问题才能发布）；
3、核心MySQL开发人员被分到很多小组里，只有很少的核心开发人员在完善5.1的质量，反之，这项工作被交给了太多的对系统一知半解的新开发人员，在review的流程上又出了问题，这导致修复一个bug经常带来更多的bug。（这点我深有体会，我们报上去的一个bug，负责处理的开发人员明显是个新手，我们已经把问题描述的很清楚了，这位老兄硬是很久才明白问题的实质原因）
4、QA很晚才开始做，结果后来QA发现的问题被迫被无视，因为要修正这些问题的话将严重拖延5.1的发布时间；
5、MySQL开发团队对bug的优先级有一条很奇怪的规定：很早就被报告的bug优先级比较低，因为他们认为大家都知道有这个bug，会避道而行。这导致那些早早就发现的bug迟迟不会被修复。
通常来说，Sun的大部分产品都有一个独立的发布标准委员会来决定产品的质量是否达到RC或GA的标准，因此Sun的产品品质一般都不错，但对MySQL却没有采用这一策略。这次发布5.1 GA是觉得现在的5.1质量已经比当年的5.0 GA质量好得多了，因此就发布了，很奇怪的逻辑。
Monty说这次的失误并不是Sun的过错，主要是MySQL的遗留问题，MySQL的发布策略一向很糟糕，5.0刚发布的时候质量还要差。希望Sun能够帮助MySQL团队解决这些问题。
总之，对使用者来说，看来目前还不是把MySQL 5.1应用到正式产品环境中去的时候，至少等仔细看看Monty文章里例举的那些bug，看看哪些确实有危险，然后等待这些bug都被fix之后再用吧。
附英文原文
Oops, we did it again (MySQL 5.1 released as GA with crashing bugs)
MySQL 5.1 is now released as "GA".
http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html
☆─────────────────────────────────────☆
kabbesy (Arthas) 于 (Wed Dec 24 00:01:19 2008) 提到:
orz
难得把分区搞出来了居然还有这bug
【 在 kabbesy (Arthas) 的大作中提到: 】
: [转]MySQL创始人提醒使用MySQL 5.1仍需谨慎
: 2008-12-01 19:28:16 分类：数据库 | 浏览(206)
: 历经3年的开发，MySQL 5.1总算前几天得以发布，没料到才过两天，MySQL的创始人之一Monty就对新版的MySQL的质量提出了严重的质疑，而且例举了非常详细的理由，这对于MySQL 5.1的应用可谓非常不利。前段时间有传闻说Monty可能会离开Sun，虽然目前事实没有发生，但现在看来
: ...................
☆─────────────────────────────────────☆
diogin (design universe...) 于 (Wed Dec 24 00:12:54 2008) 提到:
所以还是老老实实用 5.0。。
实际上分区和事件调度都可以在应用程序层做，所以倒也不是那么急迫。
【 在 kabbesy (Arthas) 的大作中提到: 】
: orz
: 难得把分区搞出来了居然还有这bug
☆─────────────────────────────────────☆
kabbesy (Arthas) 于 (Wed Dec 24 00:16:39 2008) 提到:
表分区还是非常非常重要的
应用层hash实在是不方便
事件调度实属mysql本职工作做不好，拿来凑数的
【 在 diogin (design universe...) 的大作中提到: 】
: 所以还是老老实实用 5.0。。
: 实际上分区和事件调度都可以在应用程序层做，所以倒也不是那么急迫。
☆─────────────────────────────────────☆
diogin (design universe...) 于 (Wed Dec 24 00:20:47 2008) 提到:
单机分区的好处是隐藏了下层的物理分区，但其实做分区的目的还是减少单表的大小、
提高并发效率，以及降低单节点的负载。如果考虑到了这点（特别是第二点和第三点），
则大部分高流量站点可以直接把表的shard 分布到各个节点去，这样来模拟分区，同时
还避免了单机无法伸缩的缺点。
【 在 kabbesy (Arthas) 的大作中提到: 】
: 表分区还是非常非常重要的
: 应用层hash实在是不方便
: 事件调度实属mysql本职工作做不好，拿来凑数的
: ...................
☆─────────────────────────────────────☆
kabbesy (Arthas) 于 (Wed Dec 24 00:48:47 2008) 提到:
业务层是可以人工shard，但这就会将数据集可视性给永久的缩小（全表->子表）
db层如果能shard，那是最好的
首先子表的查询性能得以保障（原理上跟应用层shard一样）
同时又可以为一些全表检索提供支持（比如一些olap类操作，应用层shard之后就没法做这种事情了）
Hibernate就有个项目，叫做Hibernate shard，在应用层做分区
原理基本是上述的，但相对于db层就太幼稚了，orm太贪心了一些……
【 在 diogin (design universe...) 的大作中提到: 】
: 单机分区的好处是隐藏了下层的物理分区，但其实做分区的目的还是减少单表的大小、
: 提高并发效率，以及降低单节点的负载。如果考虑到了这点（特别是第二点和第三点），
: 则大部分高流量站点可以直接把表的shard 分布到各个节点去，这样来模拟分区，同时
: ...................
☆─────────────────────────────────────☆
haili (砍头*沽之哉) 于 (Wed Dec 24 11:54:45 2008) 提到:
我总是要串出来说一句，其实还好，如果你的应用不会碰到bug，那么还是
非常非常稳定的（我有一台5.1.19 beta的生产服务器，正常运行了7个月，升级到
5.1.26rc，继续正常到现在）。
btw，分区alter table导致crash甚至无法修复表的bug？
没注意到这个，肯定是有省略。
当然bug是真有，我现在还需要避免一个udf的bug，如果定义的udf对应的.so
文件变了，没有重启服务器直接再定义.so的新函数，服务器立马crash。
最新的bzr branch出来的code中还是有这个bug。
【 在 kabbesy (Arthas) 的大作中提到: 】
: [转]MySQL创始人提醒使用MySQL 5.1仍需谨慎
: 2008-12-01 19:28:16 分类：数据库 | 浏览(206)
: 历经3年的开发，MySQL 5.1总算前几天得以发布，没料到才过两天，MySQL的创始人之一Monty就对新版的MySQL的质量提出了严重的质疑，而且例举了非常详细的理由，这对于MySQL 5.1的应用可谓非常不利。前段时间有传闻说Monty可能会离开Sun，虽然目前事实没有发生，但现在看来
: ...................
☆─────────────────────────────────────☆
Nineteen (古难记录者) 于 (Wed Dec 24 21:11:47 2008) 提到:
所以说还是用Oracle/MS SQLServer之类的商业数据库比较保险
【 在 haili (砍头*沽之哉) 的大作中提到: 】
: 我总是要串出来说一句，其实还好，如果你的应用不会碰到bug，那么还是
: 非常非常稳定的（我有一台5.1.19 beta的生产服务器，正常运行了7个月，升级到
: 5.1.26rc，继续正常到现在）。
: ...................
☆─────────────────────────────────────☆
mpyu (猫扑老于・Chicyu) 于 (Thu Dec 25 09:12:27 2008) 提到:
sqlserver也配和oracle平起平坐?
【 在 Nineteen (古难记录者) 的大作中提到: 】
: 所以说还是用Oracle/MS SQLServer之类的商业数据库比较保险
☆─────────────────────────────────────☆
haili (砍头*沽之哉) 于 (Thu Dec 25 09:56:48 2008) 提到:
其实还好，大部分都是已知问题。
此外，如果产品要进入中低价位市场，或者需要HPC环境时，商业数据库/OS的价格
就太高了。
【 在 Nineteen (古难记录者) 的大作中提到: 】
: 所以说还是用Oracle/MS SQLServer之类的商业数据库比较保险
☆─────────────────────────────────────☆
Nineteen (古难记录者) 于 (Thu Dec 25 13:26:34 2008) 提到:
东西不烂，只有用的人烂不烂。
【 在 mpyu (猫扑老于・Chicyu) 的大作中提到: 】
: sqlserver也配和oracle平起平坐?
☆─────────────────────────────────────☆
mpyu (猫扑老于・Chicyu) 于 (Thu Dec 25 13:38:56 2008) 提到:
东西就是个破烂
向着这垃圾说话的人也是个烂人
【 在 Nineteen (古难记录者) 的大作中提到: 】
: 东西不烂，只有用的人烂不烂。
☆─────────────────────────────────────☆
haili (砍头*沽之哉) 于 (Thu Dec 25 13:49:36 2008) 提到:
这话说的
btw，SQL Server 2000似乎就已经是个过得去的产品了。
当然，内部的细节真的是只有折腾过很久的人才会有体会，有些是公用的
有些不是。
【 在 mpyu (猫扑老于・Chicyu) 的大作中提到: 】
: 东西就是个破烂
: 向着这垃圾说话的人也是个烂人
☆─────────────────────────────────────☆
mpyu (猫扑老于・Chicyu) 于 (Thu Dec 25 13:53:05 2008) 提到:
"置疑" 怎么解决?
【 在 haili (砍头*沽之哉) 的大作中提到: 】
: 这话说的
: btw，SQL Server 2000似乎就已经是个过得去的产品了。
: 当然，内部的细节真的是只有折腾过很久的人才会有体会，有些是公用的
: ...................
☆─────────────────────────────────────☆
haili (砍头*沽之哉) 于 (Thu Dec 25 14:28:45 2008) 提到:
听不懂，有具体示例吗？可能会有人回答你
【 在 mpyu (猫扑老于・Chicyu) 的大作中提到: 】
: "置疑" 怎么解决?
Posts
