备份#

集群安装备份#

集群管理器不包含创建集群安装备份的功能。集群管理员负责决定备份集群的最佳方式，在许多可能的选择中。

强烈建议使用备份方法，并且还强烈建议检查从备份恢复是否有效。

对于某些情况，一个可能合适的选项是简单地克隆头节点。可以通过 PXE 启动新头节点并按照 Bright Cluster Manual Administrator Manual 的 第 17.4.8 节 中的步骤创建克隆。

在设置备份机制时，包括头节点的完整文件系统（即包括所有软件镜像）。除非计算节点硬盘驱动器用于存储重要数据，否则没有必要备份它们。

如果集群站点没有现有的备份基础设施，则可以使用以下开源 (GPL) 软件包来维护定期备份。

  • Bacula 需要端口 9101-9103 在头节点上可访问。在头节点的 Shorewall 规则文件中包含以下行，允许来自外部网络上 IP 地址 93.184.216.34 的这些端口的访问

  • ACCEPT net:93.184.216.34 fw tcp 9101

  • ACCEPT net:93.184.216.34 fw tcp 9102

  • ACCEPT net:93.184.216.34 fw tcp 9103

然后应该重新启动 Shorewall 服务以强制执行添加的规则。

  • rsnapshot。 rsnapshot 允许将定期增量文件系统快照写入本地或远程文件系统。尽管它很简单，但它可以成为维护系统频繁备份的非常有效的工具。更多信息请访问 http://www.rsnapshot.org。

本地数据库和数据备份与恢复#

CMDaemon 数据库存储在 MySQL cmdaemon 数据库中，包含集群的大多数存储设置。监控数据值以二进制形式存储在文件系统中，位于 /var/spool/cmd/monitoring 下。管理员应为集群运行定期备份机制，以便从最近的快照恢复所有文件。作为额外的、单独的便利

  • 对于 CMDaemon 数据库，整个数据库也在集群文件系统本身上每晚备份（“本地轮换备份”），保留最近七天的数据。

  • 对于监控数据，原始数据记录不会在本地备份，因为这些数据可能非常大。但是，监控数据的配置（存储在 CMDaemon 数据库中）也会备份最近七天的数据。

数据库损坏和修复#

MySQL 数据库损坏通常是由节点的不当关机引起的。为了解决这个问题，在启动时，MySQL 会自检是否有损坏的表，并尝试自行修复任何此类表。检测到的损坏会导致事件通知发送到 cmsh 或 Base View。当数据库损坏时，/var/log/cmdaemon 日志中的 InfoMessages 可能会提到

  • 与数据库中的表关联时发现意外的 eof。

  • 引用整个丢失的表时找不到文件。

  • 锁定的表。

  • 来自表处理程序的错误号。

  • 执行命令时出错。

如果要对数据库进行基本修复，应首先停止 CMDaemon。

1[root©headnode ~]# service cmd stop
2[root©headnode ~]# myisamchk --recover /var/lib/mysql/mysql/user.MYI
3[root©headnode ~]# service cmd start

如果基本修复失败，则可以尝试更极端的修复选项——man myisamchk(1) 建议了什么。

如果 CMDaemon 由于数据库损坏而无法启动，则 /var/log/cmdaemon 文件中的消息可能显示类似以下内容

1Oct 11 15:48:19 headnode CMDaemon: Info: Initialize cmdaemon database
2Oct 11 15:48:19 headnode CMDaemon: Info: Attempt to set provisioning Network (280374976710700) not an element of networks
3Oct 11 15:48:19 headnode CMDaemon: Fatal: Database corruption! Load Master Node with key: 280374976782569
4Oct 11 15:48:20 headnode CMDaemon: Info: Sending reconnect command to all nodes which were up before master went down ...
5Oct 11 15:48:26 headnode CMDaemon: Info: Reconnect command processed.

这里是 CMDaemon 数据库损坏消息，管理员应该注意，并建议需要对 CMDaemon 数据库进行数据库修复。在这种情况下，损坏的严重程度甚至不允许 CMDaemon 启动，这可能意味着需要从备份恢复。接下来介绍如何从备份恢复。

从本地备份恢复#

如果上一节的 MySQL 数据库修复工具无法解决问题，那么对于故障转移配置，dbreclone 选项通常应提供最新的 CMDaemon 和 Slurm 数据库。dbreclone 选项不会克隆监控数据库。

克隆数据库#

CMDaemon 附带的 cm-clone-monitoring-db.sh 帮助脚本可用于克隆监控数据库。

克隆额外的数据库#

文件 /cm/local/apps/cluster-tools/ha/conf/extradbclone.xml.template 可以用作模板，以在同一目录中创建文件 extradbclone.xml。然后可以使用 extradbclone.xml 文件来定义要克隆的其他数据库。然后运行 /cm/local/apps/cmd/scripts/cm-update-mycnf 脚本会更新 /etc/my.cnf。然后可以使用这个新的 MySQL 配置克隆数据库，方法是运行 cmha dbreclone <passive>，其中 <passive> 是被动头节点的主机名。

如果头节点不是故障转移配置的一部分，则可以从本地备份进行恢复。本地备份目录是* /var/spool/cmd/backup*，其内容如下所示

1[root©headnode ~]# cd /var/spool/cmd/backup/
2[root©headnode backup]# ls -l
3total  280
4...
5-rw------- 1 root root 33804 Oct 10 04:02 backup-Mon.sql.gz
6-rw------- 1 root root 33805 Oct  9 04:02 backup-Sun.sql.gz
7...

CMDaemon 数据库快照存储为 backup-<星期几>.sql.gz。在示例中，CMDaemon 列表中可用的最新备份结果是 backup Tue.sql.gz。然后可以将最新的备份解压缩并通过管道传输到用户 cmdaemon 的 MySQL 数据库中。密码 <password> 可以从 /cm/local/apps/cmd/etc/cmd.conf 中检索，它在 DBPass 指令中配置（Bright Cluster Manager Administrator Manual 的 附录 C）。

1gunzip backup-Tue.sql.gz
2service cmd stop #(just to make sure)
3mysql -ucmdaemon -p<password> cmdaemon < backup-Tue.sql

运行 service cmd start 应该会再次运行 CMDaemon，这次使用的是从拍摄快照时恢复的数据库。这意味着在拍摄快照之后对集群管理器所做的任何更改都不再实现。

监控数据值不保存在数据库中，而是 在文件中。

在本页中