在 dev 环境的机器应该没什么问题，资料量都不大

在 dev 环境的机器应该没什么问题，资料量都不大，应该是很快就可以跑完；但在 stage 环境时就会开始有状况了 (假设是从 production 复制过来的资料，表格的大小可能偏大)，但应该还是可以用 downtime 换，慢慢跑，花几个小时把 db migration 跑完。

可是到了 production 环境时就不太能这样搞了，这也是一般不太建议在 production 环境里用现成的 db migration 工具，尤其当资料量偏大的时候。

解这个问题的方法就是透过绕路的方式，不要直接动原来的 table：基本的想法是开一个新的 table，然后一直从旧的 table 搬资料到新的 table 上 (包括应用程序下指令写到旧的 table 上的资料)，直到最后用一个短暂的 lock 机制来切换 table。

在 PostgreSQL 的世界里似乎是 pg_repack 这个方案，用了 trigger-based 的方式处理，但之前没有注意到，是翻 pg-osc 的时候被提到才知道有这个工具。

然后把 firewall 打开，接下来就可以从其他台连进去了。