MySQL集群手册

1. 集群与普通MySQL服务器区别

        与没有使用集群的MySQL相比，在MySQL集群内操作数据的方式没有太大的区别。执行这类操作时应记住两点：

        1．表必须用ENGINE=NDB或ENGINE=NDBCLUSTER选项创建，或用ALTER TABLE选项更改，以使用NDB集群存储引擎在集群内复制它们。如果使用mysqldump的输出从已有数据库导入表，可在文本编辑器中打开SQL脚本，并将该选项添加到任何表创建语句，或用这类选项之一替换任何已有的ENGINE（或TYPE）选项。

        2．每个NDB表必须有一个主键。如果在创建表时用户未定义主键，NDB集群存储引擎将自动生成隐含的主键。

2. 直接连接的MySQL集群TCP/IP连接

        使用数据节点之间的直接连接建立集群时，需要在集群config.ini文件的[TCP]部分中明确指定如此连接的数据节点的交叉IP地址。

        在下面的示例中，假定集群具有至少4台主机，1台用于管理服务器，一台用于SQL节点，两台用于数据节点。作为整体，集群位于LAN的172.23.72.*子网内。除了通常的网络连接外，两个数据节点使用标准的交叉电缆直接相连，并使用范围在1.1.0.*的IP地址彼此间直接通信，如下所示：

# Management Server [NDB_MGMD] Id=1 HostName=172.23.72.20   # SQL Node [MYSQLD] Id=2 HostName=172.23.72.21   # Data Nodes [NDBD] Id=3 HostName=172.23.72.22   [NDBD] Id=4 HostName=172.23.72.23   # TCP/IP Connections [TCP] NodeId1=3 NodeId2=4 HostName1=1.1.0.1 HostName2=1.1.0.2

        使用数据节点间的直接连接能够改善集群的整体效率，使用该方式，数据节点能绕过以太网设备，如交换器、Hub、路由器等，从而减少了集群的等待时间。注意，对于两个以上的数据节点，要想充分利用这类直接连接的优点，需要为各数据节点建立与相同节点组内的其他数据节点间的直接连接。

3. MySQL集群中的进程管理

3.1. ndbd，存储引擎节点进程

         ndbd是使用NDB集群存储引擎处理表中所有数据的进程。通过该进程，存储节点能够实现分布式事务处理，节点恢复，对磁盘的检查点操作，在线备份，以及相关的任务。

        在MySQL集群中，一组ndbd进程能够共同处理数据。这些进程可以在相同的计算机（主机）上执行，也能在不同的计算机上执行。数据节点和集群主机之间的通信是完全可配置的。

        Ndbd将生成一组日志文件，这些文件位于由配置文件中DataDir指定的目录下。下面列出了这些日志文件。注意，node_id代表节点的唯一ID。例如，ndb_2_error.log是由节点ID为2的存储节点生成的错误日志。

        ndb_node_id_error.log是包含所引用ndbd进程所遇到的所有崩溃记录的文件。该文件中的每条记录均包含1个简要的错误字符串，以及对该崩溃跟踪文件的引用。该文件的典型条目与下面给出的类似：

·                Date/Time: Saturday 30 July 2004 - 00:20:01

·                Type of error: error

·                Message: Internal program error (failed ndbrequire)

·                Fault ID: 2341

·                Problem data: DbtupFixAlloc.cpp

·                Object of reference: DBTUP (Line: 173)

·                ProgramName: NDB Kernel

·                ProcessID: 14909

·                TraceFile: ndb_2_trace.log.2

·                ***EOM***

        注释：请记住，错误日志文件中的最后1个条目并不必然是最新的（也不太可能），这点很重要。错误日志中的条目不是按时间顺序排列的，而是与ndb_node_id_trace.log.next（请参见下面的介绍）中定义的跟踪文件的顺序对应。因此，错误日志条目是按循环方式而不是顺序方式覆盖的。

        ndb_node_id_trace.log.trace_id是准确描述了错误出现之时所发生情况的跟踪文件。该信息在MySQL集群开发团队进行分析时很有帮助。

能够对覆盖旧文件之前创建的跟踪文件的数目进行配置。trace_id是为每个连续的跟踪文件增加的编号。

        ndb_node_id_trace.log.next是记录了要指定的下一个跟踪文件编号的文件。

        ndb_node_id_out.log是包含ndbd进程的任何数据输出的文件。仅当将ndbd启动为端口监督程序时才会创建该文件。

        ndb_node_id.pid是包含启动时作为端口监督程序的ndbd进程的进程ID的文件。它还能起到锁定文件的作用，以防止启动具有相同ID的节点。

        ndb_node_id_signal.log是仅在ndbd调试版下使用的文件，它能跟踪ndbd进程中所有的入站、出站和内部消息。以及它们的数据。

        建议不要使用通过NFS安装的目录，这是因为在某些情况下，如果pid-file上的锁定依旧有效，即使当进程中止后也会产生问题。

        启动ndbd时，或许需要指定管理服务器的主机名以及监听的端口号。作为可选方式，也可以指定进程将使用的节点ID。

shell>ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"

        启动ndbd时，它实际上将启动两种进程。第1种进程称为“angel process”（天使进程），它的唯一任务是发现执行进程在何时完成，然后重启ndbd进程（如果作了该配置的话）。因此，如果你打算使用Unix的kill命令杀死ndbd进程，就需要杀死这两个进程。中止ndbd进程的更恰当方法是使用管理客户端，并通过该管理客户端停止进程。

        执行进程采用了1个线程，用于读取、写入和扫描数据，以及所有其他任务。该线程是异步实施的，以便能方便地处理数以千计的并发活动。此外，看门狗线程负责监督执行线程，以确保执行线程不会陷入无限循环。线程池负责处理文件I/O，每个线程均能处理一个打开的文件。这些线程也能被ndbd进程中的传输器用作传输器连接。在执行包含更新在内的大量操作的系统中，如果允许，ndbd进程能占用2个CPU。对于拥有多CPU的机器，建议使用属于不同节点组的数个ndbd进程。

3.2. ndb_mgmd，“管理服务器”进程

        ndb_node_id_cluster.log是集群事件日志文件。这类事件的例子包括：检查点操作的启动和完成，节点启动事件，节点故障，以及内存使用水平。

当集群日志的大小达到1MB时，文件将被重命名为ndb_node_id_cluster.log.seq_id，其中seq_id是集群日志文件的序列号（例如，如果编号1、2、3已存在，下一个日志文件将用4命名）。

        ndb_node_id_out.log是将管理服务器用作端口监督程序时用于stdout和stderr的文件。

        ndb_node_id.pid是将管理服务器用作端口监督程序时所使用的PID文件。

4. 命令选项

4.1. ndbd命令选项

        -d, --daemon：通知ndbd作为daemon（端口监督程序）进程执行（默认行为）。

        --nodaemon：指明ndbd不得作为daemon（端口监督程序）进程启动。调试ndbd以及希望将输出重定向到屏幕时，它很有用。

        --initial：通知ndbd执行初始化启动。初始化启动将删除以前ndbd实例为恢复目的创建的任何文件。它还能重新创建恢复用日志文件。注意，在某些操作系统上，该进程可能会占用较长的时间。

        仅在首次启动ndbd进程时才应使用—initial启动，这是因为它将删除集群文件系统的所有文件，并再次创建所有的REDO日志文件。该规则的例外如下：

        l 执行那些会更改文件内容的软件升级时。

        l 用新的ndbd版本重启节点时。

        l 出于某种原因，节点重启或系统重启不断失败时的最后手段。在这类情形下，请注意，由于数据文件的损坏，不能使用该节点来恢复数据。

4.2. ndb_mgmd的命令选项

        -d, --daemon：指示ndb_mgmd作为端口监督程序启动。这是默认行为。

         --nodaemon：指示管理服务器不作为端口监督程序启动。

5. MySQL集群的管理

5.1. “管理客户端”中的命令

        除了中央配置文件外，还能通过管理客户端ndb_mgm提供的命令行界面对集群进行控制。这是运行集群的主要管理界面。

        管理客户端提供了下述基本命令。在下面给出的清单中，node_id指的是数据库节点ID或关键字ALL，指明命令将应用到所有的集群数据节点上。

        HELP：显示关于所有可能命令的信息。

        SHOW：显示关于集群状态的信息。

        注释：在使用多个管理节点的集群中，该命令仅显示与当前管理服务器实际相连的数据节点的信息。

        node_id START：启动由node_id标识的数据节点（或所有数据节点）。

        node_id STOP：停止由node_id标识的数据节点（或所有数据节点）。

        node_id RESTART [-N] [-I]：重启由node_id标识的数据节点（或所有数据节点）。

        node_id STATUS：显示由node_id标识的数据节点（或所有数据节点）的状态信息。

        ENTER SINGLE USER MODE node_id：进入单用户模式，仅允许由节点ID“node_id”标识的MySQL服务器访问数据库。

        EXIT SINGLE USER MODE：退出单用户模式，允许所有的SQL节点（即所有运行的mysqld进程）访问数据库。

        QUIT：中止管理客户端。

        SHUTDOWN：关闭除SQL节点之外的所有集群节点，并退出。

5.2. 登记管理命令

        下述管理命令与集群日志有关：

        CLUSTERLOG ON：打开集群日志。

        CLUSTERLOG OFF：关闭集群日志。

        CLUSTERLOG INFO：关于集群日志设置的信息。

        node_id CLUSTERLOG category=threshold：用小于或等于threshold的优先级将category事件记录到集群日志。

        CLUSTERLOG FILTER severity_level：将集群事件日志切换为指定的severity_level。

        在下表中，介绍了集群日志类别阈值的默认设置（对于所有数据节点）。如果事件的优先级值低于或等于优先级阈值，就会在集群日志中记录。

        注意，事件是按数据节点通报的，可在不同的节点上设置不同的阈值。

类别	默认阈值（所有数据节点）
STARTUP	7
SHUTDOWN	7
STATISTICS	7
CHECKPOINT	7
NODERESTART	7
CONNECTION	7
ERROR	15
INFO	7

        阈值用于过滤每种类别中的事件。例如，对于优先级为3的STARTUP事件，不会将其记录到日志中，除非将STARTUP的阈值更改为3或更小。如果阈值为3，仅发送优先级等于或小于3的事件。

        下面给出了事件的严重级别（注释：它们与Unix的syslog级别对应；但LOG_EMERG和LOG_NOTICE除外，未使用或未映射它们）：

1	ALERT	应立刻更正的状况，如损坏的系统数据库。
2	CRITICAL	临界状况，如设备错误或资源不足。
3	ERROR	应予以更正的状况，如配置错误等。
4	WARNING	不能称其为错误的状况，但仍需要特别处理。
5	INFO	通报性消息。
6	DEBUG	调试消息，用于NDB集群开发。

        可以打开或关闭事件严重级别。如果打开了事件严重级别，那么优先级等于或低于类别阈值的事件均将被记录。如果关闭了事件严重级别，那么将不记录属于该严重级别的任何事件。

6. MySQL集群中生成的事件报告

        MySQL集群提供了两种事件日志。它们是cluster log和node logs，cluster log（集群日志）包括由所有集群节点生成的事件，node logs（节点日志）仅记录每个数据节点的本地事件。

        由集群事件日志功能生成的输出可以有多个目的地，包括文件、管理服务器控制台窗口、或syslog。由节点事件日志功能生成的输出将被写入数据节点的控制台窗口。

        注释：集群日志是为大多数使用场合推荐的日志，这是因为它在1个文件中提供了关于整个集群的日志信息。节点日志仅应在应用程序的开发过程中使用，或用于调试应用程序代码。

        Category（类别）：可以是下述值之一：STARTUP, SHUTDOWN, STATISTICS, CHECKPOINT,NODERESTART, CONNECTION, ERROR,或INFO。

        Priority（优先级）：由从1到15的数字表示，“1”表示“最重要”，“15”表示“最不重要”。

        Severity Level（严重级别）：可以是下述值之一：ALERT, CRITICAL, ERROR, WARNING, INFO,或DEBUG。

7. 单用户模式

        采用单用户模式，数据库管理员能够将对数据库系统的访问限制在1个MySQL服务器（SQL节点）。进入单用户模式时，与所有其他MySQL服务器的所有连接均将恰当关闭，而且所有正在运行的事务均将被放弃。不允许启动任何新事务。

         一旦集群进入单用户模式，只有指定的SQL节点才有权访问数据库。使用ALL STATUS命令，可查看集群进入单用户模式的时间。

示例：

NDB> ENTER SINGLE USER MODE 5

        执行该命令而且集群进入单用户模式后，节点ID为5的SQL节点将成为集群中唯一允许的用户。

        上述命令中指定的节点必须是MySQL服务器节点，如果指定任何其他类型的节点，将被拒绝。

        注释：执行上述命令时，指定节点上所有正在运行的事务均将被放弃，连接关闭，而且必须重启服务器。

        使用EXIT SINGLE USER MODE命令，能够将集群数据节点的状态从单用户模式更改为正常模式。对于等待连接的MySQL服务器（即，对于即将准备就绪并可用的集群），现在允许进行连接。在状态变化期间和变化之后，指定为单用户SQL节点的MySQL服务器将继续运行（如果仍连接的话）。

示例：

        NDB> EXIT SINGLE USER MODE

        运行在单用户模式下时，如果节点失败，推荐的处理方法是：

        1.    结束所有的单用户模式事务。

        2.    发出EXIT SINGLE USER MODE命令。

        3.    重启集群的数据节点。

        或进入单用户模式之前重启数据库。

8. 集群备份概念

        备份指的是在给定时间对数据库的快照。备份包含三个主要部分：

        Metadata（元数据）：所有数据库表的名称和定义。

        Table records（表记录）：执行备份时实际保存在数据库表中的数据。

        Transaction log（事务日志）：指明如何以及何时将数据保存在数据库中的连续记录。

        每一部分均会保存在参与备份的所有节点上。在备份过程中 ，每个节点均会将这三个部分保存在磁盘上的三个文件中：

        BACKUP-backup_id.node_id.ctl：包含控制信息和元数据的控制文件。每个节点均会将相同的表定义（对于集群中的所有表）保存在自己的该文件中。

        BACKUP-backup_id-0.node_id.data：包含表记录的数据文件，它是按片段保存的，也就是说，在备份过程中，不同的节点会保存不同的片段。每个节点保存的文件以指明了记录所属表的标题开始。在记录清单后面有一个包含关于所有记录校验和的脚注。

        BACKUP-backup_id.node_id.log：包含已提交事务的记录的日志文件。在日志中，仅保存已在备份中保存的表上的事务。参与备份的节点将保存不同的记录，这是因为，不同的节点容纳了不同的数据库片段。

        在上面所列的内容中，backup_id指的是备份ID，node_id是创建文件的节点的唯一ID。

9. 使用管理服务器创建备份

        使用管理服务器创建备份包含以下步骤：

        1.    启动管理服务器(ndb_mgm)。

        2.    执行命令START BACKUP。

        3.    管理服务器将用消息“指示备份开始”作出应答。这意味着管理服务器将请求提交给了集群，但尚未收到任何回应。

        4.    管理服务器回复“备份backup_id开始”，其中，backup_id是该备份的唯一ID（如果未作其他配置，该ID还将保存在集群日志中）。这意味着集群已收到并开始处理备份请求。它不表示备份已完成。

        5.    管理服务器发出消息“备份backup_id完成”，通知备份操作已结束。

        要想放弃正在处理的备份：

        1.    启动管理服务器。

        2.    执行命令ABORT BACKUP backup_id。backup_id是当备份开始时包含在管理服务器应大中的备份ID（在消息“备份backup_id启动”中）。

        3.    管理服务器用消息“放弃指示的备份backup_id”确认放弃请求，注意，尚未收到对该请求的实际回应。

        4.    一旦放弃了备份，管理服务器将通报“备份backup_id因XYZ而放弃”。这意味着集群中止了备份，并从集群文件系统中删除了与该备份有关的所有文件。

        在系统shell中使用下述命令，也能放弃正在执行的备份：

        shell> ndb_mgm -e "ABORT BACKUP backup_id"

        注释：执行放弃操作时，如果没有ID为backup_id的备份，管理服务器不会给出任何明确回应。但是，所发出的无效放弃命令将在集群日志中给出。

10. 如何恢复集群备份

        集群恢复程序是作为单独的命令行实用工具ndb_restore实现的，它将读取由备份创建的文件，并将保存的信息插入数据库。必须为每组备份文件执行恢复程序，也就是说，执行次数与创建备份时运行的数据库节点数相同。

        首次执行恢复程序时，还需要恢复元数据。换句话讲，必须重新创建数据库表（注意，开始执行恢复操作时，集群中应有一个空数据库）。恢复程序对于集群来说相当于API，因此，需要一个空闲连接，以便与集群相连。可使用ndb_mgm命令SHOW（在系统shell下使用ndb_mgm -e SHOW即可完成该操作）进行验证。可以使用开关“-cconnectstring”来确定MGM节点的位置。备份文件必须位于恢复程序参量给定的目录下。

        能够使用与创建是所用配置不同的配置将备份恢复到数据库。例如，对于备份ID为12的备份，该备份是在具有两个数据库节点（节点ID无恶2和3）的集群中创建的，可以将其恢复到具有4个节点的集群中。这样，ndb_restore必须运行两次，为创建备份时的每个数据库节点运行一次。

        注释：对于快速恢复，能够以并行方式恢复数据，但必须有足够的可用集群连接。然而，数据文件必须始终前于日志文件。

11. 集群备份的配置

        有4个用于备份的基本配置参数：

        BackupDataBufferSize：将数据写入磁盘之前用于对数据进行缓冲处理的内存量。

        BackupLogBufferSize：将日志记录写入磁盘之前用于对其进行缓冲处理的内存量。

        BackupMemory：在数据库节点中为备份分配的总内存。它应是分配给备份数据缓冲的内存和分配给备份日志缓冲的内存之和。

        BackupWriteSize：写入磁盘的块大小。它适用于备份数据缓冲和备份日志缓冲

12. 备份故障诊断与排除

        如果在发出备份请求时返回了错误代码，最可能的原因是内存不足，或磁盘空间不足。应检查是否为备份分配了足够的内存。此外，还应检查在备份目标的硬盘分区上是否有足够的空间。

         限制或行为中的不兼容性（运行已有的应用程序时可能导致错误）：

        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中那样。

        仅与MySQL集群有关的事宜（与MyISAM或InnoDB无关）：

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

        o        不能在线增加或舍弃节点（此时必须重启集群）。

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

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

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

        §         要想使管理节点能发现彼此的存在，创建了集群后必须重启所有的数据节点

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

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

        o        MySQL集群中总的最大节点数为63。在该数值中包括所有的MySQL服务器（SQL节点），数据节点和管理服务器。

13. MySQL集群常见问题解答

13.1. 使用集群与使用复制的区别是什么？

        在复制设置中，主MySQL服务器负责更新1个或多个从服务器。事务按顺序提交，较慢的事务会导致从服务器滞后于主服务器。这意味着，如果主服务器失败，从服务器可能无法记录最近的少数事务。如果使用了事务安全引擎，如InnoDB，要末是在从服务器上完成事务，要末是根本就不记录事务，但复制不保证主服务器和从服务器上的所有数据在任何时候都是一致的。在MySQL集群中，所有的数据节点保持同步，任何一个数据节点提交的事务将被提交给所有的数据节点。当某一数据节点失败时，所有剩余的数据节点仍能保持一致的状态。

        简而言之，尽管标准的MySQL复制是异步的，但MySQL集群是同步的。

        我们计划在MySQL 5.1中为集群实现（异步）复制功能。包括在两个集群之间，以及MySQL集群和非集群类MySQL服务器之间的复制能力。

13.2. 为了运行集群，我是否需要进行特殊的组网呢？（集群中的计算机是如何通信的？）

        MySQL集群是为高带宽环境下的使用而设计的，计算机通过TCP/IP相连。其性能直接取决于集群计算机之间的连接速度。对于集群，最低连接要求包括：典型的100MB以太网网络或等效网络。如果可能，建议使用GB以太网。

        也支持更快的SCI 协议，但需要特殊硬件。关于SCI的更多信息，

13.3. 运行集群需要多少台计算机？为什么？

        要想运行可行的集群，最少需要3台计算机。但在MySQL集群中，推荐的最低计算机数目为4：1台负责运行管理节点，1台负责运行SQL节点，2台用作存储节点。使用2个数据节点的目的是为了提供冗余性，管理节点必须运行在单独的机器上，这样，当1个数据节点失败时，仍能保证连续的仲裁服务。

13.4. 运行MySQL集群的硬件要求是什么？

        在集群运行的任何平台上，应具有具备NDB功能的二进制文件。显而易见，更快的CPU和更多的内存能够改善性能，64位CPU的效率很可能高于32位处理器。在用于数据节点的机器上必须有足够的内存，以便容纳各节点共享的数据库部分。（更多信息，请参见我需要多少内存？）。节点能通过标准的TCP/IP网络和硬件进行通信。对于SCI支持，需要特殊的组网硬件。

13.5. 由于MySQL集群使用了TCP/IP，这是否意味着我能在Internet上运行1个或多个节点位于远程位置的集群？

        在MySQL集群中，节点间的通信并不安全，这点极其重要，这类通信未加密，也未采用任何防护机制。对于集群，最安全的配置是位于防火墙后的专用网络，不能从外部直接访问任何集群数据或管理节点（对于SQL节点，应采取相同的防护措施，就像在MySQL服务器的其他实例中那样）。

        无论是任何情况，在这类条件下集群的可靠运行十分令人怀疑，这是因为设计和实施MySQL集群时，假定它运行在能保证专用高速连通性的条件下，如使用100MB或GB以太网的LAN中（更倾向于后者）。对于低于该要求的任何环境，我们未作任何测试，也不保证其性能。

13.6. 使用集群时，如何了解错误或警告消息的含义呢？

        有两种完成它的方式：

        1．出现错误或告警状况时，在MySQL监视器内，立刻使用SHOW ERRORS或SHOW WARNINGS。也能在MySQL Query Browser（查询浏览器）中显示它们。

        2．在系统shell提示符下，使用perror --ndb error_code。

13.7. MySQL集群是事务安全的吗？支持什么隔离级别？

        是。对于用NDB存储引擎创建的表，支持事务。在MySQL 5.1中，集群仅支持READ_COMMITTED事务隔离级别。

13.8. 集群支持的表类型是什么？

        NDB是仅有的支持集群功能的MySQL存储引擎。（能够使用其他存储引擎在用于集群的MySQL服务器上创建表，如MyISAM或InnoDB，但这类非NDB表不在集群中）。

13.9. 哪些版本的MySQL软件支持集群？我必须从源码编译吗？

        在5.1系列的所有MySQL-max二进制版本中均支持集群，但下面介绍的除外。使用命令SHOW VARIABLES LIKE 'have_%';或SHOW ENGINES;，可检查你的服务器是否支持NDB

13.10. 我需要多少RAM？是否能全部使用磁盘内存？

        在目前，集群是仅“内存中”的。这意味着所有的表数据（包括索引）均保存在RAM中。因此，如果你的数据占用了1GB的空间，而且打算在集群中将它复制1次，需要2GB的内存。还应加上操作系统以及在集群计算机上运行的应用程序所需的内存。

        可以使用下述公司粗略估计集群中每个数据节点所需的RAM量：

        (SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes

        要想更准确地计算内存需求量，需要为集群数据库中的每个表确定每行所需的存储空间（详情请参见11.5节，“列类型存储需求”），然后乘以占行数。还必须对列索引进行计算，方式如下：

        o对于为NDB集群表创建的每个主键索引或哈希索引，每记录需要21-25字节。这类索引使用IndexMemory（索引内存）。

        o每个有序索引每记录需要10字节的存储空间，使用DataMemory（数据内存）。

        o创建主键或唯一索引时，还会创建1个有序索引，除非该索引是使用USING HASH创建的。换句话讲，如果未使用USING HASH创建它们，对于集群表上的每个键多因或唯一索引，在MySQL 5.1中，每记录占用31-35字节。

        注意，使用USING HASH为所有主键和唯一索引创建MySQL集群表时，通常还能使表的更新速度更快。这是因为，它需要较少的内存（因未创建有序索引），对CPU的占用也较低（仅需读取或更新较少的索引）。

        所有的MySQL集群表必须有主键，这点极其重要。如果未定义，NDB存储引擎将自动创建主键，而且该主键是在未使用USING HASH的条件下创建的。

很难准确确定集群索引在任何给定时间用于存储的内存量，但是，当可用DataMemory和/或IndexMemory的使用率到达80％时，会将警告消息写入集群日志，到达80％、90％等时，也会写入集群日志。

        我们经常遇到用户通报的下述问题，当他们视图填充集群数据库时，加载进程提前终止，并显示下述错误消息：

        错误1114：表'my_cluster_table'已满。

        出现该情况时，很可能是因为在你的设置中未为所有的表数据和索引提供足够的RAM，包括NDB存储引擎所需的主键，以及表定义中不包含主键定义时自动创建的主键。

        此外还应注意，所有的数据节点应具有相同的RAM量，这是因为，集群中任何数据节点所能使用的内存均不超过任意单独数据节点的最低可用内存。换句话讲，如果有三台运行集群数据节点的计算机，在其中两台计算机上，有3GB用于保存集群数据的RAM，另一台计算机只有1GB RAM，那么每个数据节点仅能为集群贡献1GB。

13.11. 出现灾难性故障时，例如整个城市断电而且我的UPS也出现故障，我会丢失所有的数据吗？

        所有已提交的事务将被记录。因此，在出现灾难的情况下，某些数据可能会丢失，但相当有限。通过减少每事务的操作数，能够进一步减少数据损失（在任何情形下，在每事务上执行大量操作都不是一个好主意）。

13.12. 我能在一台计算机上运行多个节点吗？

        可以，但不建议这样。运行集群的主要原因之一是提供冗余，为了获得冗余性的全部优点，每个节点应位于单独的计算机上。如果将多个节点置于同一台机器，当该机器出现故障时，所有节点均将丢失。考虑到MySQL集群能运行在常见的硬件上并利用廉价的操作系统（或不需费用），为了确保任务关键型数据的安全，值得为额外的机器户花费开销。此外还须注意，对运行管理节点的集群主机的要求最低，使用200 MHz Pentium CPU，操作系统所需的足够RAM，以及用于ndb_mgmd和ndb_mgm进程的少量开销，就能完成该任务。

13.13. 我能在不重启的情况下为集群增加节点吗？

        目前不行。对于在集群中添加新的MGM或SQL节点来说，简单的重启就是所需的一切。添加数据节点时，进程略微复杂些，需要采取下述步骤：

        o对所有集群数据进行完整备份。

        o彻底关闭集群和所有的集群节点进程。

        o使用“—initial”启动选项重启集群。

   o从备份中恢复所有集群数据。

        在未来的MySQL集群版本中，我们希望为MySQL集群实现“热”重配置功能，以便能够将添加新节点时重启集群的要求降至最低（如果不能消除的话）。

13.14. 使用集群时有需要我了解的限制吗？

        MySQL中的NDB表服从下述限制：

        o并非所有的字符集和校对均被支持。

        o不支持FULLTEXT索引和前缀索引。只能为完整的列设置索引。不支持第19章：MySQL中的空间扩展中介绍的空间扩展。

        o仅支持对事务的完整回滚。不支持部分回滚以及回滚至保存点。

        o每表允许的最大属性数为128，而且属性名称不得超过31个字符。对于每个表，表和数据库名称的最大组合长度为122个字符。

        o表行的最大大小为8KB，不包括BLOB。对于每表中的行数没有限制，表的大小限制取决于多种因素，尤其是每个数据节点可用的RAM量。

        oNDB引擎不支持外键约束。就像MyISAM表一样，这些约束将被忽略。

        o不支持查询高速缓冲功能。

13.15. MySQL集群支持的列类型是什么？

        MySQL集群支持所有通常的MySQL列类型，但与MySQL空间扩展有关的例外（请参见第19章：MySQL中的空间扩展）。此外，对于索引，当与NDB表一起使用时存在一些差别。注释：MySQL集群表（即用ENGINE=NDBCLUSTER创建的表）仅有固定宽度列。这意味着（例如）含有VARCHAR(255)列的每一条记录需要256字节来保存列，无论列中保存的数据大小是多少。在未来的MySQL版本中，计划更正它。

13.16. 当集群关闭时，会对集群数据有什么影响？

        由集群数据节点保存在内存中的数据将被写入磁盘，并在下一次启动集群时重新装入内存。

        要想关闭集群，请在MGM节点所在的机器上、在shell下输入下述命令：

        shell> ndb_mgm -e shutdown

        这样就能恰当地中止ndb_mgm、ndb_mgm、以及任何ndbd进程。对于用作集群SQL节点的MySQL服务器，可使用mysqladmin shutdown停止它。

13.17. 在集群中能混合使用不同的硬件和操作系统吗？

        是。只要所有的机器和操作系统均是相同的endian。也能在不同的节点上使用不同的MySQL集群版本，但是，我们建议仅应将其作为滚动升级的一部分使用。

13.18. 我能在单台主机上运行两个数据节点吗？两个SQL节点？

        是，能够这样。在有多个数据节点的情况下，每个节点必须使用不同的数据目录。如果打算在一台机器上运行多个SQL节点，那么每个mysqld实例必须使用不同的TCP/IP端口。

 

转自：

http://dev.mysql.com/doc/refman/5.1/zh/ndbcluster.html