在轻量级重新启动成功后， 成员 无法在原始主机上重新启动

发生主机故障后， 成员 将以轻量级重新启动方式成功故障转移到访客主机，但是无法进行故障恢复，并且您无法手动重新启动主主机上的 成员 。

故障恢复不成功的原因

如果主机仍关闭
请检查硬件故障或断电问题。
如果 /var 已满
Db2® 将无法在当前主机上启动，而会尝试在另一台主机上以轻量级重启模式重新启动。
注: 在此情况下可能不会发生故障恢复，因为 /var 仍然已满。 确保有足够的空间。 建议至少提供 3 GB 可用空间。
  • 集群文件系统的日志文件存储在 /var/adm/ras 中。 与集群管理器相关的任何核心文件（如果启用了核心转储）都将转至 /var/ct/<domain>/run/mc/*/*。 请检查此路径以了解该处是否存在核心文件
    • 这些路径中的旧文件可能与任何旧系统日志一起清除。
    • 将 /var 文件系统的磁盘空间增加到至少 3 GB 的可用空间。
  • 启动 GPFS ，运行 db2cluster -cfs -start host <failedHost>
  • 运行 db2cluster -cm -list -alert 以列示警报
  • 运行 db2cluster -cm -clear -alert 以清除警报
  • 如果仍存在问题，请运行 db2support <output directory> -d <database name> -s 并联系 IBM 技术支持。
如果主机已启动，但由于通信故障而无法连接或重新启动，请不要通过 RDMA 进行通信
执行以下诊断步骤以确定通过 RDMA 的通信故障是否是故障恢复未成功的原因。
  • 在发生故障的主机与 集群高速缓存设施 主机之间执行 ping 操作。
  • 运行 lsdev -C | grep -i <ib | roce> 以验证 RDMA 组件是否处于 "可用" 状态。 状态应显示为可用。
  • 使用 ibstat -v 来检查 RDMA 状态。 验证端口是否处于活动状态以及链接是否已启动。
  • 检查 cfdump.out*， core files， cfdiag*.log， mgmnt_lwd_log 以了解 集群高速缓存工具 中是否存在未启动的故障。 如果存在故障，请运行 db2instance -list，这将显示主项处于 STARTED 状态以外的状态，辅助项处于 PEER 状态以外的状态。
    • 如果 cfdump.out 未显示已初始化的信息或对象信息，那么可能是 集群高速缓存工具 未成功启动。
    • 如果 cfdump.out 具有该信息，那么 集群高速缓存工具 已在某个时间成功启动。
  • 检查物理 IB 或 RoCE 网络电缆连接
  • 通过运行以下命令在集群中执行 RDMA ping 操作：
    db2cluster -verify -req -rdma_ping
  • 如果无法通信，请运行 db2support <output directory> -d <database name> -s 并联系 IBM 技术支持。
如果主机已启动，但 sys 日志显示光纤通道卡问题/磁盘错误 /SAN 电缆连接问题 (导致与 GPFS 磁盘的连接在主机上失败)
注: 此处引用的 sys 日志只是包含系统事件信息的日志文件。 对于每个受支持的操作系统，此文件的位置都不同。 例如，在 AIX 系统上，可以通过运行 errpt来检查系统日志; 在 Linux 系统上，运行 journalctl; 在 Windows 上，从 管理工具下打开 事件查看器 ，展开 Windows 日志 并选择 系统 选项。
请参阅 磁盘故障导致 Db2 集群文件系统故障 ，或者如果 GPFS 未重新安装
  • 运行 db2cluster -cfs -list -host -state。
  • mount | grep mmfs 以了解是否任何结果显示 filesystem type=mmfs。
  • 检查连接，卡，磁盘，然后使用 db2cluster -cfs -start host <failedHost>重新启动 GPFS。

主机失败的原因

要了解主机失败的原因，请执行以下操作：