Rails 7.1.5 分片连接问题分析与解决方案

在从 Rails 6.1.7 升级到 Rails 7.1.5 后，开发者遇到了一个关于数据库分片连接的有趣问题。这个问题涉及到 Rails 7 中引入的"细粒度连接切换"功能，理解这一机制对于正确使用多数据库分片至关重要。

问题现象

开发者配置了两个数据库分片（shard_one 和 shard_two），期望通过 connected_to 方法明确指定写入操作的目标分片。然而在实际操作中，发现写入请求被路由到了错误的分片，即使明确指定了目标分片。

核心原因分析

这个问题源于 Rails 7 引入的"细粒度连接切换"（Granular Connection Switching）机制。与 Rails 6.1 不同，Rails 7 中的连接切换行为变得更加精确：

1. Rails 6.1 行为：connected_to 会全局切换所有模型的数据库连接
2. Rails 7+ 行为：connected_to 默认只切换调用该方法的模型及其子类的连接

在示例中，MyModel.connected_to 只会影响 MyModel 及其子类的连接，而不会影响其他模型（如 User 模型）的连接行为。这就是为什么 User.create! 仍然使用默认分片的原因。

解决方案

根据使用场景的不同，有两种解决方案：

方案一：全局连接切换

如果希望所有模型都切换到指定分片，应该使用 ActiveRecord::Base.connected_to：

ActiveRecord::Base.connected_to(role: :writing, shard: :shard_one) do
  puts "Current DB: #{ServeRecord.connection.current_database}"
  User.create!(name: "Test User") # 现在会正确写入 shard_one
end

方案二：模型继承关系调整

如果确实需要细粒度控制，确保相关模型都继承自同一个抽象类：

class MyModel < ServeRecord
  # ...
end

class User < ServeRecord
  # ...
end

这样 MyModel.connected_to 也会影响 User 模型的连接。

配置建议

对于大多数应用，建议采用全局连接切换方式，除非有明确的理由需要细粒度控制。同时，升级到 Rails 7+ 时，应该特别注意以下几点：

1. 检查所有 connected_to 的使用场景
2. 明确模型继承关系对连接切换的影响
3. 在测试环境中充分验证分片切换行为

总结

Rails 7 引入的细粒度连接切换机制是一项改进功能，它提供了更精确的连接控制能力。理解这一变化对于正确使用多数据库分片至关重要。开发者应该根据实际需求选择全局切换或细粒度控制，并在升级时特别注意这一行为变化。