mysql cluster纯属招摇撞骗(结贴)

bs

莫非只有nosql 才是王道...

bigseacat

测试环境用了，性能不行。还不如主从，读写分离上做文章。

la19850302

我们公司现在几乎所有的业务都有主从

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

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

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

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

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

libertine3

3年前也想过用mysql cluster，不过测试后认为根本不能用

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

所以当时做的结论是：

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

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

la19850302

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

终于弄明白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

可能oracle干扰的,其databuffer都是预分配的,元数据也是从数据字典载入,根本没有什么MaxNoOfTables这么个设置,有必要么,再说,动态分配个元数据内存会死人啊.

boean

升华了

小木虫子

换ORACLE吧，这才是王道。

hwlinux

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

将来会有改进的，现在不用就可以了