Ndb Limitation 5122rc

Known Limitations of MySQL Cluster 摘自《MySQL 5.1.22-rc Reference Manual》 Non-Compliance In SQL Syntax： ¾ ¾

¾ ¾

¾

不支持临时表（does not support the create option 'TEMPORARY'） Ndb 的 index 和 key „ 不能在 BLOB 和 TEXT 列上创建 index „ Ndb 不支持 fulltext 索引： 但能够在 varchar 列上创建 index „ BIT 字段不能是主键、唯一键或索引，也不能是它们的一部分 „ ndb 引 擎 支 持 auto_increment 字 段 ： 如 果 没 有 显 式 主 键 ， ndb 自 动 创 建 auto_increment 字段并隐式为主键 ndb 引擎支持 geometry 数据类型（WKT 和 WKB），但不支持 spatial index ndb 引擎仅支持[LINEAR] KEY 类型分区：支持 ALTER TABLE...ADD PARTITION, REORGANIZE PARTITION, and COALESCE PARTITION ， 不 支 持 ALTER TABLE...DROP PARTITION 在 ndb 中使用行级复制，binlog 不能禁用。ndb 引擎忽略 SQL_LOG_BIN 的值

Limits and Differences from Standard MySQL Limits： ¾

¾

¾

当删除 ndb 表时，它所消耗的内存不能被自动回收，像其它引擎一样：delete 操作之 后的内存可以为同一张 ndb 表再次 insert 数据时使用而不能为其它 ndb 表使用（在执 行 rolling restart 之后，这种内存为其它表所用）；drop 和 truncate 操作之后的内存可 以为任何 ndb 表使用 cluster 配置引起的限制：在 cluster 设置限制方面，有很多可配置的硬限制存在，但 是多存在于主内存中。大多数配置参数可以在线 upgraded。这些限制包括： „ database memory size 和 index memory size：datamemory 以 32KB 页分配。当一 个 datamemory 页被使用时，它被分配到一个表；一旦被分配，只有当 drop 这个 表后，这块内存页才能被释放； „ 一个 tx 所能执行的最大 operation 数量由 MaxNoOfConcurrentOperations 和 MaxNoOfLocalOperations 设置：bulk loading/truncate table/alter table 动作被当作 多个 tx 处理，它们不受制于这个限制 „ table 和 index 有不同的限制：例如，每张表的最大 ordered indexes 数量由 MaxNoOfOrderedIndexes 决定 node 和 data object 的最大数量。下面的限制应用于 cluster nodes 和 metadata objects 的数量： „ data node 的最大数量是 48：一个 data node ID 不能大于 49 „ MySQL Cluster 里面所有 nodes 最大数量是 63（见本节最后 CGE 版本说明） ，包 括 sql nodes/API nodes/data nodes 和 mgmt nodes „ 在 MySQL Cluster 5.1/CGE5.1 里面，最大 metadata objects 的数量是 20320。这是 代码级限制。

Limits Relating to Transaction Handling ¾

Transaction isolation level：ndb 仅支持 read committed。 „ 注：如果在 ndb 表上的 select 语句包含 blob 或 text 字段，read committed 自动转换

¾ ¾

为 read with read lock。这是因为 blob 或 text 字段类型的值实际上从另外的表里面 读取的 Rollback：在 tx 中没有部分 rollback。Duplicate key 或者类似的错误将导致整个 tx 回 滚 Transactions and memory usage：正如这章节其它地方提到的，MySQL Cluster 不 能很好的处理大事务；最好是把含有大量操作的单个大事务变成含有一些操作的很多小 事务来处理。大事务需要非常多的内存资源。因为如此，很多 MySQL 语句的事务行为受 下列所述影响： „ Truncate 操作在 ndb 表上执行时是非事务的：如果 truncate 在清空表时失败，那 么需要重复执行多次直到其成功执行 „ Delete（即使没有 where 子句）是事务的：对于包含大量记录的表，你也许会发现 使用几次 delete from … limit …去执行删除操作性能会好一些。如果你的目的 是清空表，你应该使用 truncate 操作 „ Load data infile 操作在 ndb 表上执行时是非事务的 ‹ NOTE：当执行 load data infile 时候，ndb 引擎会不定期的执行提交来保证 更好利用通讯网络。不可能提前知道这样的提交在什么时候发生。Load data from master 在 MySQL Cluster 中不支持。 „ Alter table 和 tx：当拷贝一个 ndb 表的动作是 alter table 的一部分时，拷贝的 创建是非事务的。（任何情况下，当拷贝被删除时，这个操作会 rolled back。）

Error Handling 启动、停止或者重新启动一个节点可能会引发 temporary error，从而导致某些 tx 失败。这包 括下面几种情况： ¾ Temporary errors：当第一次启动一个节点时，可能你会看到 Error 1204 Temporary failure, distribution changed 或类似的 temporary errors ¾ Errors due to node failure：停止或任何 data node 失效能够导致很多不同的节点 失败错误。（然而，当执行一个计划中的 cluster 关闭时，这不会引起 tx 失败） 在这些情况下，任何产生的错误必须由应用程序处理。这通常通过重试 tx 完成。

Limits Associated with Database Objects 当使用 ndb 引擎时，一些数据库对象如表和索引会有不同的限制： ¾ Identifiers：ndb 引擎中的 database names/table names/attribute names 不能像其它存 储引擎一样长。Attribute names 将被截断至 31 个字符，并且如果被截断后的名字 不唯一的话将会报错。Database names 和 table names 总共最大长度为 122 个字符。 换句话说，一个 ndb 表名的最大长度是 122 个字符减去此表所属的 database 名字的 字符数 ¾ Number of tables：ndb 表的最大数量被限制为 20320 ¾ Attributes per table：每张表的 attributes（也就是 indexes 和 columns）的最大数 量被限制为 128 ¾ Attributes per key：每个 key 的 attributes 最大数量是 32 ¾

Row size：任何一行的最大允许尺寸是 8KB。Note that each BLOB or TEXT column contributes 256 + 8 = 264 bytes towards this total

Unsupported Or Missing Features

很多其它存储引擎支持的特性在 ndb 表中不被支持： ¾ Foreign key constraints：外键被忽略，就像在 MyISAM 表中一样 ¾ Optimize operations：optimize 操作不被支持 ¾ Load table … from master … ：这个操作不被支持 ¾ Savepoints and rollbacks：保存点和到保存点的回滚被忽略，就像在 MyISAM 表中一样 ¾ Durability of commits：在磁盘上没有持久的提交。提交是被复制的，但是不能 保证在提交的时候日志能够被刷新到磁盘上 ¾ Replication：不支持 statement 级别的复制。当配置 MySQL Cluster 复制时，需要 使用--binlog-format=row（or --binlog-format=mixed）

Limitations Relating to Performance 下面的性能问题是特殊的，尤其是在 MySQL Cluster 中特别声明的： ¾ Range scans：由于 ndb 引擎的顺序访问，会导致性能问题；与 MyISAM 或者 Innodb 相比，它做很多 range scans 的开销更大 ¾ Reliability of Records in range：Records in range 的统计是可用的，但不是经过 完全的测试或官方支持。这在某些情况下可能会导致非最佳的查询计划。如果必要 的话，你可以用 USE INDEX 或者 FORCE INDEX 来改变执行计划 ¾ Unique hash indexes：如果唯一性 hash indexes 是用 USING HASH 关键字创建， 同时 NULL 是 key 的一部分，那么在访问表的时候这个 hash indexes 不可用

Issues Exclusive to MySQL Cluster 下面的限制只针对 ndbcluster 存储引擎： ¾ Machine architecture：在 cluster 里面的所有机器必须是相同的架构。也就是说， 所有的节点主机都必须是 big-endian 或 little-endian，不能混合。举例来说，你不能 用一个运行在 PPC 机器上的管理节点来指挥一个运行在 x86 机器上的数据节点。 这个限制不应用于只是简单运行 mysql 或其它可能访问到 SQL nodes 的客户端上 ¾ Adding and dropping of data nodes：当前不支持在线添加或删除数据节点。这 种情况下，整个集群必须重启 ¾ Binary logging： 对于 binary logging，MySQL Cluster 有下面的局限性或限制： „ SQL_LOG_BIN 对于 data operations 没有影响；然而，它支持 schema operations „ MySQL Cluster 不产生包含 BLOB 字段但没有主键的表的 binlog „ 仅下面的 schema operations 被记入 cluster binlog， binlog 不在 mysqld 上执行 statement： ‹ CREATE TABLE ‹ ALTER TABLE ‹ DROP TABLE ‹ CREATE DATABASE / CREATE SCHEMA ‹ DROP DATABASE / DROP SCHEMA ‹ CREATE TABLESPACE ‹ ALTER TABLESPACE ‹ DROP TABLESPACE ‹ CREATE LOGFILE GROUP

‹ ‹

ALTER LOGFILE GROUP DROP LOGFILE GROUP

Limitations Relating to Disk Data Storage ¾

¾

磁盘数据对象有下面的最大限度： „ Tablespace 的最大数量是 2^32 „ 每个 tablespace 中的 data file 的最大数量是 2^16 „ Tablespace data file 的理论最大数量是 2^16；但是，从实际效果看，推荐最大数 量是 2^8 „ 最大 data file 的理论限制是 64GB；然而，在 MySQL 5.1 中，实际的上限是 32GB。 This is equivalent to 32768 extents of 1M each 当 cluster 运行在 diskless 模式时，disk data table 不被支持

Limitations Relating to Multiple Cluster Nodes ¾

¾

¾

¾

Multiple SQL nodes：下面的问题是有关多个 MySQL 服务器作为 MySQL Cluster SQL 节点的，并且特别针对 NDB 引擎 „ Alter table operations：当运行多个 MySQL 服务器时，alter table 不是全锁（不 是分布式表锁） „ DDL operations：DDL 操作（例如 create table/alter table）在 data node 失败的 时候是不安全的。如果一个 data node 在尝试执行这些操作中的一个时失败了， 那么数据字典被锁住，并且在没有重启 cluster 之前没有其它的 DDL 语句能够 执行 Multiple management nodes： „ 你必须显式的在 connectstrings 中给出 nodes IDs，因为 node ID 的自动分配功 能不能跨越多个 management server „ 你必须非常小心的让所有的 management servers 具有相同的配置。因为在 cluster 里面没有对这些配置的特殊检查 Multiple data node processes：在一个单主机上并行的运行多个 cluster 进程是 可能的，但是由于性能、高可用性以及其它一些，我们不推荐这么做。实际上，在 MySQL 5.1 和 MySQL Cluster 5.1 CGE 版本中，我们不支持在生产环境里面使用 MySQL Cluster 的时候，在一个单个物理机器上启动多个 ndbd 进程。 „ 注：我们也许会在将来的 MySQL 发布中支持一个主机多个 data nodes 的配置； 然而，在 MySQL 5.1/5.1 CGE 中，这样的配置只是实验性质的 Multiple network addresses：data node 上不支持多个网络地址。这种情况很容 易引发问题：在有 data node 失败的事件发生时，一个 SQL node 会等待 data node 宕机的确认，但是永远不会收到确认，这是因为通往 data node 的另一个路由仍然 是通畅的。这种情况会让 cluster 无法恢复 „ 注：在一个单个 data node 上可以使用多个网卡接口，但是它们必须绑定同一 个地址。这也意味着在 config.ini 中，每个 connection 只能有一个[TCP] section。

Previous MySQL Cluster Issues Resolved in MySQL 5.1 在早些的 MySQL Cluster 版本中存在的限制和相关问题已经在 MySQL 5.1 或 MySQL 5.1 CGE 的开发过程中被解决： ¾ Variable-length column support：NDB Cluster 存储引擎现在支持内存表中的变

¾

¾ ¾

¾

¾

¾ ¾ ¾

¾

¾

长字段类型。例如，在以前的版本中，任何具有一个或多个 Varchar 字段的集群表， 它可能仅仅包含很小的值，会比同样情况下使用 MyISAM 引擎的表和数据需要更 多的内存和磁盘空间。换句话说，一个 Varchar 类型的字段要求与一个 Char 类型 字段相同的存储空间。在 MySQL 5.1 的内存表里面，不再是这样情况了。变长字 段类型（例如 varchar 和 binary）需要的存储空间与它们在 MyISAM 表中的需求是 一样的。 ‹ 注：对于 MySQL Cluster 磁盘表，这种定宽的限制依然存在。 Replication with MySQL Cluster：现在能够在 MySQL Cluster 之间实现复制功能 „ Circular Replication：从 MySQL 5.1.18 开始，MySQL Cluster 支持 Circular Replication Auto_increment_increment and auto_increment_offset：从 MySQL 5.1.20 开 始，在集群复制中支持 auto_increment_increment 和 auto_increment_offset Database autodiscovery and online schema changes ： 多 个 访 问 同 一 个 MySQL Cluster 的 MySQL 服务器之间支持数据库的自动发现（provided that a given mysqld is already running and is connected to the cluster at the time that the database is created on a different mysqld.） „ 这个意思是指如果一个 mysqld 进程在一个名为 db_name 的数据库建立后先连 到集群上，当它第一次访问集群的时候，你应该在这个“新”的 MySQL 服务 器上执行一个 create schema db_name 的语句。一旦做完这个， “新”的 mysqld 就能无误的发现那个数据库中的任何表。 „ 这也意味这在 NDB 表中 schema 的在线变更是可能的。就是说，在 cluster 里 面的一个 SQL 节点上执行诸如 alter table 和 create index 等操作的结果不用任 何附加的动作就能在其它 SQL 节点上看到。 Backup and restore between architectures：从 MySQL 5.1.10 开始，能够在不 同架构上执行集群的备份和恢复。例如，在以前的版本中，你不能在一个 big-endian 平台上做备份，然后从这个备份恢复到一个 little-endian 平台上 Character set directory：从 MySQL 5.1.10 开始，MySQL Cluster 的安装支持字 符描述文件的非默认位置，能够使用--basedir 或--character-sets-dir 选项来改变搜索 路径 在 MySQL 5.1 里面，当运行多个管理节点时，没有再必要去重启所有的数据结点 来让管理结点之间看到对方 Length of create table statements：create table 语句的长度不能多于 4096 个字 符。这个限制仅影响 MySQL 5.1.6/5.1.7/5.1.8。（bug#17813） Ignore and replace functionality：在 MySQL 5.1.7 及以前的版本里，只对主键 支持 insert ignore/update ignore 和 replace，而不能对 unique key 支持。通过删除约 束（constraint），然后 drop 唯一索引，执行任何插入，然后再加入唯一索引的方法 能够绕过此问题。 „ 在 MySQL 5.1.8 中，insert ignore 和 replace 的这个限制已经去掉了。 Auto_increment columns ： 在 MySQL 5.1.10 及 以 前 的 版 本 里 ， 具 有 auto_increment 属性字段（包括隐藏主键）的表的最大数量是 2048 个。 „ 这个限制在 MySQL 5.1.11 中去掉了。 Maximum number of custer nodes：下面的信息适用于 MySQL Cluster 5.1 CGE 版本 在 MySQL 5.1.15-ndb-6.1.1 之前，在一个 MySQL Cluster 中的最大节点总数是 63，

包括所有的 SQL 节点、API 节点、数据节点和管理节点。 „ 从 MySQL 5.1.15-ndb-6.1.1 开始，在一个 MySQL Cluster 系统中支持 255 个 API 节点（包括 SQL 节点）。数据节点和管理节点的总数是 63 个，其中数据结点 最大为 48 个。 „ 在 MySQL Cluster 5.1 CGE 版本中，数据节点的 node ID 仍然不能大于 49。