根据你描述的场景——Ruby on Rails企业应用，多团队多环境部署，用docker-compose迁移基础设施后运行正常但重启触发连接池满，移除部分容器或配置就恢复——我来拆解下可能的原因和对应的解决办法：

1. 核心原因：总数据库连接数超过上限 #

首先要明确一个关键公式：总活跃连接数 = 容器数量 × Rails连接池大小。数据库（比如PostgreSQL默认max_connections是100）有最大连接数限制，重启阶段旧容器的连接没及时释放，新容器又建立新连接，瞬间的连接峰值就会触发connection pool full错误。

解决步骤： #

• 计算合适的连接池大小：
  先查数据库的最大连接数，比如PostgreSQL执行：

  SHOW max_connections;
  

  假设结果是100，预留20个连接给管理员、监控等非应用服务，你有20个Rails容器，那每个容器的连接池应该设为(100-20)/20 = 4。
• 调整Rails配置：
  在config/database.yml里直接指定pool值，或者通过环境变量RAILS_MAX_THREADS（Rails默认连接池大小等于这个值）来统一配置，比如在docker-compose.yml里给每个服务添加：

  environment:
    - RAILS_MAX_THREADS=4
  

2. 容器重启时的连接泄漏问题 #

旧容器在重启过程中没有优雅关闭数据库连接，导致数据库端保留了大量无效的闲置连接，挤占了可用连接数。

解决步骤： #

• 确保Rails优雅退出：
  在docker-compose.yml的Rails服务里指定stop_signal: SIGTERM（默认就是，但可以明确配置），让Puma/Unicorn有时间处理关闭逻辑。
  同时在config/puma.rb里添加 shutdown钩子，主动释放连接池：

  on_worker_shutdown do
    ActiveRecord::Base.connection_pool.disconnect!
  end
  

• 配置数据库自动回收闲置连接：
  以PostgreSQL为例，设置idle_in_transaction_session_timeout为30秒，自动回收长时间闲置的连接：

  ALTER SYSTEM SET idle_in_transaction_session_timeout = '30s';
  SELECT pg_reload_conf();
  

3. 多环境的连接数叠加问题 #

你提到移除1套完整配置后恢复，说明每套环境的连接数叠加后超出了数据库承载上限。

解决步骤： #

• 隔离多环境资源：如果条件允许，给每个团队的环境分配独立的数据库实例或者逻辑数据库，避免跨环境的连接数竞争。
• 按环境调整容器数和连接池：比如限制每套环境的容器数量，或者降低单环境内的连接池大小，确保所有环境的总连接数不超过数据库max_connections。

4. Docker-compose重启策略的优化 #

默认的docker-compose up --force-recreate会先启动新容器，再停止旧容器，导致新旧容器同时占用连接，瞬间拉高连接数。

解决步骤： #

• 先停再启：用docker-compose down && docker-compose up -d替代直接force-recreate，确保旧容器完全停止并释放连接后，再启动新容器。
• 分批次重启：如果不能一次性停止所有容器，可以分批次重启，比如每次重启1/5的容器，避免连接数瞬间峰值。

验证方法 #

• 重启前执行数据库连接数查询，对比重启过程中的峰值：

  SELECT count(*) FROM pg_stat_activity WHERE state != 'idle';
  

• 进入任意Rails容器，验证当前连接池大小：

  docker exec -it <container-name> rails runner "puts ActiveRecord::Base.connection.pool.size"
  

内容的提问来源于stack exchange，提问作者Ryan Condron