如果 TiDB 可以满足需求，最后要切换过去，那么现在做得分库可能是不必要了，甚至成为迁移的阻碍。

不如压测一下 TiDB 行不行，可以的话直接切过去。

声明：我没用过 TiDB。

原因就是一个两年前已经发现有隐患的主键上限、Rails 框架作为默认值修复的问题，Basecamp 团队自己却没有做数据迁移，DHH 责无旁贷。

Basecamp 一宕机趁机把对 Rails 的新仇旧恨抛出来的也是搞笑。

我想起这个演讲：

RailsConf 2018: Keynote: The Future of Rails 6: Scalable by Default by Eileen Uchitelle

演讲者 Eileen Uchitelle 正在把 GitHub 的技术逐步提交到 Rails。最后五分钟是重点。

如果觉得自己的方案比 Rails 社区的好多了，为什么不拿出来分享甚至向上游提交补丁？

顺着楼主思路回答就是添加配置：

config.active_job.queue_adapter = ActiveJob::QueueAdapters::AsyncAdapter.new(
  min_threads: 1,
  max_threads: 1
)

X-Y Problem http://coolshell.cn/articles/10804.html

1. 问题描述不清楚，看提问的智慧。
2. 为什么不应该使用 rvm/rbenv，以及替代方案。

想到 DHH 这段演讲 6:19 开始

分库真的是必须的吗？我接触过最大一个表 1 亿数据也没有分库，索引合理数据库能撑住。

看顶楼已经用了 TiDB 了，不考虑全用 TiDB，让它解决扩展问题？

现在看起来代码没问题，还有问题吗？

自动生成是不会漏的，除非你删了什么。

我二楼已经叫你上传代码了，一定是漏了东西，关掉 CRSF 和 8 楼的操作都不是解决方法。

新手遇到这个问题最常见的原因：

1. app/views/layouts/application.html.erb 里面误删了 <%= csrf_meta_tags %> 。
2. app/assets/javascripts/application.js 里面误删了 // require rails-ujs 。
3. 其它具体分析，但可能性已经很小。

楼主搜到一个“方案”不去了解原理就认为“解决了”，不是好的学习习惯。

引申阅读：

Ruby on Rails 安全指南 / 3 跨站请求伪造（CSRF） https://ruby-china.github.io/rails-guides/security.html#cross-site-request-forgery-csrf

你没有理解 heroku 的运作原理，heroku 应用运行在叫做 dynos 的容器里面，不同于一般的 Linux server，为了安全肯定做了一些限制。就算用 heroku run shell 成功安装了某个包，因为它是单独开启的容器，里面的修改也不能用于其它服务进程。

如果你需要修改 heroku 容器，需要了解它的 Builde pack 机制。

不过还有更好的选择，就是通过 docker 镜像部署。

把代码放到 github，一定是漏了东西。一楼的设置是关掉安全防护，不安全。

把查询对象存到外部再读回来？听起来很有问题，数据交互应该尽可能用简单的对象。

用着 dotenv

开发环境的 docker 只打包系统依赖，例如 libpg-dev，nodejs 这些，项目文件是通过 volumes mount 进去的。Rails 的 auto reload 和 webpacker 的 live reload 都能正常用。

我开发环境用 docker 的目的是为了让开发环境和生产环境等价。曾经试过开发环境用了新版本的 redis 和新命令，上线之后才发现不支持而崩溃。

我把大部分配置都放到了环境变量里，不过还有有一些行为是硬编码不可配置的，例如 rails db 下的命令，开发环境执行的同时会对 test db 也执行一遍，所以我做了折衷，Rails 默认行为不去改它，新增的配置遵循 12factor。只改配置，不区分 staging 和 production 环境。

Heroku 节省了一个运维团队啊，对小公司绝对是省钱，如果没有运维团队那其实是开发在付出时间成本。

单机部署风险太大，不同地方都见过单机部署服务器崩溃，然后备份没工作的事故了。

上面的意思是持久化服务不要放 k8s 里面，因为要做得对很难。

👏👏👏

不发帖都没留意呢。

docker compose 只适合用来搭开发环境，生产环境需要 k8s 之类的编排工具，然后对于需要持久化的服务要有特殊处理，最好用云服务。

用 docker compose。

cached 是主机到容器单向同步，会不会导致每次重启 node_modules 都要重装？而且据文档介绍同步有延迟。

volumn 慢用 http://docker-sync.io/ 解决。

解决了 volumn 慢的问题，开发环境我觉得没啥坑了。生产环境比较折腾，除非用 Heroku。

以前发过的一个技巧在这里汇总一下。

如果使用 docker，可以在 bash 配置里面加一个方法：

sandbox() {
  docker run -it -v $(pwd):/app -w /app $1 bash
}

然后可以方便的打开不同版本的 ruby 沙箱环境：

$ sandbox ruby:2.3

临时测试版本差异的时候会用到。

https://ruby-china.org/topics/37688

装过 rvm 没清理干净，找找 .bashrc .bash_profile .profile 几个配置文件删掉 rvm 相关的内容。

贴日志

Linode 一直以来只做虚拟主机这层，VPC 都没有，运维全靠自己，已经不满足生产需求了。

DigitalOcean 的基础服务足够，配置比 AWS 简单（AWS 配置的门槛较高），可以作为业余和云服务入门。

不过业余项目我最推荐是 Heroku，运维领先业界 5 年，可以把心思都放在开发上。

生产项目就不提了，因为国内网络环境的问题选择不多。

bundle stdout: rbenv: /home/chuck/.rvm/bin/rvm: command not found

用的是 rbenv 还是 rvm？去掉不必要那个。

日志贴全，隐去敏感信息。