Database connection problem

Questions / Help
1

Hi!

I wanted to report a problem we have.

We have our application running in two regions: iad (main) and syd.
We also have a Postgres cluster in the same two regions.

Then the latest deploy of the app starts working very slowly in our main region (IAD).

image

We discussed about a similar error here with @kurt and @Mark : Strange behavior on syd region

We have this IPS for the database:

image

The DATABASE_URL in the aplication used top2.nearest.of.brandkitdb.internal (was automatically configured with fly postgres attach)

I connected to the application in the IAD region and checked which database it was connecting to.

The first time I do the check it seems that you are selecting the wrong IP:

image
image729Ă—422 121 KB

Then I tried with top2:

image
image769Ă—457 61.2 KB

And then I tried again with top1:

image
image741Ă—441 54.6 KB

All of the following times work correctly using an IP from the IAD region.

Is this behavior normal?

The app continues to run slow in that region

Do you have any idea what could be happening?

Thanks! :smiley:

2

I don’t know, but thank you for explaining the issue so clearly!

Could you share the IP address of the instance where you are running dig? I’m asking mostly for context while I get up to speed on the March 1st thread you linked :pray:

1 Like
3

Sure! I don’t know if the problems are related. But it’s a similar problem I think!

❯ fly ips private --app brandkit
  ID       | REGION | IP
-----------*--------*-----------------------------------
  d29b999d | syd    | fdaa:0:37d5:a7b:9e6b:d29b:999d:2
  e22b3798 | iad    | fdaa:0:37d5:a7b:9d36:e22b:3798:2
4

Hi. Fede’s coworker here.
It’s working fine now.
Looks like it just got fixed by itself.
Any ideas of what could be the problem in the first place?

5

hey there! Glad to hear that things are running smoothy again. On our end, we haven’t applied a fix or anything to bring it back up, so I’m not sure.

It does seem that for fly postgres apps, records do get removed from our DNS in the case of vm failure. This might also be something to look out for in the vm logs should you see this behavior again.