We only need to load the extension once, which we're doing in an
initializer. So no need to load it again on the tenanted connections
(and doing so is problematic when it occurs after a fork).
The setup here is a bit rough while we settle some of the details, but
the gist of it is:
- Define accessories to run the primary/replica processes
- Add a web-replica role, which is similar to web but has the
replication-side accessory
- Load the beamer extension on the app's primary tenanted database
Note that we aren't sending any traffic into the replica yet, but it
would be functional to do so. This stage is mainly about testing the
database replication.
ref: https://3.basecamp.com/2914079/buckets/37331921/messages/8422006338
The script takes advantage of the fact that we can bind to the
existing untenanted database by adding it explicitly (and temporarily)
as a readonly shard to the database.yml, and so in the script
with_original_db is connected to the original database.
storage/tenants/%{tenant}/ is now the root directory for all
state stored for a particular tenant, including active storage and the
database.
We leave the existing files and production database in place after the
migration, in case we need to roll back (by reverting the code and
config).
We also don't do a granular active storage blob copy, since the
attachments are mostly on Account (and not on Bubble). Instead we
hardlink the blobs on disk (so we don't take up additional space with
duplicates).
Finally, we're manually adding the kamal-proxy hosts to the deploy
file, so that we can generate letsencrypt certs for the
subdomains. This is only intended to be a short-term solution, we'll
want something like a wildcard cert before we go live.
Jorge Manrubia