瀚高数据库卸载后端口占用问题分析与解决

1. 问题现象与初步排查

最近在测试环境清理一台旧服务器时，遇到了一个棘手的问题：卸载瀚高安全版数据库V4.5.10后，发现6666端口仍然被占用。通过netstat -tunlp命令检查，发现是一个名为db_ha的agent进程在持续运行。这个现象在数据库运维中并不罕见，但背后的原因和解决方案值得深入探讨。

提示：数据库卸载后残留进程的问题，往往与服务的注册机制、守护进程设计有关，需要从系统服务和进程管理两个维度进行排查。

首先确认了基本环境信息：

• 操作系统：CentOS 7.9
• 数据库版本：瀚高安全版V4.5.10
• 问题表现：卸载后ps -ef | grep highgo无结果，但db_ha进程仍在运行
• 端口占用：lsof -i :6666显示该端口被/opt/HighGo/db_ha/bin/db_ha进程占用

2. 进程残留的深层原因分析

2.1 瀚高数据库的HA架构设计

瀚高安全版的HA（High Availability）模块采用独立agent设计，db_ha进程主要负责：

• 集群节点状态监控
• 自动故障转移
• VIP漂移管理
• 健康检查服务

与主数据库服务不同，这个agent被设计为系统级守护进程，导致其在数据库卸载时可能不会被自动清理。这种设计常见于需要独立于数据库实例运行的高可用方案。

2.2 卸载脚本的执行逻辑缺陷

通过分析瀚高安全版的卸载脚本uninstall.sh，发现以下问题点：

1. 仅清理了highgo相关服务
2. 未处理systemd或init.d中注册的db_ha服务
3. 未删除/etc/init.d/db_ha启动脚本
4. 残留了/opt/HighGo/db_ha完整目录

bash复制# 检查服务注册情况的命令示例
systemctl list-unit-files | grep -i highgo
ls -l /etc/init.d/ | grep db_ha

2.3 端口占用的连锁反应

6666端口是db_ha的默认通信端口，被占用会导致：

• 新安装的瀚高数据库HA功能无法启动
• 端口冲突引发服务异常
• 集群管理功能失效

3. 完整清理方案与实操步骤

3.1 安全终止残留进程

首先需要正确停止db_ha进程，避免直接kill导致锁文件残留：

bash复制# 优雅停止服务（如果服务脚本仍存在）
/etc/init.d/db_ha stop

# 强制终止方案（当服务脚本已丢失）
pkill -9 db_ha
rm -f /var/run/db_ha.pid  # 清理PID文件

3.2 彻底清理安装残留

执行以下清理清单：

bash复制# 1. 删除安装目录
rm -rf /opt/HighGo/db_ha

# 2. 清理服务注册
systemctl disable db_ha 2>/dev/null
rm -f /etc/systemd/system/db_ha.service
rm -f /etc/init.d/db_ha

# 3. 删除环境变量
sed -i '/HIGHGO_HOME/d' /etc/profile
sed -i '/db_ha/d' /etc/profile

# 4. 清理临时文件
rm -rf /tmp/.db_ha_*

3.3 端口占用验证

完成清理后需要确认端口释放：

bash复制# 验证端口释放
ss -tulnp | grep 6666

# 验证进程终止
ps -ef | grep db_ha | grep -v grep

4. 预防措施与最佳实践

4.1 标准卸载流程增强

建议瀚高数据库卸载时增加以下步骤：

1. 提前停止所有相关服务：

   bash复制systemctl stop highgo
   /etc/init.d/db_ha stop
   

2. 使用官方卸载脚本后，手动检查：

   bash复制# 检查清单
   echo "待检查项："
   echo "1. 进程检查: $(ps -ef | grep -e highgo -e db_ha | wc -l)"
   echo "2. 端口检查: $(netstat -tunlp | grep -e 5866 -e 6666 | wc -l)"
   echo "3. 目录检查: $(ls -d /opt/HighGo* 2>/dev/null | wc -l)"
   

4.2 部署前的防护建议

1. 使用容器化部署隔离环境
2. 在测试环境验证卸载流程
3. 记录安装时的所有修改项：

   bash复制# 安装前快照
   rpm -qa > before_install.txt
   ls /etc/init.d/ > initd_before.txt
   

4.3 监控脚本示例

可以部署以下监控脚本定期检查：

bash复制#!/bin/bash
# 监控瀚高残留进程
CHECK_ITEMS=(
  "/opt/HighGo/db_ha"
  "db_ha"
  "6666"
)

for item in "${CHECK_ITEMS[@]}"; do
  if [[ $item =~ ^/ ]]; then
    # 目录检查
    [ -e "$item" ] && echo "[WARN] 残留目录: $item"
  elif [[ $item =~ ^[0-9]+$ ]]; then
    # 端口检查
    netstat -tunlp | grep -q ":$item " && echo "[WARN] 端口占用: $item"
  else
    # 进程检查
    pgrep -x "$item" >/dev/null && echo "[WARN] 残留进程: $item"
  fi
done

5. 疑难问题排查指南

5.1 特殊情况处理

场景1：文件被锁定无法删除

bash复制# 检查文件锁
lsof /opt/HighGo/db_ha/bin/db_ha

# 强制解除锁定
fuser -km /opt/HighGo/db_ha

场景2：SELinux导致权限问题

bash复制# 检查安全上下文
ls -Z /opt/HighGo/db_ha

# 临时禁用SELinux
setenforce 0

5.2 日志分析要点

关键日志位置：

• /var/log/db_ha.log
• /var/log/messages中搜索db_ha
• journalctl -u db_ha（systemd系统）

典型错误模式：

code复制ERROR: bind port 6666 failed (Address already in use)
WARNING: db_ha process already running

5.3 系统级清理检查表

完成所有操作后，建议核查以下项目：

6. 技术原理深度解析

6.1 db_ha进程的工作机制

db_ha作为独立守护进程，其持久化运行依赖以下机制：

1. 双进程守护：通过父进程监控子进程实现自动重启
2. 心跳检测：定期向共享内存写入状态信息
3. 锁文件机制：/var/lock/subsys/db_ha防止多实例启动

c复制// 典型守护进程代码结构
int main() {
    daemonize();  // 守护进程化
    init_shared_mem();  // 初始化共享内存
    start_heartbeat();  // 启动心跳线程
    event_loop();       // 主事件循环
}

6.2 端口绑定的底层原理

6666端口被占用的根本原因是：

1. TCP套接字未正确关闭
2. 处于TIME_WAIT状态
3. SO_REUSEADDR参数未设置

可以通过以下命令检查详细状态：

bash复制ss -ton state time-wait sport = :6666

6.3 服务注册的残留痕迹

瀚高安全版在系统中可能留下的痕迹包括：

1. systemd单元：

   • /usr/lib/systemd/system/db_ha.service
   • /etc/systemd/system/multi-user.target.wants/db_ha.service

2. init.d脚本：

   • /etc/init.d/db_ha
   • /etc/rc*.d/S99db_ha

3. 环境配置：

   • /etc/profile.d/highgo.sh
   • ~/.bashrc中的环境变量

7. 经验总结与操作禁忌

在实际处理过程中，有几点重要经验值得分享：

1. 绝对禁止直接rm -rf：

   • 必须先停止进程再删除文件
   • 否则可能导致文件描述符泄漏

2. systemd服务清理顺序：

   bash复制systemctl stop db_ha
   systemctl disable db_ha
   rm -f /etc/systemd/system/db_ha.service
   systemctl daemon-reload
   

3. 环境变量清理陷阱：

   • 不仅要检查/etc/profile
   • 还要查看~/.bashrc和/etc/profile.d/

4. 日志文件常被忽略：

   bash复制# 常见的日志残留位置
   /var/log/highgo/
   /var/log/db_ha*
   /tmp/db_ha_*.log
   

遇到类似问题时，建议按照以下流程操作：

1. 确认问题现象（端口占用、进程残留）
2. 追溯相关组件（通过进程名、端口号定位）
3. 检查服务注册情况（systemd/init.d）
4. 执行完整清理（停止→删除→验证）
5. 记录操作过程（便于后续审计）