企业官网建设流程全解析

场景一：HANA资源故障，发生自动故障转移

1. 现象 ：监控告警“HANA资源失败”， crm_mon 显示资源状态 FAILED ，随后可能触发转移。
2. 排查步骤 ：
◦ 查看集群日志 ： journalctl -u pacemaker -f 或 tail -f /var/log/messages ，寻找Pacemaker关于该资源操作（monitor, start, stop）的错误信息。
◦ 查看资源代理日志 ：HANA RA的日志通常在 /var/log/messages 中，搜索 SAPHana 或 ra 关键词。错误信息可能指向具体的 hdbsql 命令执行失败。
◦ 手动测试资源代理 ：在故障节点上，切换到 <sid>adm 用户，尝试手动执行资源代理的监控或启动脚本（位于 /usr/lib/ocf/resource.d/suse/SAPHana ），观察具体报错。常见原因包括：HANA实例进程异常退出、 /hana/shared 目录权限问题、网络端口冲突、存储挂载点丢失。
◦ 检查HANA自身 ：登录HANA数据库（如果还能登录），检查 ALERT 日志，使用 HANA_Studio 或 hdbsql 查看系统状态视图（ M_SYSTEM_REPLICATION_STATUS , M_SERVICE_STATUS ）。

场景二：节点被STONITH，但业务未成功切换

1. 现象 ：一个节点被意外重启或关机，但备用节点上的HANA服务未能成功启动为主节点。
2. 排查步骤 ：
◦ 检查STONITH日志 ：在幸存节点查看 /var/log/messages ，确认STONITH动作是否成功执行及其原因。是心跳丢失？还是资源监控失败？
◦ 检查备节点接管流程 ：在备节点查看集群日志，看Pacemaker是否尝试启动 SAPHana 资源为 Master 。失败原因可能是：共享存储挂载失败（多路径问题、LUN未对备节点可见）、HANA数据目录文件系统损坏、系统复制关系未就绪（需要手动执行 hdbnsutil -sr_register ）。
◦ 检查脑裂策略 ：确认 DUPLICATE_PRIMARY_TIMEOUT 设置是否合理。如果原主节点很快恢复，可能因超时未到而阻止了备节点成为主节点。

场景三：系统复制状态异常（滞后或断开）

1. 现象 ： systemReplicationStatus.py 显示 REPLICATION_STATUS 为 ERROR 或 INITIALIZING ，或者 SECONDARY_APPLICATION_DELAY 持续增长。
2. 排查步骤 ：
◦ 检查网络 ：使用 ping 和 tcpping 检查主备节点间用于复制的端口（3 <instance> 01, 3 <instance> 03, 3 <instance> 40）的连通性和延迟。高延迟或丢包是复制滞后的首要原因。
◦ 检查备节点日志重放服务 ：在备节点，检查 nameserver 和 indexserver 的跟踪文件（trace），看是否有错误。使用 hdbsql 检查 M_LOG_REPLAY_STATUS 视图。
◦ 检查主节点日志发送 ：在主节点，检查 logreplay 服务的状态和网络发送情况。
◦ 检查存储性能 ：如果备节点日志卷（ /hana/log ）IO性能不足，会导致重放速度跟不上接收速度，造成延迟累积。使用 iostat -x 1 观察磁盘利用率和服务时间。