Docker部署Artifactory 5.6.2关联PostgreSQL 9.6.6-alpine故障求助

先理清楚咱们当前的核心困境：PostgreSQL先是CPU跑满、重启失败，恢复备份后数据库能启动，但Artifactory卡在和数据库交互的环节。下面一步步来拆解问题、找解决办法：

1. 先确认恢复后的PostgreSQL状态真的正常 #

别光看容器启动了就觉得没问题，得深入验证下数据库本身的健康度：

• 进入PostgreSQL容器，执行psql -U <你的Artifactory数据库用户名> -d <对应的数据库名>，连接上后跑几个命令：
  • SELECT 1; 先验证基本连接是否通畅
  • SELECT count(*) FROM pg_stat_activity; 看看有没有大量阻塞的连接或者异常会话
  • SELECT pg_database_size('<数据库名>'); 对比下这个大小和备份文件的大小，确保恢复完整了
• 再看看PostgreSQL的日志，要么进容器看/var/log/postgresql/postgresql-9.6-main.log，要么直接跑docker logs <postgres容器名>，搜搜有没有ERROR或者FATAL级别的报错——比如恢复时数据不一致、权限不对这类问题都可能藏在这里。

2. 核对Artifactory的数据库连接配置 #

Artifactory的数据库配置文件在容器里一般是/var/opt/jfrog/artifactory/etc/db.properties，得仔细检查这些项：

• 数据库URL、用户名、密码是不是都对，比如正确的格式应该是这样：

  db.type=postgresql
  db.url=jdbc:postgresql://<postgres容器IP或容器名>:5432/<数据库名>
  db.username=artifactory
  db.password=你的数据库密码
  

• 要是Docker容器之间用容器名通信，得确保两个容器在同一个Docker网络里，不然Artifactory连不上PostgreSQL，自然会卡住。

3. 盯着Artifactory的启动日志找线索 #

跑docker logs <artifactory容器名>，看看卡在交互阶段的时候日志具体说了啥：

• 如果日志一直在刷Waiting for database connection或者连接超时的信息，那大概率是网络不通、数据库权限没开，或者密码错了
• 如果日志里有表不存在、数据校验失败这类报错，那可能是备份的时候数据库没完全停稳，导致备份文件损坏了，恢复后数据不一致。

4. 顺便解决之前PostgreSQL CPU跑满的问题（避免再踩坑） #

之前PostgreSQL占满CPU，大概率是配置不够或者查询没优化：

• 调一下PostgreSQL的内存参数：找到容器里的postgresql.conf，把shared_buffers改成宿主机内存的1/4（比如宿主机8G内存就设成2G），再适当调高work_mem和maintenance_work_mem，让数据库能用更多内存减少磁盘IO
• 开个pg_stat_statements扩展，看看哪些查询最耗时——Artifactory 5.x有些版本确实有查询效率问题，找到慢查询后可以针对性优化（比如加索引，或者升级Artifactory版本）
• 跑一遍ANALYZE <数据库名>;更新数据库统计信息，让PostgreSQL能生成更高效的执行计划

5. 校验备份恢复的数据一致性 #

如果数据库能启动，但Artifactory还是卡，可能是备份方式不对：

• 别直接复制数据库文件夹备份，试试用Artifactory自带的导出工具：$ARTIFACTORY_HOME/bin/artifactory.sh export，导出后再用导入工具恢复，这样能保证数据和Artifactory的兼容性
• 检查数据库文件夹的权限：恢复后，PostgreSQL容器里的/var/lib/postgresql/data文件夹权限得是postgres:postgres，不然数据库读写数据会出问题，Artifactory自然连不上。

6. 应急方案：先确认Artifactory本身没问题 #

要是以上步骤都没搞定，可以先临时切换到Artifactory内置的H2数据库启动，看看Artifactory本身能不能正常跑——如果能，那问题肯定出在PostgreSQL那边，再集中精力排查数据库；如果还是卡，那就是Artifactory本身有问题，得检查它的配置或者镜像是否损坏。

内容的提问来源于stack exchange，提问作者Robert Lachner