search

berenddeboer / cdk-rds-sql

A CDK construct that allows creating roles and databases an on Aurora Serverless Postgresql cluster.
Apache License 2.0
23 stars 11 forks source link

fix: extend connection timeout #12

Closed blimmer closed 2 months ago

blimmer commented 1 year ago

Fixes #7

Agree with @moltar - the timeout is very very low and can cause timeout exceptions that could be avoided by just bumping the time.

Since the lambda has 300 seconds to run, a maximum of 30 seconds to connect seems reasonable.

berenddeboer commented 6 months ago

Apologies, only saw this now. The problem I have with this is if the database is not accessible, it'll wait 30seconds. Also 2s seems pretty reasonable for a database? I would find it odd it cannot connect that quickly. I think I rather have it as an option if this is a problem for people.

blimmer commented 6 months ago

The problem is with the initial creation of the database. I can't use this construct because it does not wait long enough for the database to be live, then fails the whole stack.

Perhaps it needs to have additional CFN dependencies?

berenddeboer commented 6 months ago

Ah, so not with resume right? It depends on the rds construct. So is this a v2 serverless? Happy to support this a bit better, but possibly via an option. So if you can help me with the exact conditions? Then I can see if I can get it right or even repeat it.

blimmer commented 5 months ago

I tried using this pacakge with several standard RDS Aurora Postgres clusters, only to have them rolled back because of timeouts from this custom resource.

I think you could reproduce this issue on just a standard rds aurora cluster, because they can take quite a while (~10 minutes) to spin up.

stephanpelikan commented 2 months ago

I have the same issue: I created a serverless PostgreSql which has to auto-pause after 5 mins: Current capacity: 0 capacity units.

Next I extended the stack to create a database but it fails due to timeout.

Regarding timeout: Even deleting the cluster took 1516 seconds. All the time the stack was waiting for the cluster to wake up and receive the 'delete' command. During this period in AWS console the cluster was still active and zero capacity.