瀚高数据库卸载后端口占用问题解决方案

1. 问题现象与背景解析

最近在给客户部署瀚高数据库安全版V4.5.10时遇到一个典型问题：正常卸载数据库后，发现6666端口仍然被占用，通过netstat -ano检查发现是db_ha的agent进程残留导致的。这种情况在国产数据库运维中其实并不少见，特别是当数据库带有高可用组件时，卸载流程往往比常规数据库更复杂。

瀚高数据库作为国产数据库的代表产品之一，其安全版集成了db_ha高可用组件，这个组件会独立运行agent进程监听6666端口用于集群通信。标准卸载流程有时无法完全清理这些附属组件，导致端口占用问题影响后续安装。我在多个项目现场都遇到过类似案例，下面就把完整的排查和解决方案梳理出来。

提示：数据库卸载后端口占用问题可能引发后续安装失败、服务冲突等连锁反应，建议在维护窗口期彻底处理

2. 问题根因深度分析

2.1 db_ha组件的工作机制

瀚高安全版的db_ha是一个独立的高可用管理模块，其架构设计上有以下特点：

1. 采用主从agent模式，每个节点都会启动db_ha_agent进程
2. 默认绑定6666端口用于节点间心跳检测和元数据同步
3. 以系统服务形式注册，但部分版本存在服务注册不完整的情况

2.2 卸载残留的具体原因

通过分析安装日志和脚本，发现导致残留的典型场景包括：

1. 卸载脚本未正确处理附属服务（特别是非root用户安装时）
2. 存在未退出的数据库连接导致卸载流程中断
3. 自定义安装路径后卸载脚本路径检测失效
4. 安全策略限制导致部分文件删除失败

3. 完整解决方案

3.1 标准清理流程

建议按照以下步骤操作：

bash复制# 1. 检查残留进程
ps -ef | grep db_ha
netstat -tunlp | grep 6666

# 2. 停止服务（如果仍能运行）
systemctl stop db_ha_agent
$HG_BASE/ha/db_ha/bin/db_ha_ctl stop

# 3. 强制终止进程
kill -9 <PID>

# 4. 清理安装残留
rm -rf /opt/HighGo/ha  # 默认安装路径
rm -rf /etc/systemd/system/db_ha_agent.service
rm -rf /tmp/.db_ha_lock

# 5. 删除用户和组
userdel dbha
groupdel dbha

# 6. 清理crontab任务
crontab -l | grep -v db_ha | crontab -

3.2 特殊情况处理

当遇到顽固性残留时，需要额外处理：

1. 检查/var/run目录下的pid文件
2. 清理共享内存段：

   bash复制ipcs -m | grep dbha | awk '{print $2}' | xargs -I {} ipcrm -m {}
   

3. 检查selinux策略：

   bash复制semanage port -l | grep 6666
   semanage port -d -t highgo_port_t -p tcp 6666
   

4. 预防措施与最佳实践

4.1 安全卸载操作指南

1. 卸载前必须：

   • 断开所有应用连接
   • 备份重要数据
   • 记录当前配置参数

2. 推荐卸载步骤：

   bash复制# 1. 停止主服务
   systemctl stop highgodb
   
   # 2. 停止所有附属组件
   systemctl stop db_ha_agent
   systemctl stop hg_backup
   
   # 3. 执行官方卸载
   $HG_BASE/uninstall.sh --mode=full
   
   # 4. 手动检查清理
   

4.2 安装前的环境检查清单

为避免历史残留影响新安装，建议部署前执行：

1. 端口扫描：

   bash复制nmap -sT -p 5866,6666,9999 localhost
   

2. 用户组检查：

   bash复制getent passwd | grep -E 'highgo|dbha'
   

3. 文件系统检查：

   bash复制find / -name "*highgo*" -o -name "*db_ha*"
   

5. 典型问题排查实录

5.1 案例1：服务注册异常

现象：卸载后仍能通过systemctl启动残留服务
解决方法：

bash复制systemctl disable db_ha_agent
rm -f /usr/lib/systemd/system/db_ha_agent.service
systemctl daemon-reload

5.2 案例2：文件锁残留

现象：报错"Lock file exists"
解决方法：

bash复制lsof /tmp/.db_ha_lock
rm -f /tmp/.db_ha_lock

5.3 案例3：环境变量干扰

现象：卸载脚本报路径错误
解决方法：

bash复制unset HG_BASE
unset HG_HOME
./uninstall.sh --force

6. 深入技术细节

6.1 db_ha组件架构解析

该组件包含三个核心模块：

1. Agent进程：负责节点状态监测
2. Watchdog：保障进程高可用
   3.仲裁服务：处理脑裂场景

6.2 端口绑定机制

6666端口通过SO_REUSEADDR参数实现快速重启绑定：

c复制setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse))
bind(sockfd, (struct sockaddr*)&addr, sizeof(addr))

这种设计导致即使进程异常退出，端口也可能处于TIME_WAIT状态。

7. 运维工具开发建议

对于频繁部署的场景，可以编写自动化检查脚本：

python复制#!/usr/bin/env python3
import psutil
import socket

def check_port(port):
    with socket.socket() as s:
        return s.connect_ex(('localhost', port)) == 0

def kill_process(name):
    for proc in psutil.process_iter(['name']):
        if proc.info['name'] == name:
            proc.kill()

if check_port(6666):
    kill_process('db_ha_agent')
    print("[Clean] Killed residual process")
else:
    print("[OK] No port conflict detected")

这个脚本可以集成到自动化部署流程中，在安装前自动清理环境。