adding a reading replica to an existing app creates a brand new database

1

Hey :wave:

Maybe I’ve missed something but I encountered a weird behavior: adding a reading replica to an existing app creates a brand new database (and proxying the Postgres app actually points to the “old” db)

Here is what I did: I have a Rails app that I’m running based on the regular flyctl launch etc. It works fine and it has the DATABASE_URL env. var set.

Now, following this guide, this is what I did:

  • Added a volume
  • Scaled out the Postgres app
  • Run fly attach --postgres-app command

Here is when things got interesting: The command complained that a DATABASE_URL was already in place and I couldn’t do that, so I set the database url to a new env. var called DB_URL and updated my database.yml to use DB_URL.

To my surprise, upon deploying, I saw the migrations running all over and suddenly I had a brand new DB!

This is not expected I think and what is strange is that I can’t see the new DB anywhere. Proxying the Postgres app with flyctl proxy 5433 -a my_postgres_app shows me the old.

Two questions: what happened and how can I avoid/revert it?

2

Ok, as soon as I posted, I think I realized my mistake. Two things I screwed up:

  • My old DATABASE_URL doesn’t have a db name suffixed to it so all tables were created under postgres database. rookie mistake here
  • The new DB_URL of course does have the db name suffixed. I can now connect to it.

Here is another question tho. while playing around with multi-region, I did the following

  • Added a volume on a diff. region
  • Scale out postgres app
  • Added fly-ruby gem
  • Redeployed

Upon redeploying, my app was 10x slower. I assume it was because I was not using the correct db_url (postgres://user:passwd@postgres.internal:5432 instead of postgres://user:password@top2.nearest.of.postrgres.internal:5432/fatia_pizza_app)

Was that the reason?