Adding advance failover detection for Aurora managed DBs
- Dominant language
- Go
- Stars
- 14.3k
- Forks
- 1.1k
- Avg merge
- 6d 9h
- Merged PRs (30d)
- 11
Description
**Is your feature request related to a problem? Please describe.**
When a db failover happens in Aurora clusters for _some_ time until DNS gets reconfigured any connections are broken.
Potentially i'd like to be able to configure a monitor that detects this situation and:
- invalidates current connections
- provides DNS resolution that's faster than DNS ttl
**Describe the solution you'd like**
Looking at this https://github.com/aws/aws-advanced-jdbc-wrapper i think what i'd like to be able to have is some _topology_ aware driver/connection pool.
**Describe alternatives you've considered**
I think the `target_session_attrs` covers some of the functionality that i'm thinking about, specifically giving it a list of hosts and requiring that the connection is in "write" mode.
This does not cover a failover scenario, because at that point we need to re-resolve the DNS (see [here](https://aws.amazon.com/blogs/database/improve-application-availability-on-amazon-aurora/) )
I _think_ that this can be mostly doable within the context of pgx by doing the following:
- Have a custom function that returns the IP of the writer
- When a failover is detected, reset the connection pool (based on [this](https://github.com/jackc/pgx/issues/299#issuecomment-322010132))
I'm mostly writing here to see if anybody can think of another way of going at this problem, the aws jdbc driver acts as a load balancer from the point of view from the app:
>For each client session, the driver maintains a logical connection (app to driver) and a physical connection (driver to database). If a physical connection fails due to a failover, the driver notices the failure and initiates its own failover handling protocol while keeping the logical connection alive
I don't think that pgx should be responsible for that but maybe there's a "simpler" approach where i can wrap pgx and do something pretty similar, but i'm not fully sure what this wrapper looks like. is it implementing the sql interfaces on top of pgx?
Contributor guide
Research direction
Start by reviewing pgx's target_session_attrs behavior and the connection-pool reset discussion linked in the issue. Compare that with the AWS advanced JDBC wrapper's topology and failover handling, then determine whether a pgx wrapper can detect Aurora failover, re-resolve the writer, and invalidate connections. Done requires a concrete, scoped implementation approach.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, go, postgresql
- Domain
- backend, databases
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100