在 SAP HANA 生产数据库中创建数据库用户

使用以下步骤在 SAP HANA 生产数据库中创建数据库用户。

1. 在 SystemDBSAP HANA 生产系统中创建数据库用户、或提供现有用户的凭据。 钩子脚本使用该数据库用户连接到生产数据库并更改配置参数。

   使用 数据库交互终端 hdbsql 或 Cockpit 登录 SystemDB 使用 SAP HANA 数据库交互终端 hdbsql 或 SAP HANA Cockpit 登录主实例，并创建一个新用户。

   例如，在终端会话中使用 hdbsql 连接数据库。

   sudo -i -u ${sid}adm -- hdbsql -i ${INSTNO} -d SYSTEMDB -u SYSTEM
   

   创建用户。

   CREATE USER HA_HOOK PASSWORD <Password> no force_first_password_change;
   

   授予用户所需的权限。

   授予 INIFILE ADMIN 权限，允许更改配置文件参数。

   GRANT INIFILE ADMIN TO HA_HOOK;
   

   验证 HA_HOOK 用户。

    sudo -i -u ${sid}adm -- hdbsql -d SYSTEMDB -u SYSTEM select \* from users where user_name = \'HA_HOOK\';
   

2. 将用户证书添加到安全用户存储 hdbuserstore。

   在两个节点上运行以下命令。 使用上一步中设置的密码。

   sudo -i -u ${sid}adm -- hdbuserstore SET HA_HOOK_KEY localhost:3${INSTNO}13 HA_HOOK <Password>
   

   检查 hdbuserstore 的更新。

   sudo -i -u ${sid}adm -- hdbuserstore list
   

   在主实例上，使用存储的用户密钥测试连接。

   sudo -i -u ${sid}adm  -- hdbsql -U HA_HOOK_KEY select \* from m_inifiles;
   

创建挂钩脚本

Python 用于创建钩子脚本的示例文件作为 安装的一部分提供。SAP HANA 样本位于 $DIR_INSTANCE/exe/python_support/hdb_ha_dr 目录中。

目标目录 /hana/shared/myHooks 已为钩子 SAPHanaSR.py 创建。 在 /hana/shared/myHooks 中创建 HA/DR 提供程序钩子。 以下钩子脚本基于 HADRdummy.py 示例。

在 NODE2 上，编辑文件 /hana/shared/myHooks/SAPHanaCostOptSR.py 并添加以下内容。

"""
Sample for a HA/DR hook provider.

When using your own code in here, please copy this file to location on /hana/shared outside the HANA installation.
This file will be overwritten with each hdbupd call! To configure your own changed version of this file, please add
to your global.ini lines similar to this:

    [ha_dr_provider_<className>]
    provider = <className>
    path = /hana/shared/haHook
    execution_order = 1


For all hooks, 0 must be returned in case of success.
"""

from __future__ import absolute_import
from hdb_ha_dr.client import HADRBase, Helper
from hdbcli import dbapi
import os, time

class SAPHanaCostOptSR(HADRBase):

    def __init__(self, *args, **kwargs):
        # delegate construction to base class
        super(SAPHanaCostOptSR, self).__init__(*args, **kwargs)

    def about(self):
        return {"provider_company" :        "SAP",
                "provider_name" :           "SAPHanaCostOptSR", # provider name = class name
                "provider_description" :    "Handle reconfiguration event for cost-optimized system replication",
                "provider_version" :        "1.0"}

    def postTakeover(self, rc, **kwargs):
        """Post takeover hook."""

        # prepared SQL statements to remove memory allocation limit and pre-load of column tables
        stmnt1 = "ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') UNSET ('memorymanager','global_allocation_limit') WITH RECONFIGURE"
        stmnt2 = "ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') UNSET ('system_replication','preload_column_tables') WITH RECONFIGURE"

        myPort = int('3' + os.environ.get('DIR_INSTANCE')[-2:] + '15')
        myKey = self.config.get("userkey") if self.config.hasKey("userkey") else "HA_HOOK_KEY"

        self.tracer.info("%s.postTakeover method called with rc=%s" % (self.__class__.__name__, rc))
        self.tracer.info("%s.postTakeover method: userkey: %s, port: %s" % (self.__class__.__name__, myKey, myPort))

        if rc in (0, 1):
            # rc == 0: normal takeover succeeded
            # rc == 1: waiting for force takeover
            conn = dbapi.connect(userkey=myKey, address='localhost', port=myPort)
            self.tracer.info("%s: Connect using userkey %s - %s" % (self.__class__.__name__, myKey, conn.isconnected()))
            cursor = conn.cursor()
            rc1 = cursor.execute(stmnt1)
            self.tracer.info("%s: (%s) - %s" % (self.__class__.__name__, stmnt1, rc1))
            rc2 = cursor.execute(stmnt2)
            self.tracer.info("%s: (%s) - %s" % (self.__class__.__name__, stmnt2, rc2))
            return 0
        elif rc == 2:
            # rc == 2: error, something went wrong
            return 0

激活成本优化挂钩

使用以下步骤激活成本优化挂钩。

1. 停止群集。

   在任何一个群集节点上，运行以下命令。

   pcs cluster stop --all
   

2. 设置钩子脚本的文件所有权。

   在 NODE2 上，运行以下命令。

   chown -R ${sid}adm:sapsys /hana/shared/myHooks
   

3. 更新 NODE2 上的 global.ini 配置文件，启用钩子脚本。

   在 NODE2 上，运行以下命令将所需参数添加到 global.ini 文件中。

   sudo -i -u ${sid}adm -- <<EOT
       python \$DIR_INSTANCE/exe/python_support/setParameter.py \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/provider=SAPHanaCostOptSR \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/path=/hana/shared/myHooks \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/userkey=HA_HOOK_KEY \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/execution_order=2 \
         -set SYSTEM/global.ini/trace/ha_dr_saphanacostoptsr=info
   EOT
   

4. 检查 global.ini 文件的内容。

   cat /hana/shared/${SID}/global/hdb/custom/config/global.ini
   

5. 验证挂钩是否起作用。

   • 在 NODE2 上重启 HANA 实例，并验证钩子脚本是否按预期运行。
   • 通过 SAP HANA 接管操作触发钩子。
   • 检查钩子是否在跟踪文件中记录了任何内容。

   sudo -i -u ${sid}adm -- \
       sh -c 'grep SAPHanaCostOptSR $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_*.trc'
   

   验证钩子功能后，就可以重新启动 HA 群集。

6. 启动 HA 群集。

   在任何一个群集节点上，运行以下命令。

   pcs cluster start --all
   

   检查群集的状态。

   pcs status --full
   

Test1- 说明

模拟在 NODE1 上运行的 HANA 主数据库实例崩溃。

Test1- 先决条件

• 用于 HANA 系统复制的功能性双节点 RHEL HA 附加集群。
• 两个群集节点都处于活动状态。
• 群集在 NODE1 和 NODE2 上启动。
• 集群资源 SAPHana_${SID}_${INSTNO} 是通过 AUTOMATED_REGISTER=false 配置的。
• 检查 SAP HANA 系统复制状态：
  • SAP HANA 主数据库运行在 NODE1 上。
  • SAP HANA 备用数据库运行在 NODE2 上。
  • HANA 系统复制已激活并保持同步。
• NODE2 上的辅助 SAP HANA 数据库在内存配置减少的情况下运行。
  • global_allocation_limit 已减少。
  • 已禁用列表预载 (preload_column_tables = false)。
• NODE2 上运行着一个非生产 SAP HANA 系统 ${SID_NP}。

Test1- 测试程序

以用户 ${sid}adm 的身份发送 SIGKILL 信号，使 SAP HANA 初级程序崩溃。

在 NODE1 上，运行以下命令。

sudo -i -u ${sid}adm -- HDB kill-9

Test1- 预期行为

• SAP HANA NODE1 上的主实例崩溃。
• 群集会检测到已停止的 HANA 主数据库，并将资源标记为 failed。
• 群集会将 NODE2 上的辅助 HANA 数据库升级为新的主数据库。
  • 群集在 NODE2 上停止非生产数据库 ${SID_NP}。
  • 激活期间，global_allocation_limit 和 preload_column_tables 参数将重置为默认值。
• 群集释放 NODE1 上的虚拟 IP 地址，并在 NODE2 上的新主 IP 地址上获取该地址。
• 如果应用程序（如 SAP NetWeaver ）连接到 SAP HANA 的租户数据库，则应用程序会自动重新连接到新的主数据库。

在 NODE2 上，运行以下命令检查 global_allocation_limit 和 preload_column_tables 是否未设置。

sudo -i -u ${sid}adm -- hdbcons "mm globallimit" | grep limit

grep -E "global_allocation_limit|preload_column_tables" \
     /hana/shared/${SID}/global/hdb/custom/config/global.ini

Test1- 恢复程序

由于群集资源 SAPHana_${SID}_${INSTNO} 是通过 AUTOMATED_REGISTER=false 配置的，因此群集不会重启故障的 HANA 数据库，也不会将其注册到新的主数据库中。 新主系统 ( NODE2 ) 的状态显示辅助系统处于 "CONNECTION TIMEOUT"（连接超时）状态。

在 NODE1 上，运行以下命令将先前的主系统注册为新的辅助系统。

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_register \
        --name=${DC1} \
        --remoteHost=${NODE2} \
        --remoteInstance=${INSTNO} \
        --replicationMode=sync \
        --operationMode=logreplay \
        --online
EOT

验证系统复制状态。

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_state
    HDBSettings.sh systemReplicationStatus.py
EOT

在 NODE1 上，运行以下命令启动群集节点。

pcs cluster start

新的辅助实例重新启动，并显示为同步状态 (SOK)。

pcs status --full

使用 AUTOMATED_REGISTER=true 配置群集资源 SAPHana_${SID}_${INSTNO}。

在 NODE1 上，运行以下命令。

pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true

pcs resource config SAPHana_${SID}_${INSTNO}

Test2- 说明

使用群集命令将主实例移回另一个节点。

Test2- 先决条件

• 用于 HANA 系统复制的功能性双节点 RHEL HA 附加集群。
• 两个群集节点都处于活动状态。
• 群集在 NODE1 和 NODE2 上启动。
• 集群资源 SAPHana_${SID}_${INSTNO} 是通过 AUTOMATED_REGISTER=true 配置的。
• 检查 SAP HANA 系统复制状态：
  • SAP HANA 主数据库运行在 NODE2 上。
  • SAP HANA 备用数据库运行在 NODE1 上。
  • HANA 系统复制已激活并保持同步。
• 非生产 SAP HANA 系统 ${SID_NP} 在 NODE2 上停止运行。

Test2- 考试准备

取消对非生产 SAP HANA 系统的群集资源的管理，以防止它在辅助系统的内存资源不受限制时启动。

在 NODE1 上，运行以下命令。

pcs resource unmanage group_${sid_np}_non_prod

Test2- 测试程序

在 NODE1 上，运行以下命令将 SAP HANA 主文件移回 NODE1。

pcs resource move SAPHana_${SID}_${INSTNO}-clone

Test2- 预期行为

• 集群会创建一个位置限制，以移动资源。
• 群集触发对 NODE1 上辅助 HANA 数据库的接管。
• 如果应用程序（如 SAP NetWeaver ）连接到 SAP HANA 的租户数据库，则应用程序会自动重新连接到新的主数据库。
• 非生产 SAP HANA 系统的资源 ${SID_NP} 处于非托管状态，不会自动启动。

Test2- 恢复程序

要重建完整的 HA 方案，需要遵循几个步骤。

1. 等待主 HANA 实例激活。 然后，减少二级程序的内存占用。

   在 NODE2 上运行以下命令来减少内存。

   export GLOBAL_ALLOCATION_LIMIT=<size_in_mb_for_hana_secondary>
   

   sudo -i -u ${sid}adm -- <<EOT
       python \$DIR_INSTANCE/exe/python_support/setParameter.py \
         -set SYSTEM/global.ini/system_replication/preload_column_tables=false \
         -set SYSTEM/global.ini/memorymanager/global_allocation_limit=$GLOBAL_ALLOCATION_LIMIT
   EOT
   

2. 移除位置限制，从而触发二级实例的启动。

   pcs resource clear SAPHana_${SID}_${INSTNO}-clone
   

   确认约束已清除。

   pcs constraint
   

   检查群组状态。

   pcs status --full
   

3. 在 NODE2 上，运行以下命令检查 global_allocation_limit 和 preload_column_tables 是否已设置。

   sudo -i -u ${sid}adm -- hdbcons "mm globallimit" | grep limit
   

   grep -E "global_allocation_limit|preload_column_tables" \
        /hana/shared/${SID}/global/hdb/custom/config/global.ini
   

4. 重新激活非生产 SAP HANA 系统的资源。

   在 NODE2 上，运行以下命令。

   pcs resource manage group_${sid_np}_non_prod
   

   管理非生产 SAP HANA 系统 ${SID_NP} 的资源，并在 NODE2 上启动非生产系统。

   pcs status --full
   

Test3- 说明

模拟运行主 HANA 数据库的节点崩溃。

Test3- 先决条件

• 用于 HANA 系统复制的功能性双节点 RHEL HA 附加集群。
• 两个群集节点都处于活动状态。
• 群集在 NODE1 和 NODE2 上启动。
• 集群资源 SAPHana_${SID}_${INSTNO} 是通过 AUTOMATED_REGISTER=true 配置的。
• 检查 SAP HANA 系统复制状态：
  • SAP HANA 主数据库运行在 NODE1 上。
  • SAP HANA 备用数据库运行在 NODE2 上。
  • HANA 系统复制已激活并保持同步。
• NODE2 上的辅助 SAP HANA 数据库在内存配置减少的情况下运行。
  • global_allocation_limit 已减少。
  • 已禁用列表预载 (preload_column_tables = false)。
• NODE2 上运行着一个非生产 SAP HANA 系统 ${SID_NP}。

Test3- 测试程序

通过发送崩溃系统请求，在 NODE1 上崩溃主系统。

在 NODE1 上，运行以下命令。

sync; echo c > /proc/sysrq-trigger

Test3- 预期行为

• NODE1 关闭。
• 群集检测到故障节点，并将其状态设置为 OFFLINE。
• 群集会将 NODE2 上的辅助 HANA 数据库升级为新的主数据库。
  • 群集在 NODE2 上停止非生产数据库 ${SID_NP}。
  • 在激活过程中，global_allocation_limit 和 preload_column_tables SAP HANA ${SID} 的参数会被重置。
• 群集通过 NODE2 获取新主服务器上的虚拟 IP 地址。
• 如果应用程序（如 SAP NetWeaver ）连接到 SAP HANA 的租户数据库，则应用程序会自动重新连接到新的主数据库。

Test3- 恢复程序

登录 IBM Cloud® 控制台并启动 NODE1。 等待 NODE1 再次可用，然后重启群集框架。

在 NODE1 上，运行以下命令。

pcs cluster start

pcs status --full

由于群集资源 SAPHana_${SID}_${INSTNO} 是与 AUTOMATED_REGISTER=true 一起配置的，因此，当 NODE1 加入群集时，SAP HANA 会重新启动，并且前主服务器会注册为辅助服务器。

然后，重新运行 Test2- Test the manual move of SAPHana resource to another node 中的步骤 中的步骤，以恢复到初始状态。

Test4- 说明

模拟 HANA 备用数据库崩溃。

Test4- 先决条件

• 用于 HANA 系统复制的功能性双节点 RHEL HA 附加集群。
• 两个节点都已激活。
• 群集在 NODE1 和 NODE2 上启动。
• 集群资源 SAPHana_${SID}_${INSTNO} 是通过 AUTOMATED_REGISTER=true 配置的。
• 检查 SAP HANA 系统复制状态：
  • SAP HANA 主数据库运行在 NODE1 上。
  • SAP HANA 备用数据库运行在 NODE2 上。
  • HANA 系统复制已激活并同步。

Test4- 测试程序

以用户 ${sid}adm 的身份发送 SIGKILL 信号，使 SAP HANA 二级程序崩溃。

在 NODE2 上，运行以下命令。

sudo -i -u ${sid}adm -- HDB kill-9

Test4- 预期行为

• SAP HANA NODE2 上的二级碰撞。
• 群集会检测到已停止的二级 HANA 数据库，并将资源标记为 failed。
• 群集重新启动辅助 HANA 数据库。
• 群集检测到系统复制再次同步。

Test4- 恢复程序

等待辅助 HANA 实例启动并再次同步 (SOK)，然后清理失败的资源操作，如 pcs status 所示。

在 NODE2 上，运行以下命令。

pcs resource refresh SAPHana_${SID}_${INSTNO}

pcs status --full