We use AWS Aurora Serverless PostgreSQL as the main database in our project.
With a growing number of users, we started facing the following issue quite often:
terminating current active connection due to forced scale event.
Obviously, it happens when the database is scaling, but I'm not sure how to properly handle this exception or prevent scaling.
Also, it seems that when we save a considerable number of rows in one transaction and scaling begins, some rows are committed to the database and others aren't, which breaks the data consistency.
We use C# Entity Framework Core as ORM.
Is there a proper way to handle situations like this?
You can switch to v2 to avoid terminating active connections during scaling. As the documentation states,
The notions of scaling points and associated timeout periods from Aurora Serverless v1 don't apply in Aurora Serverless v2. Aurora Serverless v2 scaling can happen while database connections are open, while SQL transactions are in process, while tables are locked, and while temporary tables are in use. Aurora Serverless v2 doesn't wait for a quiet point to begin scaling. Scaling doesn't disrupt any database operations that are underway.
If you are going to stick with V1 (might not be possible for much longer due to end-of-life for V1), you can also change the setting to "Roll back" rather than "force":
If the timeout expires before a scaling point is found, do this:
Roll back the capacity change Your Aurora Serverless cluster's capacity isn't changed. It stays as its current capacity.
Force the capacity change Your Aurora Serverless cluster's capacity is changed without a scaling point. This can interrupt in-progress transactions, requiring resubmission.
You can see the current timeout action in the CLI with:
aws rds describe-db-clusters --db-cluster-identifier myCluster |
jq .DBClusters[].ScalingConfigurationInfo.TimeoutAction
and set it with
aws rds modify-db-cluster --db-cluster-identifier myCluster --scaling-configuration TimeoutAction=RollbackCapacityChange