We recently performed a zero downtime Postgres upgrade at Knock. This blog post goes into details about the Postgres considerations, although the BEAM & Elixir ecosystem were invaluable in managing the cutover process.
Some Elixir-related bits:
- We used
DynamicSupervisorto start/stop Oban during the cutover. Without going into too much detail, Oban needs aNotifierto coordinate global state, and we rely on the default Postgres notifier (Although there is a new PubSub notifier that we have our eyes on). This Notifier establishes a persistent Postgres connection that is managed outside of your Ecto Repo, and the easiest way to move Oban over to the new instance was to stop and restart it with a new configuration usingDynamicSupervisor - Metaprogramming made it easier to build facade interfaces to our Ecto Repos so that database requests could be routed to the old or new database instance, based on the state of a launch darkly flag. Internally, LD uses ETS and a persistent websocket connection, which helps lookups be fast and up to date. ETS is still not quite fast enough for the volume of DB queries in our system, and so we also used
:persistent_termto set the flag that determined what state we were in during the cutover process. Benchee helped us verify that we weren’t going to have a performance regression. - We looked at Ecto Repo’s
get_dynamic_repofunction, but determined that using a facade was a better fit for our use case. It’s worth knowing what’s available, though, since Ecto comes with a lot of extensibility out of the box. - The concurrency model of the BEAM makes it so much easier to reason about all of the stuff involved in a migration like this. Although you can take a similar approach with most languages, the BEAM didn’t get in the way of reasoning through the specifics of the cutover, especially around how we maintain uptime and data consistency during a cutover like this.
We may do a full post on the BEAM-related details of this upgrade in the future.
