第17章:MySQL簇 / 17.8. MySQL簇的已知限制

在本节中,我们列出了5.1.x系列中对MySQL簇的一些已知限制,并与使用MyISAMInnoDB存储引擎时可用的特性进行了比较。目前,尚不打算在即将推出的MySQL 5.1版本中处理这些问题,但是,我们将在后续的版本系列中,提供这方面的补丁和修正。如果你检查了MySQL缺陷数据库(http://bugs.mysql.com)中的“簇”类别,可发现我们打算在即将推出的MyAQL 5.1版中更正的已知缺陷(如果标记为“5.1”的话)。

(注释:在本节末尾,列出了在当前版本中已解决的MySQL 5.0簇中的一些事宜)。

·         语法中的不兼容性(运行已有的应用程序时导致错误):

o        不支持文本索引。

o        不支持Geometry数据类型(WKTWKB)。

·         限制或行为中的不兼容性(运行已有的应用程序时可能导致错误):

o        没有事务的部分回滚功能。重复键或类似错误会导致整个事务的回滚。

o        存在很多可配置的硬限制,但能使用簇中的可用主内存设置限制。关于配置参数的完整清单,请参见17.4.4节,“配置文件”。大多数配置参数可在线升级。这些硬限制包括:

§         数据库内存大小和索引内存大小(分别是DataMemoryIndexMemory)。

§         对于能够执行的最大事务数,可使用配置参数MaxNoOfConcurrentOperations进行设置。注意批量加载,TRUNCATE TABLEALTER TABLE是通过运行多个事务作为特殊情况进行处理的,因而不受该限制的约束。

§         与表和索引有关的不同限制。例如,每表的最大有序索引数是由MaxNoOfOrderedIndexes确定的。

o        NDB表中,数据库名称、表名称和属性名称不能与其他表处理程序中的一样长。属性名称将被截短至31个字符,截短后如果不是唯一的,将导致错误。数据库名称和表名的总最大长度为122个字符(也就是说,NDB簇表名的最大长度为122个字符减去该表所属的数据库的名称中的字符数)。

o        所有的簇表行具有固定长度。这意味着(例如),如果表中有仅包含相对较小值的1个或多个VARCHAR字段,与使用MyISAM引擎的相同表和数据相比,使用NDB存储引擎时需要更多的内存和磁盘空间。换句话讲,对于VARCHAR列,它所需的存储空间与具有相同大小的CHAR列所需的相同。

o        簇数据库中的最大表数目限制为1792

o        每表的最大属性数限制为128

o        任一行的最大允许大小为8K不包括保存在BLOB列中的数据。

o        每键的最大属性数为32

·         不支持的特性(不会导致错误,但不被支持或强制):

o        外键结构将被忽略,就像在MyISAM表中那样。

o        保存点以及对保存点的回滚将被忽略,就像在MyISAM中那样。

·         性能以及与限制有关的事宜

o        由于对NDB存储引擎的连续访问,存在查询性能问题,与MyISAMInnoDB的情形相比,执行很多范围扫描时,开销相对昂贵。

o        不支持范围统计中的记录,在某些情况下,这会造成非最优查询计划。可采用USE INDEXFORCE INDEX规避该问题。

o        对于使用USING HASH创建的唯一性哈希索引,如果NULL是键的一部分,不能使用这类索引访问表。

o        MySQL簇不支持磁盘上的持续提交。提交将被复制,但不保证在提交时会将日志写入磁盘。

·         丢失特性:

o        唯一支持的隔离级别是READ_COMMITTEDInnoDB支持READ_COMMITTEDREAD_COMMITTEDREPEATABLE_READSERIALIZABLE)。关于其如何影响簇数据库备份和恢复的更多信息,请参见17.6.5.5节,“备份故障诊断与排除”

o        不支持磁盘上的持续提交。提交将被复制,但不保证在提交时会将日志写入磁盘。

·         与多MySQL服务器有关的问题(与MyISAMInnoDB无关):

o        运行多个MySQL服务器时,ALTER TABLE未完全锁定(无分布式表锁定)。

o        如果在多个MySQL服务器上进行了更新,MySQL复制功能不能正确处理。但是,如果数据库分区方案是在应用级别上完成的,而且在这些分区上非发生事务,那么可使复制功能正确工作。

o        对于访问相同MySQL簇的多MySQL服务器,不支持数据库的自动发现(autodiscovery)功能。但是,在情况下,支持对表的自动发现(autodiscovery)功能。这意味着,创建了名为db_name的数据库后,或使用1MySQL服务器导入了该数据库后,应在访问相同MySQL簇的每个额外MySQL服务器上发出CREATE DATABASE db_name语句(从MySQL 5.0.2开始,你还能使用CREATE SCHEMA db_name;)。一旦对给定MySQL服务器完成了该操作,服务器应能检测到数据库表,而不产生错误。

·         仅与MySQL簇有关的事宜(与MyISAMInnoDB无关):

o        簇中使用的所有机器必须具有相同的体系结构,也就是说,所有承载节点的机器必须是big-endianlittle-endian,不能混合使用这两者。例如,不能用运行在PPC上的管理节点指挥运行在x86机器上的数据节点。该限制不适用于简单运行mysql或其他客户端(可能会访问簇的SQL节点)的机器。

o        不能像使用ALTER TABLECREATE INDEX完成的那样执行在线方案更改,这是因为NDB簇不支持这类变更的自动检测(但是,能够导入或创建使用不同存储引擎的表,然后使用“ALTER TABLE tbl_name ENGINE=NDBCLUSTER;”将其转换为NDB。在这类情况下,需要发出FLUSH TABLES命令,强制簇发现变化)。

o        不能在线增加或舍弃节点(此时必须重启簇)。

o        使用多个管理服务器时:

§         必须在连接字符串中明确为节点指定ID,这是因为,在多个管理服务器上,自动分配的节点ID不能正常工作。

§         必须十分小心,确保所有的管理服务器具有相同的配置。簇对此方面不进行任何特殊检查,

§         要想使管理节点能发现彼此的存在,创建了簇后必须重启所有的数据节点(详细解释请参见Bug #13070)。

o        不支持用于数据节点的多个网络接口。如果使用了这类接口,很容易导致问题,原因在于,在出现某一数据节点失败的情况下,SQL节点将等待以确认该数据节点是否出现问题,但由于该数据节点的另一路径仍保持打开状态,SQL节点永远不会收到该确认信息。这会导致簇无法工作。

o        数据节点的最大数目为48

o        MySQL簇中总的最大节点数为63。在该数值中包括所有的MySQL服务器(SQL节点),数据节点和管理服务器。

考虑到本节开始时设定的条件,我们力图使上面列出的信息尽可能完全。你可以将任何遇到的差异通报到MySQL缺陷数据库,http://bugs.mysql.com/。如果我们不打算在MySQL 5.1中更正该问题,我们会将其添加到列表中。