Automating GBase Database Pre-Installation Checks: A Practical 18-Check Bash Workflow

本文为原文前 6,000 字符的节选翻译,完整内容请查看原文。

Automating GBase Database Pre-Installation Checks: A Practical 18-Check Bash Workflow

gha_preinstall -i A 已经针对 GBase 数据库(GBase 8c)执行了 18 项预安装检查。那么,为什么还要编写自定义 Bash 脚本呢?因为官方工具虽然能识别出哪些检查项处于“异常”(Abnormal)状态,但它不会自动为您提供三台主机之间便捷的并排对比。部署中一个常见的错误是:仔细检查第一台机器,假设其他两台配置相同,然后直接进行安装。这种假设往往就是集群部署问题的开端。本教程将展示如何使用 Bash 构建一个轻量级的 GBase 数据库预安装验证工作流。它结合了本地环境检查、官方 18 项验证工具以及跨主机日志对比。该工作流分为三个步骤:收集每台主机上的环境信息;运行官方 GBase 数据库预安装检查;收集并对比所有主机的结果。

Step 1: Create a Local Environment Check Script

Start by creating a script named precheck.sh on each host. The script collects basic operating system, kernel, network, memory, resource limit, firewall, SELinux, disk, and port information.

#!/bin/bash
H=$(hostname)
OUT="/tmp/gbase8c_precheck_${H}.log"
{
  echo "== host: $H =="
  echo "-- OS --"
  head -n 2 /etc/os-release
  echo "-- kernel --"
  uname -r
  echo "-- hostname resolution --"
  getent hosts "$H"
  echo "-- swap --"
  swapon --show
  echo "-- THP --"
  cat /sys/kernel/mm/transparent_hugepage/enabled
  echo "-- scheduler --"
  cat /sys/block/sda/queue/scheduler
  echo "-- resource limits --"
  ulimit -n
  ulimit -u
  echo "-- firewall --"
  systemctl is-active firewalld
  echo "-- SELinux --"
  sestatus | head -n 1
  echo "-- disk --"
  df -h /home/gbase
  echo "-- listening ports --"
  ss -tlnp | grep -E ':(20001|2379|6666|5432|15432|15433|20010)([[:space:]]|$)' || true
} | tee "$OUT"
echo "Local check log: $OUT"

第一步:创建本地环境检查脚本

首先在每台主机上创建一个名为 precheck.sh 的脚本。该脚本用于收集基本的操作系统、内核、网络、内存、资源限制、防火墙、SELinux、磁盘和端口信息。

A few implementation details are worth noting: hostname identifies the current host in the output. getent hosts checks whether the hostname can be resolved through the configured name service. THP output helps identify differences in Transparent Huge Pages configuration. ulimit captures the current shell’s resource limits. ss identifies listening services that may conflict with planned database ports. The example uses /dev/sda and /home/gbase as deployment assumptions. Adjust these paths to match the actual storage device and installation layout.

第二步:运行官方 GBase 数据库检查

本地环境信息固然有用,但它不能替代官方验证工具。请使用相同的集群配置在每台主机上运行 gha_preinstall:

cd /home/gbase/gbase_package/script/
OUT="/tmp/gbase8c_precheck_$(hostname).log"
./gha_preinstall -i A \
-f /home/gbase/gbase.yml | tee -a "$OUT"

这会将官方 GBase 数据库预安装检查结果追加到相应的主机日志中。这种区分很重要:自定义脚本收集环境细节,而 gha_preinstall -i A 提供官方验证结果。两者结合,比单独任何一种输出都能提供更有价值的证据。

Step 3: Collect and Compare Results Across Hosts

Once precheck.sh is available on all three hosts, execute it remotely and collect the output on a central machine. For example:

mkdir -p /tmp/logs
for h in node1 node2 node3; do
  ssh "$h" "bash /tmp/precheck.sh"
  scp "$h:/tmp/gbase8c_precheck_${h}.log" \
  "/tmp/logs/${h}.log"
done

This collects the local environment logs. The official check output can also be retrieved from each host:

for h in node1 node2 node3; do
  scp "$h:/tmp/gbase8c_precheck_${h}.log" \
  "/tmp/logs/${h}.log"
done

If the logs are already collected, compare the official validation results: grep -H "Abnormal" /tmp/logs/*.log. For a more detailed comparison, review the corresponding sections in each host’s log rather than relying exclusively on the Abnormal count. The objective is to identify both individual host differences and configuration problems shared by every host.

第四步:理解两类问题

跨主机对比通常会揭示出两类不同的问题。

案例 1:单机异常(Single-Host Outlier) 例如:

主机THP 配置
node1never
node2never
node3always
只有 node3 的 THP 设置不一致。这正是工程师在检查一台机器并假设其他机器配置相同时最容易忽略的问题类型。

案例 2:集体配置错误(Collective Configuration Error) 考虑另一个例子:

主机Swap 状态
node1Enabled
node2Enabled
node3Enabled
三台主机的配置完全相同,但一致性并不自动意味着正确性。这种情况可能更危险,因为简单的差异对比(diff)显示不出任何不同。解决方案是将每台主机与部署标准进行对比,而不仅仅是与邻近主机对比。一致性和合规性是两码事,两者都必须进行验证。

Step 5: Make Environment Validation Repeatable

Automating GBase Database pre-installation checks provides two additional benefits. First: Repeatability. The same script can be reused for: Initial cluster installation, adding or replacing hosts, cluster expansion, and reinstallation after environment changes. This reduces dependence on individual engineers remembering every check. Second: Delivery Evidence. The collected logs can be attached to the deployment record. Instead of simply reporting that environment checks were completed, the delivery team can provide actual results for every host. This makes technical reviews and responsibility handovers much easier.

重要提示:脚本仅用于收集信息,而非做出部署决策

最后一点警告:自定义脚本不应自动判定环境是否符合部署条件。例如,所需的 Swap 配置和 ulimit -n 值可能取决于 GBase 数据库的部署架构、工作负载以及特定版本的具体要求。18 项官方检查提供了验证基准,但可能仍需要额外的环境检查。自动化的目的在于……