红帽全球峰会配置 SAP HANA 扩展多目标系统复制以实现灾难恢复
摘要
使开源包含更多
红帽承诺替换我们的代码和文档中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于这一努力的精力，这些更改将在即将发布的版本中逐渐实施。有关让我们的语言更加包含的更多详情，请参阅我们的CTO Chris Wright 信息。
对红帽文档提供反馈
我们感谢您对我们文档的反馈。让我们了解如何改进它。
通过 Jira 提交反馈（需要帐户）
- 确保您已登录到 JIRA 网站。
- 通过单击此链接 来提供反馈。https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12330720&issuetype=3&components=12387093&priority=10200&summary=Doc&description=Please+include+the+Document+URL,+the+section+number+and%20+describe+the+issue&labels=SAP_DOCS&customfield_12311140=SAPOCP-775&assignee=rh-ee-pmohta
- 在 Summary 字段中输入描述性标题。
- 在 Description 字段中输入您对改进的建议。包括到文档相关部分的链接。
- 如果要通知将来的更新，请确保已分配为 Reporter。
- 点对话框底部的 Create。
第 1 章 概述
由于对可用性需求不断增长，数据的一个副本不够。
为确保业务连续性，可靠且高度可用的架构必须在多个复制站点之间复制数据。使用多目标系统复制时，主站点可将数据更改复制到多个次要站点。如需更多信息，请参阅 SAP HANA Multitarget System Replication。
本文档论述了如何在 2 节点集群中使用 SAP HANA Multitarget System Replication 配置额外的复制站点，如 使用 RHEL HA 附加组件自动化 SAP HANA Scale-Up 系统复制 中所述。
配置示例类似如下：
初始设置如下：
- 将主站点 1 (DC1)复制到次要站点 2 (DC2)
- 将主站点 1 (DC1)复制到次要站点 3 (DC3)
如果主站点失败，则主站点切换到次要站点 2 (DC2)，而以前的主站点 1 (DC1)将变为次要站点。
发生故障转移时，此解决方案可确保在第三个站点上切换配置的主站点。故障转移后的配置如下：
- 在 DC2 上运行的主
- 在 DC1 上运行辅助运行（从 DC2 同步）
- 在 DC3 上运行辅助运行（从 DC2 同步）
remotehost3 上的 SAP HANA 实例将自动重新注册到新主，只要此实例在故障转移期间启动并运行。
本文档还描述了将主数据库切换到第三个站点的示例。
请注意，将客户端连接到数据库需要进一步的网络配置。这不在本文档的讨论范围内。
如需更多信息，请检查以下内容：
第 2 章 参数
用于设置第三个站点，现有双节点集群的这些参数：
| 参数 | 示例 | 描述 |
|---|---|---|
| SID | RH2 | HANA 数据库的系统 ID |
| 第一个 SITE | DC1 | 第一个数据中心 /site 的名称 |
| 第二 SITE | DC2 | 第二个数据中心/站点的名称 |
| 第三 SITE | DC3 | 第三个数据中心/站点的名称 |
| InstanceNr | 02 | HANA 实例编号 |
| <SID>adm uid | 1000 | SAP HANA admin 用户的用户 ID (rh2adm) |
| sapsys gid | 980 | sapsys 的组 ID |
需要所有三个 HANA 实例都使用相同的值：
- SID
- InstanceNr
- <SID>adm uid
- sapsys gid
第 3 章 先决条件
要解决这一解决方案，必须满足以下要求：
所有节点必须具有相同的：
- CPU 和 RAM 数量
- 软件配置
- RHEL 发行版本（请注意，至少需要 RHEL 8.6）
- 防火墙设置
- SAP HANA 版本(SAP HANA 2.0 SPS04 或更高版本)
pacemaker 软件包仅安装在集群节点上，且必须使用相同的 resource-agents-sap-hana (0.162.1 或更高版本)。
要能够支持 SAP HANA Multitarget System Replication，请参阅 添加 SAP HANA Multitarget System Replication 支持。另外，设置以下内容：
-
use
register_secondaries_on_takeover=true -
use
log_mode=normal
初始设置基于安装指南，使用 RHEL HA 附加组件自动化 SAP HANA Scale-Up 系统复制。
所有 SAP HANA 实例的系统复制配置都基于 SAP 要求。如需更多信息，请参阅基于 SAP HANA 管理指南 的 SAP 指南。
第 4 章 安装
本章描述了额外 SAP HANA 实例的安装。
4.1. 使用故障转移测试检查 2 节点基本安装
使用 RHEL HA 附加组件，验证安装是否基于 Automating SAP HANA Scale-Up System Replication 来完成。
为了可以使用 SAP HANA Multitarget System Replication，resource-agents-sap-hana 的版本必须是 0.162.1 或更高版本。这可检查，如下所示：
rpm -q resource-agents-sap-hana
# rpm -q resource-agents-sap-hana您可以运行故障转移测试以确保环境正常工作。您可以移动 SAPHana 资源，它也在 使用 Move 故障切换 SAPHana 资源 中所述。
4.2. 在第三个站点上安装 SAP HANA
在第三个站点上，您还需要使用与在双节点 Pacemaker 集群上为 SAP HANA 实例相同的版本和参数安装 SAP HANA，如下所示：
| 参数 | 值 |
|---|---|
| SID | RH2 |
| InstanceNumber | 02 |
| <SID>adm 用户 ID | rh2adm 999 |
| sapsys 组 ID | sapsys 999 |
SAP HANA 安装使用 hdblcm 完成。如需了解更多详细信息，请参阅使用 hdbclm 的 SAP HANA 安装。另外，也可使用 Ansible 进行安装。
在本章示例中，我们使用：
- site DC1 上的 hosts:clusternode1，clusternode2 on site DC2 和 remotehost3 on site DC3
- SID RH2
- adminuser rh2adm
4.3. 将 SAP HANA 系统复制设置为第三个站点
在现有安装中，已经在双节点集群中的主和次要 SAP HANA 实例之间配置了 SAP HANA 系统复制。在启动并运行主 SAP HANA 数据库实例上启用了 SAP HANA 系统复制。
本章论述了如何在站点 DC3 的节点 remotehost3 上将第三个 SAP HANA 实例注册为额外的辅助 HANA 系统复制站点。此步骤与在节点 clusternode2 上注册原始辅助 HANA 实例(DC2)类似。以下章节将更详细地阐述。如果需要更多信息，您还可以检查 配置 SAP HANA System Replication 的一般前提条件。
4.3.1. 检查主数据库
您必须检查其他数据库是否正在运行，系统复制是否正常工作。请参阅：
您可以使用以下方法发现主 HANA 实例：
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode" mode: primary
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
mode: primary4.3.2. 复制数据库密钥
在您能够注册新的 secondary HANA 实例之前，primary HANA 实例的数据库密钥需要复制到新的 additional HANA 复制站点。在我们的示例中，第三个站点的主机名是 remotehost3。
例如，在主节点 clusternode1 上运行：
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY4.3.3. 将额外的 HANA 实例注册为辅助 HANA 复制站点
您需要知道运行 主数据库的 节点的主机名。
要监控注册，您可以在主节点上的独立终端中运行以下命令：
clusternode1:rh2adm> watch python
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/python_support/systemReplicationStatus.py
clusternode1:rh2adm> watch python
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/python_support/systemReplicationStatus.py这将显示进度以及错误（如果它们发生）。
要将第 3 个站点(DC3)上注册为额外的次要 SAP HANA 实例，请在第三个站点主机 remotehost3 上运行以下命令：
remotehost3:rh2adm> hdbnsutil -sr_register --name=DC3 --remoteHost=clusternode1 --remoteInstance=${TINSTANCE} --replicationMode=async --operationMode=logreplay --online
remotehost3:rh2adm> hdbnsutil -sr_register --name=DC3 --remoteHost=clusternode1 --remoteInstance=${TINSTANCE} --replicationMode=async --operationMode=logreplay --online在本例中，DC3 是第三个站点的名称，clusternode1 是主节点的主机名。
如果数据库实例已在运行，则不必停止它，您可以使用 --online 选项，该选项将在实例上线时注册。然后，由 hdbnsutil 本身启动实例所需的重启（停止和启动）。
选项 --online 在任何情况下都可以正常工作，当 HANA 实例上线并脱机时（此选项都可以使用 SAP HANA 2.0 SPS04 及更高版本）。
如果 HANA 实例离线，您必须在第三个节点注册后启动它。您可以在 SAP HANA System Replication 中找到更多信息。
我们使用 SAP HANA System Replication 选项，称为 register_secondaries_on_takeover = true。这将自动重新使用新的主站点重新注册辅助 HANA 实例，以防在之前的主站点和其他次要站点之间进行故障转移。这个选项必须添加到所有潜在的主站点的 global.ini 文件中。
所有 HANA 实例都应在 全局.ini 中具有此条目：
[system_replication] register_secondaries_on_takeover = true
[system_replication]
register_secondaries_on_takeover = true
以下两个章节详细描述了 global.ini 配置。
尽管参数在启动故障转移时，如果第三个节点上的额外 second HANA 实例 停机，则需要手动重新注册此 HANA 实例。
4.3.5. 在 pacemaker 节点上配置 global.ini
选项 register_secondaries_on_takeover = true 需要添加到由 pacemaker 集群管理的 SAP HANA 实例的 global.ini 中。请编辑对应节点上的 global.ini 文件，并且不要从另一个节点复制文件。
只有在站点的 HANA 实例已停止处理时，才应编辑 global.ini 文件。
以 rh2adm 用户身份编辑 global.ini ：
clusternode1:rh2adm> vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
clusternode1:rh2adm> vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.iniExample:
启动 SAP HANA 数据库实例后，此选项就会生效。
4.3.6. 在第三个站点上配置 global.ini
以 < sid>adm 用户身份编辑 global.ini ：
remotehost3:rh2adm> vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
remotehost3:rh2adm> vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
在 remotehost3 上，不使用 ha_dr_provider_SAPHanaSR 部分。
remotehost3 上的 global.ini 示例：
4.3.7. 验证安装
安装后，您必须检查所有 HANA 实例是否已启动并在运行，并且 HANA System Replication 在它们之间正常工作。最简单的方法是检查 systemReplicationStatus，如检查系统复制 状态 中详细介绍。
如需更多信息，请参阅检查数据库状态。
要使 HANA 系统复制正常工作，请确保"log_mode"参数设为"normal"。如需更多信息，请参阅 检查 SAP HANA 数据库的 log_mode。
要验证设置是否按预期工作，请运行 测试案例，如以下章节中所述。
第 5 章 测试问题单
安装完成后，建议运行一些基本测试来检查安装，并验证 SAP HANA Multitarget System Replication 如何工作，以及如何从故障中恢复。在开始生产之前，最好运行这些测试案例。如果可能，您还可以准备测试环境，以便在启动生产前验证更改。如果可能，您还可以准备测试环境，以便在生产中应用更改前检查更改。
所有情况都将描述：
- 测试的主题
- 测试先决条件
- 测试步骤
- 监控测试
- 启动测试
- 预期结果
- 返回初始状态的方法
要将以前的 primary HANA 复制站点自动注册为由集群管理的 HANA 实例的新次要 HANA 复制站点，您可以使用 SAPHana 资源中的选项 AUTOMATED_REGISTER=true 选项。如需了解更多详细信息，请参阅 AUTOMATED_REGISTER。
示例中使用的 HA 集群节点名称和 HANA 复制站点（在括号中）：
- clusternode1 (DC1)
- clusternode2 (DC2)
- remotehost3 (DC3)
以下参数用于配置 HANA 实例和集群：
- SID=RH2
- INSTANCENUMBER=02
- CLUSTERNAME=cluster1
您可以在测试环境中使用 clusternode1-2, remotehost3 作为别名。
测试更为详细，包括示例和其他前提条件检查。最后，有有关如何清理环境以进一步测试的示例。
在某些情况下，如果 clusternode1-2 和 remotehost3 之间的距离太长，您应该使用 -replcationMode=async 而不是 -replicationMode=syncmem。在选择正确的选项前，请询问您的 SAP HANA 管理员。
5.1. 准备测试
在运行测试前，整个环境需要处于正确的且健康的状态。
我们通过以下方式检查集群和数据库：
-
pcs status --full -
python $DIR_EXECUTABLE/python_support/systemReplicationStatus.py -
df -h
pcs status --full 的示例可在 Check cluster status 中找到。如果 "Migration Summary" 中存在警告或之前失败，您应该在开始测试前清理集群。
pcs resource clear SAPHana_RH2_02-clone
[root@clusternode1]# pcs resource clear SAPHana_RH2_02-clone集群清理 描述了进行它的一些更多方法。务必要启动集群及所有资源。
除了集群外，数据库也应该已启动并在同步。验证数据库的正确状态的最简单方法是检查系统复制状态。另请参阅 Replication Status。这应该会在主数据库中检查。
要发现主节点，您可以检查 发现主数据库 或使用：
pcs status | grep -E "Promoted|Master" hdbnsutil -sr_stateConfiguration
[root@clusternode1]# pcs status | grep -E "Promoted|Master"
[root@clusternode1]# hdbnsutil -sr_stateConfiguration运行以下命令，检查文件系统中是否有足够空间：
df -h
[root@clusternode1]# df -h在继续操作前，请按照 系统检查 的指南进行操作。如果环境清理干净，就可以运行测试。
5.2. 监控环境
在本节中，我们专注于在测试期间监控环境。本节仅涵盖查看更改所需的 monitor。建议从专用终端运行这些监控器。为了能够在测试期间检测更改，建议在开始测试前启动监控。
在 Useful Commands 部分中，会显示更多示例。
5.2.1. 发现主节点
您需要发现主节点来监控故障转移，或运行某些命令，它们仅在主节点上执行时提供有关复制状态的信息。
要发现主节点，您可以以 < sid>adm 用户身份运行以下命令：
clusternode1:rh2adm> watch -n 5 'hdbnsutil -sr_stateConfiguration | egrep -e "primary masters|^mode"'
clusternode1:rh2adm> watch -n 5 'hdbnsutil -sr_stateConfiguration | egrep -e "primary masters|^mode"'输出示例，当 clusternode2 是主数据库时：
mode: syncmem primary masters: clusternode2
mode: syncmem
primary masters: clusternode2在运行主数据库的节点上的输出是：
mode: primary
mode: primary5.2.2. 检查 Replication 状态
复制状态显示主数据库节点和次要数据库节点与复制的当前状态之间的关系。
要发现复制状态，您可以以 < sid>adm 用户身份运行：
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration如果要永久监控系统复制状态的变化，请运行以下命令：
clusternode1:rh2adm> watch -n 5 'python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
clusternode1:rh2adm> watch -n 5 'python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
这个示例还决定了当前的返回代码。
只要返回代码（状态）为 15，复制状态就正常。其他返回代码包括：
- 10: NoHSR
- 11: error
- 12: unknown
- 13: 初始化
- 14: 同步
- 15: active
如果注册了新的次要设备，您可以在主节点上的单独窗口中运行它，您会看到复制的进度。如果要监控故障转移，您可以在旧主以及新的主数据库服务器上并行运行它。如需更多信息，请参阅 检查 SAP HANA 系统复制状态。
5.2.3. 检查 /var/log/messages 条目
Pacemaker 将大量信息写入 /var/log/messages 文件中。在故障转移过程中，大量信息会被写入这个消息文件中。要根据 SAP HANA 资源代理只遵循重要的消息，过滤 pacemaker SAP 资源的详细活动非常有用。足以检查单个集群节点上的消息文件。
例如，您可以使用这个别名：
tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_$SAPSYSTEMNAME_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
[root@clusternode1]# tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_$SAPSYSTEMNAME_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
在单独的窗口中运行 tmsl 来监控测试的进度。还要检查 monitor 故障切换和同步状态的示例。
5.2.4. 集群状态
有几种方法可以检查集群状态。
检查集群是否正在运行：
-
pcs cluster status
-
检查集群和所有资源：
-
pcs status
-
检查集群、所有资源和所有节点属性：
-
pcs status --full
-
仅检查资源：
-
pcs resource
-
pcs status --full 命令将为您提供所有必要的信息。要监控更改，您可以与 watch 一起运行这个命令：
watch pcs status --full
[root@clusternode1]# watch pcs status --full可以在 Check cluster status 中找到输出示例和更多选项。
5.2.5. 发现左侧
为确保您的环境准备好运行下一个测试，需要修复或删除之前测试中的左侧。
stonith用于隔离集群中的节点：-
detect:
[root@clusternode1]# pcs stonith history -
Fix:
[root@clusternode1]# pcs stonith cleanup
-
detect:
多个主数据库：
detect:
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration | grep -i primary需要识别具有相同主的所有节点。
-
fix: 使用
--force_full_replica选项重新注册错误的主
移动导致的位置限制：
detect:
[root@clusternode1]# pcs constraint location检查警告部分。
-
Fix:
[root@clusternode1]# pcs resource clear <clone-resource-which was moved>
二级复制关系：
-
detect: on the primary database run
clusternode1:rh2adm> python $DIR_EXECUTABLE/python_support/systemReplicationStatus.py - 修复：取消注册并重新注册辅助数据库。
-
detect: on the primary database run
检查 siteReplicationMode （所有 SAP HANA 节点上的相同输出）
-
clusternode1:rh2adm> hdbnsutil -sr_state --sapcontrol=1 |grep site prerequisitesMode
-
pcs 属性：
-
detect:
[root@clusternode1]# pcs property config -
Fix:
[root@clusternode1]# pcs property set <key=value>
-
detect:
清除
maintenance-mode。-
[root@clusternode1]# pcs property set maintenance-mode=false
-
log_mode ：
detect:
clusternode1:rh2adm> python systemReplicationStatus.py将响应
log_mode通常需要的复制状态。可以检测到log_mode，如 使用 hdbsql 检查 Inifile 内容 中所述。-
fix ：将
log_mode更改为 normal，然后重新启动主数据库。
CIB 条目：
detect: 集群信息基础中的 SFAIL 条目。
请参阅 检查集群一致性，以查找和删除 CIB 条目。
cleanup/clear:
detect:
[root@clusternode1]# pcs status --full有时它会显示错误或警告。您可以清理/清理/清理资源，如果一切正常，则不会发生。在运行下一个测试前，您可以清理您的环境。
修复示例：
[root@clusternode1]# pcs resource clear <name-of-the-clone-resource>[root@clusternode1]# pcs resource cleanup <name-of-the-clone-resource>
如果要检查现有环境中是否有问题，这也很有用。
如需更多信息，请参阅 用法 命令。
5.3. 测试 1：故障切换具有活跃第三个站点的主节点
| 测试的主题 | 自动重新注册第三个站点。 清除后，将状态更改为 SOK。 |
| 测试先决条件 |
|
| 测试步骤 |
使用 |
| 监控测试 |
在第三个站点中，作为
在辅助节点上运行： |
| 启动测试 | 执行集群命令：
|
| 预期结果 | 在 site 3 上的 monitor 命令中，主主从 clusternode1 变为 clusternode2。
清除资源后，同步状态将从 |
| 返回初始状态的方法 | 运行测试两次。 |
(*)
remotehost3:rh2adm> watch hdbnsutil -sr_state [root@clusternode1]# tail -1000f /var/log/messages |egrep -e ‘SOK|SWAIT|SFAIL’
remotehost3:rh2adm>
watch hdbnsutil -sr_state
[root@clusternode1]# tail -1000f /var/log/messages |egrep -e ‘SOK|SWAIT|SFAIL’详细描述
以 root 用户身份在 clusternode1 或 clusternode2 上检查集群的初始状态。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此输出显示，HANA 在 clusternode1 上被提升，它是主 SAP HANA 服务器，克隆资源的名称为 SAPHana_RH2_02-clone 是可升级的。
您可以在测试期间在单独的窗口中运行它来查看更改：watch pcs status --full
[root@clusternode1]# watch pcs status --fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow 识别 SAP HANA 克隆资源的另一种方法是：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要在开始测试前，在 remotehost3 上查看主服务器在 remotehost3 上启动监控的更改。
remotehost3:rh2adm> watch 'hdbnsutil -sr_state | grep "primary masters"
remotehost3:rh2adm> watch 'hdbnsutil -sr_state | grep "primary masters"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出类似如下：
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:47:21 2023 primary masters: clusternode1
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:47:21 2023 primary masters: clusternode1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在测试过程中，预期的输出将更改为 clusternode2。
通过将上面发现的克隆资源移到 clusternode2 来启动测试：
pcs resource move SAPhana_RH2_02-clone clusternode2
[root@clusternode1]# pcs resource move SAPhana_RH2_02-clone clusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 上的 monitor 的输出将更改为：
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:50:31 2023 primary masters: clusternode2
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:50:31 2023 primary masters: clusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pacemaker 为移动克隆资源创建一个位置约束。这需要手动删除。您可以使用以下方法查看约束：
pcs constraint location
[root@clusternode1]# pcs constraint locationCopy to Clipboard Copied! Toggle word wrap Toggle overflow 需要删除此约束。
清除克隆资源以删除位置约束：
pcs resource clear SAPhana_RH2_02-clone Removing constraint: cli-prefer-SAPHana_RH2_02-clone
[root@clusternode1]# pcs resource clear SAPhana_RH2_02-clone Removing constraint: cli-prefer-SAPHana_RH2_02-cloneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 清理资源：
pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)
[root@clusternode1]# pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
测试的结果
- remotehost3 上的"主 master"监控应该立即切换到新主节点。
-
如果您检查集群状态，则以前的次要会被提升，以前的主会被重新注册，并且
Clone_State从Promoted变为UndefinedtoWAITINGFORLPAtoDEMOTED。 -
当
SAPHanamonitor 在故障转移后第一次启动时，次要会将sync_state更改为SFAIL。由于现有位置约束，资源需要被清除，并在次要的sync_state的短时间将再次更改为SOK。 - 二级被提升。
要恢复初始状态，您只需运行下一个测试即可。完成测试后，运行 清理。
5.4. 测试 2：故障切换具有被动第三个站点的主节点
| 测试的主题 | 没有重新注册已停止的第三个站点。 即使第三个站点停机，故障转移也可以正常工作。 |
| 测试先决条件 |
|
| 测试步骤 |
使用 |
| 启动测试 |
执行集群命令 |
| 预期结果 | DC3 没有更改。SAP HANA 系统复制与旧关系保持同步。 |
| 返回初始状态的方法 | 在新主上重新注册 DC3，并启动 SAP HANA。 |
详细描述
以 root 用户身份在 clusternode1 或 clusternode2 上检查集群的初始状态：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 本例的输出显示，HANA 在 clusternode1 上被提升，它是主 SAP HANA 服务器，克隆资源的名称为
SAPHana_RH2_02-clone是可升级的。如果您在 HANA 之前运行 test 3，则可能会在 clusternode2 上提升。停止 remotehost3 上的数据库：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查 remotehost3 上的主数据库：
remotehost3:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i "primary masters" primary masters: clusterclusternode2
remotehost3:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i "primary masters" primary masters: clusterclusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查集群节点上集群中的当前主要信息：
pcs resource | grep Masters * Masters: [ clusternode2 ][root@clusterclusternode1]# pcs resource | grep Masters * Masters: [ clusternode2 ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
sr_state以查看 SAP HANA 系统复制关系：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
SAP HANA 系统复制关系仍然有一个主要(DC1)，它被复制到 DC2 和 DC3。remotehost3 （关闭）上的复制关系可以使用以下方法显示：
remotehost3 上的数据库，其离线检查 global.ini 文件中的条目。
启动测试：在集群中启动故障转移，移动
SAPHana-clone-resource示例：pcs resource move SAPHana_RH2_02-clone clusternode2
[root@clusternode1]# pcs resource move SAPHana_RH2_02-clone clusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果在 clusternode2 上提升 SAPHana，则必须将克隆资源移到 clusternode1。该示例要求 SAPHana 在 clusternode1 上提升。
没有输出。与之前的测试类似，会创建一个位置约束，该约束可以使用以下方法显示：
pcs constraint location Location Constraints: Resource: SAPHana_RH2_02-clone Enabled on: Node: clusternode1 (score:INFINITY) (role:Started)[root@clusternode1]# pcs constraint location Location Constraints: Resource: SAPHana_RH2_02-clone Enabled on: Node: clusternode1 (score:INFINITY) (role:Started)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 即使集群再次查找正常，此约束也会避免另一个故障转移，除非删除了约束。其中一种方法是清除资源。
清除资源：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 清理资源：
pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)
[root@clusternode1]# pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查当前状态。可以通过两种方式显示需要同步的复制状态。从 remotehost3 上的主设备开始：
remotehost3:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i primary active primary site: 1 primary masters: clusternode1
remotehost3:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i primary active primary site: 1 primary masters: clusternode1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出显示站点 1 或 clusternode1，这是开始测试之前的主要内容，将主要移到 clusternode2。然后再检查新主上的系统复制状态。首先检测新主设备：
pcs resource | grep Master * Masters: [ clusternode2 ][root@clusternode1]# pcs resource | grep Master * Masters: [ clusternode2 ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在这里，我们有一个不一致的，需要重新注册 remotehost3。您可能认为，如果我们再次运行测试，我们可能会将主设备切回到原始 clusternode1。在这种情况下，我们有第三个方法来识别系统复制是否正常工作。在主节点上，我们的问题单 clusternode2 运行：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果在此输出中没有看到 remotehost3，则必须重新注册 remotehost3。在注册前，请在主节点上运行以下内容以观察注册的进度：
clusternode2:rh2adm> watch python $DIR_EXECUTABLE/python_support/systemReplicationStatus.py
clusternode2:rh2adm> watch python $DIR_EXECUTABLE/python_support/systemReplicationStatus.pyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 现在，您可以使用以下命令重新注册 remotehost3：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 即使 remotehost3 上的数据库尚未启动，您也无法在系统复制状态输出中看到第三个站点。
通过在 remotehost3 上启动数据库，可以完成注册：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
上面启动的监控器将立即显示 remotehost3 的同步。
- 要切换回来，请再次运行测试。一个可选测试是将主要测试切换到节点，该节点在 remotehost3 上的 global.ini 上配置，然后启动数据库。数据库可能会启动，但永远不会显示在系统复制状态的输出中，除非它被重新注册。
如需更多信息，请参阅 检查 SAP HANA 系统复制状态。
5.5. 测试 3：将主站点故障切换到第三个站点
| 测试的主题 | 将主站点故障转移到第三个站点。 辅助将重新注册到第三个站点。 |
| 测试先决条件 |
|
| 测试步骤 |
将集群设置为
使用 |
| 启动测试 |
执行 SAP HANA 命令on remotehost3: |
| 监控测试 |
在第三个站点 run: |
| 预期结果 |
|
| 返回初始状态的方法 |
详细描述
检查数据库是否使用 Check 数据库 运行，并检查复制状态：
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
例如，输出为：
mode: syncmem primary masters: clusternode1
mode: syncmem
primary masters: clusternode1在这种情况下，主数据库是 clusternode1。如果在 clusternode1 上运行这个命令，您将获得：
mode: primary
mode: primary在这个主节点上，您还可以显示系统复制状态。它应该类似如下：
- 现在，我们有一个适当的环境，我们可以开始监控所有 3 个节点上的系统复制状态。
在测试启动前，应启动 3 个监视器。执行测试时，输出将改变。因此，只要测试还没有完成，使它们保持运行。
在旧的主节点上，clusternode1 在测试过程中在一个单独的窗口中运行：
clusternode1:rh2adm> watch -n 5 'python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?`
clusternode1:rh2adm> watch -n 5 'python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?`clusternode1 上的输出将是：
在 remotehost3 上运行相同的命令：
remotehost3:rh2adm> watch -n 5 'python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
remotehost3:rh2adm> watch -n 5 'python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'响应将是：
this system is either not running or not primary system replication site
this system is either not running or not primary system replication site测试启动故障转移后，输出将改变。在测试启动前，输出类似于主节点的示例。
在第二个节点上启动：
clusternode2:rh2adm> watch -n 10 'hdbnsutil -sr_state | grep masters'
clusternode2:rh2adm> watch -n 10 'hdbnsutil -sr_state | grep masters'这将显示当前 master clusternode1，并在启动故障转移后立即切换。
-
为确保一切配置正确，还要检查
global.ini。 -
在 DC1、DC2 和 DC3 上检查
global.ini。
在所有三个节点上，global.ini 应该包含：
[persistent] log_mode=normal [system_replication] register_secondaries_on_takeover=true
[persistent]
log_mode=normal
[system_replication]
register_secondaries_on_takeover=true您可以使用以下内容编辑 global.ini：
clusternode1:rh2adm>vim /usr/sap/$SAPSYSTEMNAME/SYS/global/hdb/custom/config/global.ini
clusternode1:rh2adm>vim /usr/sap/$SAPSYSTEMNAME/SYS/global/hdb/custom/config/global.ini[可选] 将集群置于
maintenance-mode：pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在测试过程中，您会发现故障转移将使用 和，而不设置
maintenance-mode。因此，您可以在不使用它的情况下运行第一个测试。在恢复它时，我只想向您显示，而是使用。这是主要方面的一个选项，不能访问。开始测试：故障切换到 DC3。在 remotehost3 上，请运行：
remotehost3:rh2adm> hdbnsutil -sr_takeover done.
remotehost3:rh2adm> hdbnsutil -sr_takeover done.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
测试已启动，现在请检查之前启动的 monitor 的输出。
在 clusternode1 上，系统复制状态将丢失与 remotehost3 和 clusternode2 (DC2)的关系：
集群仍然不会注意到此行为。如果您检查系统复制状态的返回码，则返回码 11 表示错误，这告诉您出现问题。如果您有访问权限，现在最好进入 maintenance-mode。
remotehost3 变为新的主主，而 clusternode2 (DC2)会在 remotehost3 上自动注册为新主。
remotehost3 的系统复制状态的输出示例：
returncode 15 还表示一切都是 okay，但缺少 clusternode1。这必须手动重新注册。前一个主 clusternode1 没有被列出，因此复制关系会丢失。
-
设置
maintenance-mode。
如果还没有在集群的一个节点上设置 maintenance-mode 之前完成，使用以下命令：
pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=true
您可以运行以下命令来检查 maintenance-mode 是否活跃：
资源显示非受管状态，这表示集群处于 maintenance-mode=true。虚拟 IP 地址仍然在 clusternode1 上启动。如果要在另一个节点上使用此 IP，请在设置 maintanence-mode=true 前禁用 vip_RH2_02_MASTER。
pcs resource disable vip_RH2_02_MASTER
[root@clusternode1]# pcs resource disable vip_RH2_02_MASTER当我们检查 clusternode1 上的 sr_state 时，您将只看到一个与 DC2 的关系：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 但是，当检查 DC2 时，主数据库服务器为 DC3。因此，DC1 的信息不正确。
clusternode2:rh2adm> hdbnsutil -sr_state
clusternode2:rh2adm> hdbnsutil -sr_stateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果我们在 DC1 上检查系统复制状态，则返回码为 12 （未知）。因此，需要重新注册 DC1。
您可以使用此命令将以前的主 clusternode1 注册为 remotehost3 的新辅助设备：
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=async --name=DC1 --remoteName=DC3 --operationMode=logreplay --online
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=async --name=DC1 --remoteName=DC3 --operationMode=logreplay --online注册完成后，您将在 remotehost3 上看到复制三个站点，状态（重新代码）将变为 15。如果此操作失败，则必须手动删除 DC1 和 DC3 上的复制关系。请按照 Register Secondary 中描述的说明进行操作。例如，列出现有关系：
hdbnsutil -sr_state
hdbnsutil -sr_state删除您可以使用的现有关系示例：
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC2
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC2这通常不需要这样做。
我们假定测试 4 将在测试 3 后执行。因此，恢复步骤是运行测试 4。
5.6. 测试 4：将主节点故障转移到第一个站点
| 测试的主题 | 主切换回一个集群节点。 故障恢复并再次启用集群。 将第三个站点重新注册为次要站点。 |
| 测试先决条件 |
|
| 测试步骤 | 检查集群的预期主要信息。 从 DC3 节点故障转移到 DC1 节点。 检查前期次要是否已切换到新主设备。 重新注册 remotehost3 作为新的次要。
设置 cluster |
| 监控测试 | 在新的主启动时：
|
| 启动测试 |
检查集群的预期主要内容： VIP 和提升 SAP HANA 资源应该在同一节点上运行，而这是潜在的新主要资源。
在这个潜在的主要运行中： 重新将前一个主重新注册为新次要：
在设置 |
| 预期结果 | 新主要是启动 SAP HANA。 复制状态将显示所有 3 个站点复制。 第二个集群站点会自动重新注册到新主站点。 灾难恢复(DR)站点成为数据库的额外副本。 |
| 返回初始状态的方法 | 运行测试 3。 |
详细描述
检查集群是否已设置为
maintenance-mode：pcs property config maintenance-mode Cluster Properties: maintenance-mode: true
[root@clusternode1]# pcs property config maintenance-mode Cluster Properties: maintenance-mode: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果
maintenance-mode不是 true，您可以使用以下方法对其进行设置：pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查系统复制状态，并发现所有节点上的主数据库。首先使用以下命令发现主数据库：
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
其输出应如下所示：
在 clusternode1 上：
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: syncmem primary masters: remotehost3
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
mode: syncmem
primary masters: remotehost3在 clusternode2 上：
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: syncmem primary masters: remotehost3
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
mode: syncmem
primary masters: remotehost3在 remotehost3:
remotehost3:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: primary
remotehost3:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
mode: primary在所有三个节点上，主数据库为 remotehost3。在这个主数据库中，您必须确保所有三个节点的系统复制状态处于活跃状态，返回码为 15：
-
检查所有三个
sr_states都一致。
请在所有三个节点上运行 hdbnsutil -sr_state --sapcontrol=1 |grep site prerequisitesMode:
clusternode1:rh2adm>hdbnsutil -sr_state --sapcontrol=1 |grep site.*Mode
clusternode1:rh2adm>hdbnsutil -sr_state --sapcontrol=1 |grep site.*Modeclusternode2:rh2adm>hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
clusternode2:rh2adm>hsbnsutil -sr_state --sapcontrol=1 | grep site.*Moderemotehost3:rh2adm>hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
remotehost3:rh2adm>hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode所有节点上的输出应该相同：
- 在单独的窗口中启动监控。
在 clusternode1 启动时：
clusternode1:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"
clusternode1:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"在 remotehost3 启动时：
remotehost3:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"
remotehost3:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"在 clusternode2 启动时：
clusternode2:rh2adm> watch "hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode"
clusternode2:rh2adm> watch "hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode"- 启动测试
在 clusternode1 上切换到 clusternode1 启动：
clusternode1:rh2adm> hdbnsutil -sr_takeover done.
clusternode1:rh2adm> hdbnsutil -sr_takeover
done.- 检查 monitor 的输出。
clusternode1 上的监控器将更改为：
重要信息也是返回代码 15。clusternode2 上的监控器将更改为：
DC3 已消失，需要重新注册。在 remotehost3 上，systemReplicationStatus 会报告一个错误，并将 returncode 变为 11。
检查集群节点是否已重新注册。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 站点映射显示，clusternode2 (DC2)被重新注册。
检查或启用 vip 资源：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow vip 资源
vip_RH2_02_MASTER已停止。要再次运行它：
pcs resource enable vip_RH2_02_MASTER Warning: 'vip_RH2_02_MASTER' is unmanaged
[root@clusternode1]# pcs resource enable vip_RH2_02_MASTER
Warning: 'vip_RH2_02_MASTER' is unmanaged
警告正确，因为集群不会启动任何资源，除非 maintenance-mode=false。
-
停止集群
维护模式。
在我们停止 maintenance-mode 之前，我们应在单独的窗口中启动两个 monitor 以查看更改。在 clusternode2 上运行：
watch pcs status --full
[root@clusternode2]# watch pcs status --full在 clusternode1 上运行：
clusternode1:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo $?"
clusternode1:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo $?"
现在，您可以运行以下命令，在 clusternode1 上取消设置 maintenance-mode ：
pcs property set maintenance-mode=false
[root@clusternode1]# pcs property set maintenance-mode=falseclusternode2 上的 monitor 应该显示一切现在都如预期运行：
手动交互后，最好清理集群，如 Cluster Cleanup 所述。
- 将 remotehost3 重新注册到 clusternode1 上的新主卷。
需要重新注册 Remotehost3。要监控进度，请在 clusternode1 上启动：
clusternode1:rh2adm> watch -n 5 'python
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
clusternode1:rh2adm> watch -n 5 'python
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'在 remotehost3 上，请开始：
remotehost3:rh2adm> watch 'hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode'
remotehost3:rh2adm> watch 'hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode'现在，您可以使用这个命令重新注册 remotehost3：
remotehost3:rh2adm> hdbnsutil -sr_register --remoteHost=clusternode1 --remoteInstance=${TINSTANCE} --replicationMode=async --name=DC3 --remoteName=DC1 --operationMode=logreplay --online
remotehost3:rh2adm> hdbnsutil -sr_register --remoteHost=clusternode1 --remoteInstance=${TINSTANCE} --replicationMode=async --name=DC3 --remoteName=DC1 --operationMode=logreplay --onlineclusternode1 上的监控器将更改为：
remotehost3 的监控器将更改为：
现在，我们再次有 3 个条目，remotehost3 (DC3)再次是从 clusternode1 (DC1)复制的次要站点。
- 检查所有节点是否是 clusternode1 上的系统复制状态的一部分。
请在所有三个节点上运行 hdbnsutil -sr_state --sapcontrol=1 |grep site prerequisitesMode:
clusternode1:rh2adm> hdbnsutil -sr_state --sapcontrol=1 |grep site.*ModesiteReplicationMode
clusternode1:rh2adm> hdbnsutil -sr_state --sapcontrol=1 |grep site.*ModesiteReplicationModeclusternode2:rh2adm> hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
clusternode2:rh2adm> hsbnsutil -sr_state --sapcontrol=1 | grep site.*Moderemotehost3:rh2adm> hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
remotehost3:rh2adm> hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode在所有节点上，我们应该获得相同的输出：
-
检查
pcs status --full和SOK。运行：
pcs status --full| grep sync_state
[root@clusternode1]# pcs status --full| grep sync_state
输出应该是 PRIM 或 SOK ：
* hana_rh2_sync_state : PRIM
* hana_rh2_sync_state : SOK
* hana_rh2_sync_state : PRIM
* hana_rh2_sync_state : SOK
最后，集群状态应如下所示，包括 sync_state PRIM 和 SOK ：
请参阅 检查集群状态和 Check 数据库，以验证所有是否再次工作。
第 6 章 有用的命令
以下是有用的命令的 3 部分。在大多数情况下，它应该有助于验证操作或配置是否成功。示例与响应一起列出。在某些情况下，出于格式化原因，输出已被调整。
-
当由 <
sid>adm 用户以 >开头时，此文档中列出的所有命令均以 > 开头。 -
root 用户运行的所有命令都以#开头。 -
要执行命令，请省略 prefix > 或
#。
6.1. SAP HANA 命令
SAP HANA 命令由 < sid>adm 用户执行。Example:
6.1.1. 使用 hdbclm进行 SAP HANA 安装
第三个站点的安装与第二个站点的安装类似。安装可以使用 hdblcm 作为用户 root 来完成。为确保之前未安装任何内容，请运行 hdbuninst 以检查 SAP HANA 是否尚未安装在此节点上。
HANA 卸载的输出示例：
cd /software/DATA_UNITS/HDB_SERVER_LINUX_X86_64 root@DC3/software/DATA_UNITS/HDB_SERVER_LINUX_X86_64# ./hdbuninst Option 0 will remove an already existing HANA Installation No SAP HANA Installation found is the expected answer
[root@remotehost3]# cd /software/DATA_UNITS/HDB_SERVER_LINUX_X86_64
root@DC3/software/DATA_UNITS/HDB_SERVER_LINUX_X86_64# ./hdbuninst
Option 0 will remove an already existing HANA Installation
No SAP HANA Installation found is the expected answerDC3 上 HANA 安装的输出示例：
在安装开始前，会列出概述：
输入 y 开始安装。
6.1.2. 使用 hdbsql 检查 Inifile 内容
6.1.3. 检查数据库
检查数据库是否正在运行，并发现当前的主节点。
列出数据库实例
如果输出为绿色，则实例正在运行。
列出数据库进程
通常，所有数据库进程都处于 GREEN 状态。
列出 SAP HANA 进程
显示 SAP HANA landscape 配置
返回码：
- 0: fatal
- 1: error
- 2: warning
- 3: info
- 4: OK
发现主数据库
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"辅助检查示例：
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode" mode: syncmem primary masters: clusternode1
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
mode: syncmem
primary masters: clusternode1在当前主上检查示例：
显示数据库版本
使用 SQL 查询的示例：
hdbsql RH2=> select * from m_database SYSTEM_ID,DATABASE_NAME,HOST,START_TIME,VERSION,USAGE "RH2","RH2","node1","2023-06-22 15:33:05.235000000","2.00.059.02.1647435895","CUSTOM" 1 row selected (overall time 29.107 msec; server time 927 usec)
hdbsql RH2=> select * from m_database
SYSTEM_ID,DATABASE_NAME,HOST,START_TIME,VERSION,USAGE
"RH2","RH2","node1","2023-06-22 15:33:05.235000000","2.00.059.02.1647435895","CUSTOM"
1 row selected (overall time 29.107 msec; server time 927 usec)
使用 systemOverview.py 的示例：
6.1.4. 启动和停止 SAP HANA
选项 1：HDB 命令
clusternode1:rh2adm> HDB help
Usage: /usr/sap/RH2/HDB02/HDB { start|stop|reconf|restart|version|info|proc|admin|kill|kill-<sig>|term }
kill or kill-9 should never be used in a productive environment!
clusternode1:rh2adm> HDB help
Usage: /usr/sap/RH2/HDB02/HDB { start|stop|reconf|restart|version|info|proc|admin|kill|kill-<sig>|term }
kill or kill-9 should never be used in a productive environment!启动数据库
clusternode1:rh2adm> HDB start
clusternode1:rh2adm> HDB startCopy to Clipboard Copied! Toggle word wrap Toggle overflow 停止数据库
clusternode1:rh2adm> HDB stop
clusternode1:rh2adm> HDB stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
选项 2 （推荐）：使用 sapcontrol
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StartSystem HDB
03.07.2023 14:08:30
StartSystem
OK
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StartSystem HDB
03.07.2023 14:08:30
StartSystem
OKclusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StopSystem HDB
03.07.2023 14:09:33
StopSystem
OK
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StopSystem HDB
03.07.2023 14:09:33
StopSystem
OK使用 GetProcessList 来监控 HANA 服务的启动和停止：
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function GetProcessList
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function GetProcessList6.1.5. 检查 SAP HANA System Replication 状态
有多种方法可以检查 SAP HANA 系统复制状态：
- 'clusternode1:rh2adm> python systemReplicationStatus.py ' on the primary node
-
clusternode1:rh2adm> echo $? #(Return code of systemReplicationStatus) -
clusternode1:rh2adm> hdbnsutil -sr_state -
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration
作为监控器运行的 systemReplicationStatus.py 输出示例：
返回代码的预期结果为：
- 10: NoHSR
- 11: error
- 12: unknown
- 13: 初始化
- 14: 同步
- 15: active
在大多数情况下，系统复制检查将返回返回码 15。另一个显示选项是使用 -t (printLandscapeTree)。
当前主机上的输出示例：
clusternode1:rh2adm> python systemReplicationStatus.py -t
HANA System Replication landscape:
DC1 ( primary )
| --- DC3 ( syncmem )
| --- DC2 ( syncmem )
clusternode1:rh2adm> python systemReplicationStatus.py -t
HANA System Replication landscape:
DC1 ( primary )
| --- DC3 ( syncmem )
| --- DC2 ( syncmem )
hdbnsutil -sr_state 示例：
主上的 sr_stateConfiguation 示例：
二级上的 sr_stateConfiguration 示例：
您还可以在节点是当前主的辅助数据库中检查。在故障转移过程中，会出现两个主数据库，并且需要这些信息来确定潜在的主数据库错误，需要重新注册为次要数据库。
如需更多信息，请参阅示例 ：检查 Primary 和 Secondary Systems 上的状态。
6.1.6. 注册辅助节点
为 SAP HANA 系统复制环境注册辅助数据库的先决条件：
注册示例：
在注册了 global.ini 文件后，将自动更新
…来自：
…至：
6.1.7. sapcontrol GetProcessList
检查活跃的 SAP HANA 数据库的进程
6.1.8. sapcontrol GetInstanceList
这将列出 SAP HANA 数据库的实例状态。它还将显示端口。有三个不同的状态名称：
- GREEN （运行）
- GRAY （停止）
- YELLOW （当前正在更改）
活跃实例示例：
停止的实例示例：
6.1.9. hdbcons 示例
您还可以使用 HDB 控制台显示数据库的信息：
-
hdbcons -e hdbindexserver 'replication info' -
hdbcons -e hdbindexserver 帮助更多选项
'replication info' 示例：
帮助示例：
6.1.10. 创建 SAP HANA 备份
如果要使用 SAP HANA 系统复制，必须首先在主系统上创建一个备份。
如何执行此操作的示例为用户 < sid>adm:
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d SYSTEMDB "BACKUP DATA USING FILE ('/hana/backup/')"
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d ${SAPSYSTEMNAME} "BACKUP DATA USING FILE ('/hana/backup/')"
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d SYSTEMDB "BACKUP DATA USING FILE ('/hana/backup/')"
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d ${SAPSYSTEMNAME} "BACKUP DATA USING FILE ('/hana/backup/')"6.1.11. 在主数据库上启用 SAP HANA 系统复制
必须在主节点上启用 SAP HANA 系统复制。这要求首先进行备份。
clusternode1:rh2adm> hdbnsutil -sr_enable --name=DC1 nameserver is active, proceeding ... successfully enabled system as system replication source site done.
clusternode1:rh2adm> hdbnsutil -sr_enable --name=DC1
nameserver is active, proceeding ...
successfully enabled system as system replication source site
done.6.1.12. 将数据库密钥复制到辅助节点
数据库密钥需要从主数据库复制到次要数据库，然后才能将其注册为次要数据库。
例如：
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY6.1.13. 为 SAP HANA 系统复制注册辅助节点
请确定数据库密钥已首先复制到次要节点。然后运行注册命令：
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC1 --remoteName=DC3 --operationMode=logreplay --online
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC1 --remoteName=DC3 --operationMode=logreplay --online参数描述：
-
remotehost: 运行源（主）数据库的活动节点的主机名 -
remoteInstance：数据库的实例数 replicationMode：以下选项之一-
同步：硬盘同步 -
async: 异步复制 -
syncmem: 内存同步
-
-
名称：这是此复制站点的别名 -
remoteName：源数据库的别名名称 operationMode：以下选项之一-
delta_datashipping：定期传输数据。接管需要更长的时间。 -
logreplay: 在远程站点上立即为 redone 日志。接管速度更快。 -
logreplay_readaccess：可能对第二个站点进行额外的 logreplay 只读访问。
-
6.1.14. 检查 SAP HANA 数据库的 log_mode
设置 log_mode 有两个选项：
-
log_mode=overwrite -
log_mode=normal：这是默认值，在数据库实例作为主要实例运行时也是必需的。使用 SAP HANA Multitarget System Replication，您必须使用log_mode=normal。检查log_mode的最佳方法是使用hdbsql：
包括错误的 覆盖 条目示例：
在这种情况下，我们有两个 global.ini 文件：
DEFAULT-
/usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
-
HOST-
/HANA/shared/${SAPSYSTEMNAME}/HDB${TINSTANCE}/${HOSTNAME}/global.iniTheHOST值覆盖DEFAULT值。您还可以在数据库启动前检查这两个文件，然后再次使用hdbsql验证正确的设置。您可以通过编辑 global.ini 文件来更改log_mode。
-
Example:
clusternode1:rh2adm> vim /hana/shared/${SAPSYSTEMNAME}/HDB${TINSTANCE}/${HOSTNAME}/global.ini
# global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver
[persistence]
log_mode = overwrite
clusternode1:rh2adm> vim /hana/shared/${SAPSYSTEMNAME}/HDB${TINSTANCE}/${HOSTNAME}/global.ini
# global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver
[persistence]
log_mode = overwriteglobal.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver [persistence] log_mode = normal
# global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver
[persistence]
log_mode = normal
检查或更新 global.ini 文件后，验证 log_mode 值：
部分还显示在 [persistence] 部分中需要设置此参数。当您将日志模式从 覆盖 改为 normal 时，建议您创建一个完整的数据备份，以确保数据库可以被恢复。
6.1.15. 发现主数据库
例如，有几种方法可以识别主节点：
-
pcs status | grep Promoted -
hdbnsutil -sr_stateConfiguration -
systemReplicationStatus.py
选项 1 - 以下 systemReplicationStatus.py 脚本示例，过滤器将返回所有节点上的主数据库位置：
clusternode1:rh2adm>
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/Python/bin/python
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py --sapcontrol=1 | egrep -e
"3${TINSTANCE}01/HOST|PRIMARY_MASTERS"| head -1 | awk -F"=" '{ print $2 }'
clusternode1:rh2adm>
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/Python/bin/python
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py --sapcontrol=1 | egrep -e
"3${TINSTANCE}01/HOST|PRIMARY_MASTERS"| head -1 | awk -F"=" '{ print $2 }'输出：
clusternode2
clusternode2
选项 2 - 以下示例以类似方法为所有节点显示 systemReplicationStatus ：
rh2adm>hdbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
rh2adm>hdbnsutil -sr_state --sapcontrol=1 | grep site.*Mode输出：
6.1.16. 接管主
请参阅 检查复制状态 部分，以检查主节点和次要节点。另外：
- 将集群设置为 maintenance-mode
- 在辅助节点上启动接管
为集群启用 maintenance-mode 的示例：
pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=true
在成为新主的二级中，以 < sidadm> 用户身份运行：
clusternode1:rh2adm> hdbnsutil -sr_takeover
clusternode1:rh2adm> hdbnsutil -sr_takeover这个二级成为主要的，其他活跃二级数据库会重新注册到新主，需要手动重新注册为次要主。
6.1.17. 重新注册以前的主主作为辅助
请确定集群停止或置于 maintenance-mode 中。Example:
clusternode2:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC2 --online --remoteName=DC3 --operationMode=logreplay --force_full_replica --online
clusternode2:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC2 --online --remoteName=DC3 --operationMode=logreplay --force_full_replica --online在我们的示例中，我们使用完整复制。需要完整复制时，您的 SAP HANA 系统管理员应知道。
6.1.18. 从故障切换中恢复
请参阅 检查 SAP HANA 系统复制状态 并发现 主要节点。信息一致非常重要。如果节点不是 systemReplicationStatus.py 输出的一部分，且具有不同的系统复制状态，如果需要重新注册此节点，请检查您的数据库管理员。
解决这种情况的一种方法是 重新注册 此站点作为新次要站点。
有时，辅助实例仍会没有启动。然后，在重新注册前取消注册此站点。取消注册二级 DC1 的示例：
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC1
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC1重新注册 DC1 的示例：
clusternode1:rh2adm> hdbnsutil -sr_register --name=DC1 --remoteHost=node2 --remoteInstance=02 --replicationMode=sync --operationMode=logreplay --online
clusternode1:rh2adm> hdbnsutil -sr_register --name=DC1 --remoteHost=node2 --remoteInstance=02 --replicationMode=sync --operationMode=logreplay --online6.2. pacemaker 命令
6.2.1. 启动和停止集群
要启动所有节点上的集群，请执行以下命令：
pcs cluster start -all
# pcs cluster start -all重启后，只有在启用该服务时，集群才会自动启动。命令有助于了解集群是否已启动，以及是否启用守护进程是否自动启动。
pcs cluster status
# pcs cluster status集群自动启动可以通过以下方式启用：
pcs cluster enable --all
# pcs cluster enable --all其他选项有：
- 停止集群。
- 将节点设置为待机。
-
将集群设置为
maintenance-mode。
如需了解更多详细信息，请检查 pcs 集群 帮助：
pcs cluster stop --all pcs cluster help
# pcs cluster stop --all
# pcs cluster help6.2.2. 将集群设置为 maintenance-mode
如果要进行更改，并且希望避免 pacemaker 集群的干扰，您可以通过将其置于 maintenance-mode 来"忽略"集群：
pcs property set maintenance-mode=true
# pcs property set maintenance-mode=true
验证 maintenance-mode 的一种简单方法是检查资源是否是非受管状态：
刷新集群资源以便在集群处于 maintenance-mode 时检测资源状态，且不更新资源状态更改：
pcs resource refresh
# pcs resource refresh
这将指示任何内容是否尚未正确，并会在不使用 maintenance-mode 时立即导致补救操作。
运行以下命令来删除 maintenance-mode ：
pcs property set maintenance-mode=false
# pcs property set maintenance-mode=false现在，集群将继续正常工作。如果配置了错误，它将现在做出反应。
6.2.3. 检查集群状态
以下是检查集群状态的几种方法：
检查集群是否正在运行：
pcs cluster status
# pcs cluster statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查集群和所有资源：
pcs status
# pcs statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查集群、所有资源和所有节点属性：
pcs status --full
# pcs status --fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow 仅检查资源：
pcs resource status --full
# pcs resource status --fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
Stonith历史记录：pcs stonith history
# pcs stonith historyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查位置限制：
pcs constraint location
# pcs constraint locationCopy to Clipboard Copied! Toggle word wrap Toggle overflow
必须配置和测试隔离。要获取尽可能自动化的解决方案，集群必须持续激活，然后让集群在重启后自动启动。在生产环境中，禁用重启允许手动干预，例如崩溃后实例的人工干预。还要检查守护进程状态。
Example:
6.2.4. 检查资源状态
使用 pcs resource 检查所有资源的状态。这会输出列表和资源的当前状态。
Example:
6.2.5. 检查资源配置
以下显示当前资源配置：
这将列出用于配置安装和配置的资源代理的所有参数。
6.2.6. SAPHana 资源选项 AUTOMATED_REGISTER=true
如果在 SAPHana 资源中使用这个选项，则 pacemaker 将自动重新注册二级数据库。
建议您在第一次测试中使用这个选项。使用 AUTOMATED_REGISTER=false 时，管理员需要手动重新注册次要节点。
6.2.7. 资源处理
管理资源有几个选项。如需更多信息，请查看帮助信息：
pcs resource help
# pcs resource help列出使用的资源代理：
pcs resource config | grep "type=" | awk -F"type=" '{ print $2 }' | sed -e "s/)//g"
# pcs resource config | grep "type=" | awk -F"type=" '{ print $2 }' | sed -e "s/)//g"输出示例：
IPaddr2 SAPHanaTopology SAPHana
IPaddr2
SAPHanaTopology
SAPHana显示特定的资源代理描述和配置参数：
pcs resource describe <resource agent>
# pcs resource describe <resource agent>示例（不带输出）：
pcs resource describe IPaddr2
# pcs resource describe IPaddr2
资源代理 IPaddr2 示例（带有输出）：
如果集群停止，则所有资源也会停止；如果集群 处于维护模式，则所有资源将保持运行，但不会受监控或管理。
6.2.8. 集群属性处理，用于 maintenance-mode
列出所有定义的属性：
要重新配置数据库，必须指示集群忽略任何更改，直到配置完成为止。您可以使用以下方法将集群 置于维护模式 ：
pcs property set maintenance-mode=true
# pcs property set maintenance-mode=true
检查 maintenance-mode ：
验证所有资源都是 "unmanaged"：
如果您取消设置 maintenance-mode，则资源将切回到受管：
pcs property set maintenance-mode=false
# pcs property set maintenance-mode=false6.2.9. 使用 Move 故障转移 SAPHana 资源
有关如何故障转移 SAP HANA 数据库的简单示例是使用 pcs resource move 命令。您需要使用克隆资源名称并移动资源，如下所示：
pcs resource move <SAPHana-clone-resource>
# pcs resource move <SAPHana-clone-resource>
在本例中，克隆资源是 SAPHana_RH2_02-clone ：
移动资源：
检查是否有剩余的限制：
pcs constraint location
# pcs constraint location您可以通过清除资源来删除在故障切换过程中创建的位置限制。Example:
pcs resource clear SAPHana_RH2_02-clone
[root@clusternode1]# pcs resource clear SAPHana_RH2_02-clone检查 "Migration Summary" 中是否存在剩余的警告或条目：
pcs status --full
# pcs status --full
检查 stonith 历史记录：
pcs stonith history
# pcs stonith history如果需要，清除 stonith 历史记录：
pcs stonith history cleanup
# pcs stonith history cleanup如果您使用早于 2.1.5 的 pacemaker 版本，请参阅 运行 pcs resource move 时是否存在管理限制的方法？ 并检查剩余的限制。
6.2.10. 监控故障切换和同步状态
所有 pacemaker 活动都记录在集群节点上的 /var/log/messages 文件中。由于还有许多其他消息，有时很难阅读与 SAP 资源代理相关的消息。您可以配置命令别名，仅过滤与 SAP 资源代理相关的消息。
别名 tmsl 示例：
alias tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_$SAPSYSTEMNAME_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
# alias tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_$SAPSYSTEMNAME_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
tsml 的输出示例：
通过过滤器，可以更轻松地了解正在发生哪些状态更改。如果缺少详细信息，您可以打开整个消息文件来读取所有信息。
故障转移后，您可以清除资源。另请检查是否有剩余位置限制。
6.2.11. 检查集群一致性
在安装过程中，资源有时会在配置最终完成前启动。这可能导致 Cluster Information Base (CIB)中的条目，这可能会导致行为不正确。这可以轻松检查，并在配置完成后手动更正。
如果您启动 SAPHana 资源，则会重新创建缺少的条目。pcs 命令无法解决错误的条目，需要手动删除。
检查 CIB 条目：
cibadmin --query
# cibadmin --queryDC3 和 SFAIL 是不应存在于 Cluster Information Base、当群集成员为 DC1 和 DC2 以及节点之间的同步状态报告为 SOK 的条目。
检查对应条目的示例：
cibadmin --query |grep '"DC3"' cibadmin --query |grep '"SFAIL"'
# cibadmin --query |grep '"DC3"'
# cibadmin --query |grep '"SFAIL"'该命令可以作为 root 用户在集群中的任何节点上执行。通常，命令的输出为空。如果配置中仍然出现错误，输出可能会类似如下：
<nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>
<nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>使用以下命令可以删除这些条目：
cibadmin --delete --xml-text '<...>'
# cibadmin --delete --xml-text '<...>'要删除上例中的条目，您必须输入以下内容：请注意，输出包含双引号，因此文本必须嵌入到单引号中：
cibadmin --delete --xml-text ' <nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>'
# cibadmin --delete --xml-text ' <nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>'验证没有删除的 CIB 条目。返回的输出应为空。
cibadmin --query |grep 'DC3"'
# cibadmin --query |grep 'DC3"'6.2.12. 集群清理
在故障转移测试过程中，可能留下在限制后，其他仍然保留在以前的测试中。在启动下一个测试前，需要从它们清除集群。
检查失败事件的集群状态：
pcs status --full
# pcs status --full如果您在 "Migration Summary" 中看到集群警告或条目，您应该清除并清理资源：
pcs resource clear SAPHana_RH2_02-clone pcs resource cleanup SAPHana_RH2_02-clone
# pcs resource clear SAPHana_RH2_02-clone
# pcs resource cleanup SAPHana_RH2_02-clone输出：
Cleaned up SAPHana_RH2_02:0 on clusternode1 Cleaned up SAPHana_RH2_02:1 on clusternode2
Cleaned up SAPHana_RH2_02:0 on clusternode1
Cleaned up SAPHana_RH2_02:1 on clusternode2检查是否有不需要的位置限制，例如来自以前的故障切换：
pcs constraint location
# pcs constraint location更详细地检查现有限制：
pcs constraint --full
# pcs constraint --full资源移动后位置约束示例：
Node: hana08 (score:-INFINITY) (role:Started) (id:cli-ban-SAPHana_RH2_02-clone-on-hana08)
Node: hana08 (score:-INFINITY) (role:Started) (id:cli-ban-SAPHana_RH2_02-clone-on-hana08)清除此位置约束：
pcs resource clear SAPHana_RH2_02-clone
# pcs resource clear SAPHana_RH2_02-clone验证约束是否已从约束列表中显示。如果保留，则使用其约束 id 显式删除它：
pcs constraint delete cli-ban-SAPHana_RH2_02-clone-on-hana08
# pcs constraint delete cli-ban-SAPHana_RH2_02-clone-on-hana08
如果您使用隔离运行多个测试，您可能也清除 stonith 历史记录：
pcs stonith history cleanup
# pcs stonith history cleanup所有 pcs 命令都是以 root 用户身份执行的。另外，请检查 发现左侧。
6.2.13. 其他集群命令
各种集群命令示例
6.3. RHEL 和常规命令
6.3.1. 发现当前状态
您必须按照以下步骤了解环境的当前状态。请参阅监控 环境。另外，我们建议您进行以下操作：
-
检查
/var/log/messages，使用 Aliases 来监控 日志以方便日志检查。 - 有时，集群必须从以前的活动中清理才能继续正常工作。发现 左侧并在需要时清除它们。
6.3.2. yum info
6.3.3. RPM 显示版本
rpm -q resource-agents-sap-hana resource-agents-sap-hana-0.162.1-2.el9_2.noarch
# rpm -q resource-agents-sap-hana
resource-agents-sap-hana-0.162.1-2.el9_2.noarch6.3.4. 监控的别名
您可以将其添加到 shell 配置集中。在示例中，根别名依赖于 < sid>adm 别名，因此还必须定义它。
root （在
~/.bashrc中添加）：Copy to Clipboard Copied! Toggle word wrap Toggle overflow <SID>adm（添加到~/.customer.sh）：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}