分类： Mysql/postgreSQL
2008-05-11 22:30:26
管理MySQL簇涉及众多任务，首先是配置和启动MySQL簇。详情请参见17.4节，“MySQL簇的配置”和17.5节，“MySQL簇中的进程管理”。
下面介绍了MySQL簇的管理事宜。
有两种积极管理MySQL簇的基本方法。第1种方法是，使用在管理客户端中输入的命令，借此可检查簇的状态，更改日志级别，启动和停止备份，以及启动和停止节点。对于第2种方法，需要研究管理服务器DataDir目录下簇日志文件ndb_node_id_cluster.log的内容。（node_id代表其活动已被记录的节点的唯一ID）。簇日志包含由ndbd生成的事件报告。也能将簇日志条目发送到Unix的系统日志中。
本节介绍了启动簇时涉及的步骤。
有数种不同的启动类型和模式，如下所述：
· 首次启动：在所有节点上与干净的文件系统一起启动簇。这或是出现在首次启动簇时，或是使用“--initial”选项重启簇时。
· 系统重启：簇启动并读取保存在数据节点中的数据。这出现在下述情况下：使用完后关闭了簇，并希望从簇的停止点恢复簇操作时。
· 节点重启：这是在簇运行的同时簇节点的在线重启。
· 首次节点重启：与节点重启类似，差别在于将再次初始化节点，并与干净的文件系统一起启动。
启动之前，必须对每个节点进行初始化操作（ndbd进程）。这包括下述步骤：
1. 获取节点ID。
2. 获取配置数据。
3. 为节点间的通信分配端口。
4. 根据从配置文件获得的设置分配内存。
一旦完成了对各节点的初始化操作，将进入簇启动进程。在该进程中，簇将经历下述阶段：
· 阶段0
清理簇文件系统。仅当使用“--initial”选项启动簇时，才会出现。
· 阶段1
建立簇连接，建立节点间的通信。启动簇“心跳”机制。
· 阶段2
选举仲裁程序节点。
如果这是系统重启阶段，簇将确定最近的可恢复全局检查点。
· 阶段3
该阶段包括众多内部簇变量的初始化。
· 阶段4
对于初始启动或初始节点重启，将创建redo日志文件。这类文件的数目等于NoOfFragmentLogFiles／
对于系统重启：
o 读取方案。
o 从本地检查点和undo日志读取数据。
o 应用所有的redo信息，直至到达最近的可恢复检查点为止。
对于节点重启，找到redo日志的末尾。
· 阶段5
如果这是首次启动，将创建SYSTAB_0和NDB$EVENTS内部系统表。
对于节点重启或首次节点重启：
o 节点包含在事务处理操作中。
o 将节点的方案与主服务器的方案进行比较，并与其同步。
o 对所收到的、来自本节点所在节点组内其他节点的、INSERT形式的数据进行同步。
o 在任何情形下，等待由仲裁程序判定的本地检查点操作的完成。
· 阶段6
更新内部变量。
· 阶段7
更新内部变量。
· 阶段8
在系统重启中，重建所有的索引。
· 阶段9
更新内部变量。
· 阶段10
在节点重启或首次节点重启的这一阶段，API可能会连接到节点，并接收事件。
· 阶段11
在节点重启或首次节点重启的这一阶段，将事件传递任务提交给加入簇的节点。新加入的节点负责将其主要数据传递给订方。
对于首次启动或系统重启，一旦该进程完成，将启用事务处理功能。对于节点重启或首次节点重启，启动进程的完成意味着节点现在能够成为事务协调程序。
管理客户端提供了下述基本命令。在下面给出的清单中，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节点之外的所有簇节点，并退出。
在下一节中，介绍了用于事件日志的命令。在这些议题的单独一节中，介绍了用于创建备份以及从备份中恢复的命令。
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。
无论是簇日志还是节点日志，都能根据这些属性进行过滤。
下述管理命令与簇日志有关：
· 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簇开发。 |
可以打开或关闭事件严重级别。如果打开了事件严重级别，那么优先级等于或低于类别阈值的事件均将被记录。如果关闭了事件严重级别，那么将不记录属于该严重级别的任何事件。
事件日志中记录的事件报告采用下述格式：datetime [string] severity – message。例如：
09:19:30 2005-07-24 [NDB] INFO -- Node 4 Start phase 4 completed
本节讨论了所有值得通报的事件，按类别以及每一类别中的严重级别排序。
CONNECTION事件
这类事件与簇节点之间的连接有关。
|
事件 |
优先级 |
严重级别 |
描述 |
|
DB节点已连接 |
8 |
INFO |
数据节点已连接 |
|
DB节点断开连接 |
8 |
INFO |
数据节点断开连接 |
|
通信关闭 |
8 |
INFO |
SQL节点或数据节点的连接已关闭 |
|
通信打开 |
8 |
INFO |
SQL节点或数据节点的连接已打开 |
CHECKPOINT事件
下面给出的日志消息与检查点有关。
（注释：GCP =全局检查点，LCP =本地检查点）。
|
事件 |
优先级 |
严重级别 |
描述 |
|
在calc keep GCI中，LCP已停止 |
0 |
ALERT |
LCP已停止 |
|
本地检查点片段完成 |
11 |
INFO |
片段上的LCP已完成 |
|
全局检查点完成 |
10 |
INFO |
GCP完成 |
|
全局检查点启动 |
9 |
INFO |
启动GCP：将REDO日志写入磁盘 |
|
本地检查点完成 |
8 |
INFO |
LCP已正常完成 |
|
本地检查点启动 |
7 |
INFO |
启动LCP：将数据写入磁盘 |
|
报告undo日志已封闭 |
7 |
INFO |
UNDO日志已封闭：缓冲快要溢出 |
STARTUP事件
下述事件是在成功或失败的节点启动或簇启动时生成的。它们还提供了与启动进程进展状况有关的信息，包括与日志活动有关的信息。
|
事件 |
优先级 |
严重级别 |
描述 |
|
收到内部启动信号STTORRY |
15 |
INFO |
重启完成后收到的信息块 |
|
Undo记录已执行 |
15 |
INFO |
|
|
新的REDO日志已启动 |
10 |
INFO |
GCI保持X，最新的可恢复GCI Y |
|
新日志已启动 |
10 |
INFO |
日志部分X，启动MB Y，停止MB Z |
|
拒绝将节点纳入簇中 |
8 |
INFO |
由于配置错误、无法建立通信、或其他问题，不能将节点包含在簇中。 |
|
DB节点邻居 |
8 |
INFO |
显示附近的数据节点。 |
|
DB节点启动阶段X完成 |
4 |
INFO |
数据节点启动阶段已完成。 |
|
节点已被簇成功接纳 |
3 |
INFO |
显示节点，管理节点，以及动态ID。 |
|
DB节点启动阶段已开始 |
1 |
INFO |
NDB簇节点正在启动。 |
|
DB节点的所有启动阶段已完成 |
1 |
INFO |
NDB簇节点已启动。 |
|
DB节点关闭操作已启动 |
1 |
INFO |
数据节点的关闭操作已开始 |
|
DB节点关闭操作失败 |
1 |
INFO |
无法正常关闭数据节点。 |
NODERESTART事件
下述事件是在重启节点时产生的，并与节点重启进程的成功或失败相关。
|
事件 |
优先级 |
严重级别 |
描述 |
|
节点失败阶段完成 |
8 |
ALERT |
通报节点失败阶段的完成 |
|
节点失败，节点状态为X |
8 |
ALERT |
通报节点已失败 |
|
通报仲裁程序结果 |
2 |
ALERT |
对于仲裁尝试，有8种不同的可能结果： · 仲裁检查失败，剩余节点少于1/2。 · 仲裁检查成功，节点组多数 · 仲裁检查失败，丢失节点组 · 网络分区，要求仲裁 · 仲裁成功，来自节点X的正面回应 · 仲裁失败，来自节点X的负面回应 · 网络分区，无可用的仲裁程序 · 网络分区，未配置仲裁程序 |
|
完成了片段复制 |
10 |
INFO |
|
|
完成了目录信息复制 |
8 |
INFO |
|
|
完成了分配信息复制 |
8 |
INFO |
|
|
开始复制片段 |
8 |
INFO |
|
|
完成了所有片段的复制 |
8 |
INFO |
|
|
GCP接收已启动 |
7 |
INFO |
|
|
GCP接收已完成 |
7 |
INFO |
|
|
LCP接收已启动 |
7 |
INFO |
|
|
LCP接收已完成（状态= X） |
7 |
INFO |
|
|
通报是否发现了仲裁程序 |
6 |
INFO |
搜索仲裁程序时，有7种可能的结果： · 管理服务器重启仲裁线程[state=X] · 准备仲裁程序节点X [ticket=Y] · 接收仲裁程序节点X [ticket=Y] · 启动仲裁程序节点X [ticket=Y] · 丢失了仲裁程序节点X – 进程失败 [state=Y] · 丢失了仲裁程序节点X – 进程退出 [state=Y] · 丢失了仲裁程序节点X |
STATISTICS事件
下述事件具有统计特性。它们提供了相应的信息，如事务和其他操作的数目，低浓度节点发送或接收的数据量，以及内存使用率等。
|
事件 |
优先级 |
严重级别 |
描述 |
|
通报作业日程统计 |
9 |
INFO |
平均的内部作业日程统计 |
|
发送的字节数 |
9 |
INFO |
发送至节点X的平均字节数 |
|
接收的自己# |
9 |
INFO |
从节点X接收的平均字节数 |
|
通报事务统计 |
8 |
INFO |
事务数目，提交次数，读取次数，简单读取次数，写入次数，并发操作数目。属性信息，以及放弃次数 |
|
通报操作 |
8 |
INFO |
操作数目 |
|
通报表创建 |
7 |
INFO |
|
|
内存使用 |
5 |
INFO |
数据内存和索引内存的使用率（80%、90%和100%） |
ERROR事件
这些事件与簇错误和告警有关，如果出现1个或多个这类事件，表明出现了重大故障或失败。
|
事件 |
优先级 |
严重级别 |
描述 |
|
因失去心跳而死亡 |
8 |
ALERT |
因失去心跳而声明节点X死亡。 |
|
传输器错误 |
2 |
ERROR |
|
|
传输器告警 |
8 |
WARNING |
|
|
失去心跳 |
8 |
WARNING |
节点X失去心跳#Y |
|
一般性告警事件 |
2 |
WARNING |
|
INFO事件
这些事件给出了关于簇状态和簇维护活动的一般信息，如日志和心跳传输等。
|
事件 |
优先级 |
严重级别 |
描述 |
|
发出心跳 |
12 |
INFO |
将心跳发送至节点X |
|
创建日志字节 |
11 |
INFO |
日志部分，日志文件，MB |
|
一般信息事件 |
2 |
INFO |
|
采用单用户模式，数据库管理员能够将对数据库系统的访问限制在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. 重启簇的数据节点。
或
· 进入单用户模式之前重启数据库。
· 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。
开始备份前，请确保已为备份操作恰当地配置了簇。（请参见17.6.5.4节，“簇备份的配置”）。
使用管理服务器创建备份包含以下步骤：
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的备份，管理服务器不会给出任何明确回应。但是，所发出的无效放弃命令将在簇日志中给出。
簇恢复程序是作为单独的命令行实用工具ndb_restore实现的，它将读取由备份创建的文件，并将保存的信息插入数据库。必须为每组备份文件执行恢复程序，也就是说，执行次数与创建备份时运行的数据库节点数相同。
首次执行恢复程序时，还需要恢复元数据。换句话讲，必须重新创建数据库表（注意，开始执行恢复操作时，簇中应有一个空数据库）。恢复程序对于簇来说相当于API，因此，需要一个空闲连接，以便与簇相连。可使用ndb_mgm命令SHOW（在系统shell下使用ndb_mgm -e SHOW即可完成该操作）进行验证。可以使用开关“-c connectstring”来确定MGM节点的位置。（关于连接字符串的更多信息，请参见17.4.4.2节，“MySQL簇连接字符串”。备份文件必须位于恢复程序参量给定的目录下。
能够使用与创建是所用配置不同的配置将备份恢复到数据库。例如，对于备份ID为12的备份，该备份是在具有两个数据库节点（节点ID无恶2和3）的簇中创建的，可以将其恢复到具有4个节点的簇中。这样，ndb_restore必须运行两次，为创建备份时的每个数据库节点运行一次。
注释：对于快速恢复，能够以并行方式恢复数据，但必须有足够的可用簇连接。然而，数据文件必须始终前于日志文件。
有4个用于备份的基本配置参数：
· BackupDataBufferSize
将数据写入磁盘之前用于对数据进行缓冲处理的内存量。
· BackupLogBufferSize
将日志记录写入磁盘之前用于对其进行缓冲处理的内存量。
· BackupMemory
在数据库节点中为备份分配的总内存。它应是分配给备份数据缓冲的内存和分配给备份日志缓冲的内存之和。
· BackupWriteSize
写入磁盘的块大小。它适用于备份数据缓冲和备份日志缓冲
关于这些参数的更多细节，请参见17.4节，“MySQL簇的配置”。