Open jguertin opened 4 years ago
When solving the issue, we may instead look at pessimistic disconnect handling. The strategy is essentially to perform a SELECT 1
on connections when SQL Alchemy prepares to use it: https://docs.sqlalchemy.org/en/13/core/pooling.html#disconnect-handling-pessimistic
Regarding pessimistic disconnect handling, Thor noted:
We've has been finding those settings aren't doing exactly what he needs. I'm using some the sqlalchemy settings and also have the DB liveness in the probe having to pod roll itself if it can't connect well. although with the DNS outtages in the cluster of late that makess for a fairly active set of rolls
Based on this we may need to use leverage the DB health check endpoint to reset connection as a secondary function.
This issue is to address an issue appearing in Sentry: https://sentry.io/organizations/bc-government-registries/issues/1488039825/?project=1834187
It appears the connection was dropped when we performed "SELECT 1" against the database in the health check endpoint. Here's a bit more background on how we can optimistically deal with this kind of problem. https://docs.sqlalchemy.org/en/13/core/pooling.html#disconnect-handling-optimistic
The logs copied from the server provide a bit more context over what is available in Sentry: