Php文档 Php问答行业资讯 Php论坛 Php手册 Php博客

游戏榜单

软件榜单

关闭导航

热搜榜

热门下载

热门标签

关闭搜索

php爱好者> php文档>MySQL 5.1参考手册 :: 17. MySQL簇(4)

MySQL 5.1参考手册 :: 17. MySQL簇(4)

时间：2008-05-11 来源：sdccf

17.6. MySQL簇的管理

17.6.1. MySQL簇的启动阶段 17.6.2. “管理客户端”中的命令 17.6.3. MySQL簇中生成的事件报告 17.6.4. 单用户模式 17.6.5. MySQL簇的联机备份

管理MySQL簇涉及众多任务，首先是配置和启动MySQL簇。详情请参见17.4节，“MySQL簇的配置”和17.5节，“MySQL簇中的进程管理”。

下面介绍了MySQL簇的管理事宜。

有两种积极管理MySQL簇的基本方法。第1种方法是，使用在管理客户端中输入的命令，借此可检查簇的状态，更改日志级别，启动和停止备份，以及启动和停止节点。对于第2种方法，需要研究管理服务器DataDir目录下簇日志文件ndb_node_id_cluster.log的内容。（node_id代表其活动已被记录的节点的唯一ID）。簇日志包含由ndbd生成的事件报告。也能将簇日志条目发送到Unix的系统日志中。

17.6.1. MySQL簇的启动阶段

本节介绍了启动簇时涉及的步骤。

有数种不同的启动类型和模式，如下所述：

· 首次启动：在所有节点上与干净的文件系统一起启动簇。这或是出现在首次启动簇时，或是使用“--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

在节点重启或首次节点重启的这一阶段，将事件传递任务提交给加入簇的节点。新加入的节点负责将其主要数据传递给订方。

对于首次启动或系统重启，一旦该进程完成，将启用事务处理功能。对于节点重启或首次节点重启，启动进程的完成意味着节点现在能够成为事务协调程序。

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

除了中央配置文件外，还能通过管理客户端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节点之外的所有簇节点，并退出。

在下一节中，介绍了用于事件日志的命令。在这些议题的单独一节中，介绍了用于创建备份以及从备份中恢复的命令。

17.6.3. MySQL簇中生成的事件报告

17.6.3.1. 登记管理命令 17.6.3.2. 日志事件在本节中，我们讨论了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。

无论是簇日志还是节点日志，都能根据这些属性进行过滤。

17.6.3.1. 登记管理命令

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

· 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簇开发。

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

17.6.3.2. 日志事件

事件日志中记录的事件报告采用下述格式：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 <error msg> [state=Y]

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

17.6.4. 单用户模式

采用单用户模式，数据库管理员能够将对数据库系统的访问限制在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. 重启簇的数据节点。

或

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

17.6.5. MySQL簇的联机备份

17.6.5.1. 簇备份概念 17.6.5.2. 使用管理服务器创建备份 17.6.5.3. 如何恢复簇备份 17.6.5.4. 簇备份的配置 17.6.5.5. 备份故障诊断与排除在本节中，介绍了创建备份的方法，以及从备份恢复数据库的方法。

17.6.5.1. 簇备份概念

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

· 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.2. 使用管理服务器创建备份

开始备份前，请确保已为备份操作恰当地配置了簇。（请参见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的备份，管理服务器不会给出任何明确回应。但是，所发出的无效放弃命令将在簇日志中给出。

17.6.5.3. 如何恢复簇备份

簇恢复程序是作为单独的命令行实用工具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必须运行两次，为创建备份时的每个数据库节点运行一次。

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