Postgresql Connection Retry

[rudijs]

Summary

Hi,

If Postgresql is slow to start or not available when Kong starts, is there any retry strategy for the database connection?

What I think is ideal is kong attempts to start up then continues to retry until the database becomes available.

Currently it's just [postgres error] connection refused then the process exits and ends.

Are there any recommended or suggested way I can address this?

Thanks!

Steps To Reproduce

1. Stop Pgsql
2. kong start

Additional Details & Logs

• Kong version 0.93
• Operating System Debian Jesse

[thibaultcha]

I can't seem to find a previous discussion where this was proposed and debated. I remember reading arguments both in favor and against. I would really like to find it before discussing this furthermore.

As of now, your Postgres server will need to be up and running.

[rudijs]

Ah OK, I think auto reconnect before and during Kong/NGNIX start and run would be great - much like a web application does.

With the current status, I'm looking at a start up script that confirms Pgsql is up and ready before starting Kong.

Here's a code snippet of some simple bash code:

echo "==> Waiting for PostgreSQL to be ready..."

while ! nc -z ${KONG_DATABASE_HOSTIP} 5432; do   
  echo "==> $(date) Connecting to ${KONG_DATABASE_HOSTIP} port 5432..."
  sleep 1
done

echo "==> PostgreSQL ready."

echo "==> Start Kong..."

kong start

[thibaultcha]

Yes, I believe it would be good to have too (including for Cassandra as well). The way to implement this would be to check for database availability in the CLI and only start nginx when the database is reachable. We could have a timeout on that operation, preventing Kong's start from hanging too long because the DB is not reachable.

If I recall correctly, someone brought the concern that failing as soon as possible in the "starting process" of the application can also be a desirable behavior, as you you would exepct Kong to start if and only if it is healthy and able to process request (instead of hanging because the DB is not reachable).

I believe a timeout option, or a way to disable this behavior via a CLI flag would solve this concern. Any other thoughts?

[486]

I totally agree that we need this as an option. If activated, Kong should tolerate a missing database or a sudden connection loss and retry / wait until it is available (again). After a user-defined timeout, it should exit as it is currently the case. This behavior is essential for running Kong as a Docker container because in the container world (and in the cloud world) you cannot guarantee anything to be up at a certain point in time or to be always reachable.

[ravidontharaju]

Has there been any update on this? It would be great to have a retry x times or a user-defined time out.