Rails5.2迁6.0后AWS实例偶发ActiveRecord::ConnectionNotEstablished错误求助

从报错栈、监控现象、升级前后的环境差异来看，这个问题和Aurora版本、RDS配置完全无关，是Rails 6相比5.2版本在数据库连接池生命周期管理上的底层逻辑变更导致的：

• Rails 6默认开启连接池回收机制，当应用进程长时间没有活跃请求时，不是仅回收池内的空闲单连接，而是会销毁整个primary连接池、主动关闭所有持有到数据库的连接，这也是在RDS监控上看到连接数大幅骤降的直接原因。
• 本地开发环境从来复现不了，是因为开发模式下一直有热重载、调试请求、控制台操作，永远进不到「长时间无活动请求」的空闲状态，自然不会触发连接池全量销毁的逻辑。
• 报错刚好触发在自定义健康检查逻辑上，是因为这个中间件的执行时机早于Rails核心的连接池初始化逻辑：Rails默认的ActiveRecord::ConnectionAdapters::ConnectionManagement中间件本来会在每个请求进入时先初始化当前线程对应的连接池，但健康检查挂在Rack URLMap的最外层，在核心初始化逻辑跑完之前就直接调用AR的迁移版本查询接口，一旦赶上连接池刚被回收销毁，就会直接抛出「未找到primary连接池」的错误。

优先级1：快速止血调整 #

• 修改自定义健康检查的数据库查询逻辑，不要直接裸调ActiveRecord::Migration.current_version，在查询前先主动强制初始化连接池，避免在未初始化的状态下直接拿连接：

  # 替换原有的查询逻辑
  ActiveRecord::Base.establish_connection # 强制重建当前环境的primary连接池
  current_migration_version = ActiveRecord::Migration.current_version
  

• 调整Rack中间件加载顺序，把自定义健康检查中间件移动到ActiveRecord::ConnectionAdapters::ConnectionManagement之后，让Rails核心先完成连接池初始化，再执行业务逻辑的数据库查询。

优先级2：调整连接池回收策略 #

如果你的RDS连接容量足够，不需要应用空闲时就主动断开所有数据库连接，可以在生产环境配置中调整回收逻辑：

# config/environments/production.rb
# 直接关闭过于激进的连接池全量回收
config.active_record.connection_reaping = false
# 或者把回收频率调低到30分钟，避免频繁触发连接销毁
config.active_record.reaping_frequency = 1800

注意：如果关闭全量回收，需要把应用配置的最大连接数和RDS实例的最大连接上限做匹配，避免长期不回收导致数据库连接被打满。

优先级3：适配Thin+EventMachine的运行模式 #

当前使用的Thin服务器是基于EventMachine的动态线程池处理请求，Rails 6的连接池是和工作线程强绑定的：

• 当请求被分配到一个从未初始化过连接池的新工作线程时，如果刚好赶上连接池全局回收，就会触发找不到连接池的错误。
• 可以把Thin的工作线程池固定为单线程处理所有请求，或者在服务启动时预先给所有工作线程初始化好连接池，避免懒加载带来的时序问题。

之前做的Aurora 5.6升5.7的操作和这个问题完全无关——这个问题的触发是应用层Rails的连接池生命周期逻辑变更，从连接销毁的动作开始就不会和数据库侧产生交互，自然升级数据库版本不会有任何效果。

内容的提问来源于stack exchange，提问作者Shumnan Sun