![]() ![]() ![]() Of course, nothing of the above is documented. For example, SQL query crashed with "I/O error occurred" can be retried with some jitter, but retrying "Request timed out" is dangerous - however current SQL result is a failure, SQL query can successfully be executed and committed into a database but has not been transferred into RDS Data API result set, and there is no way to determine it. More than that, some kind of service errors are retriable, and some are not retriable. For example, RDS Data API can crash with following errors "Remaining connection slots are reserved", "I/O error occurred", "too many clients already", "Cannot write in a read-only transaction", "canceling statement due to user request" and so on. Some service errors are documented, but many and many errors can be discovered only by manual running queries with high-load. Although RDS Data API developers can easily perform handling these errors in that API and rethrow only user-land errors to a consumer, Data API throws on service errors too, and developer should segregate that errors and performs custom retries and similar logic. Errors do not correlate with corresponding queries and are just abstraction lack from low-lever layers of AWS's serverless implementation. Since the database is serverless, tons of temporary errors can appear while executing SQL statements. Unfortunately just using ExecuteStatement and issuing SQL queries to a database via appropriate API is not enough. Service becomes usable, but not everything is simple. RDS Data API had fixed most major issues, like query result mixing and hanging internal connections. Working with Aurora PostgreSQL serverless had been paralyzed until this post had been published on Reddit. ![]() Database often had been crashed with internal errors like "Too many connections", however, it's serverless service and should not discover any internal implementations, and much for should not throw low-level errors to consumers. Request with SQL Select statement can crash with error from concurrent Update statement. Parallel launched RDS Data API queries had begun to mix results and errors between each other. But when traffic load had been increased, weird things had begun. When starting using Aurora PostgreSQL serverless in late 2019, everything works well with small spikes with low-load traffic. database transactions can be shared between lambdas. RDS Data API has support for external transactions and good API at first sight, e.g. The most common limits in RDS Data API are 64 KB for SQL query, 512 KB for result row set, and 45 seconds for query execution (Documentation says about 1MB limit for result row set, but it is not true). Like any other serverless service, which has potential infinite limits globally, every distinct interaction has strong limits. Since the database is serverless and there is no server with hostname and TCP port, communication is performed via special RDS Data API. Firstly, there is no direct way to communicate with the database via the classical mechanism. When a database is not used price is zero, and when high-load traffic has appeared, the database can perform auto-scale automatically and relative infinitely.Īlthough Aurora PostgreSQL serverless looks perfect and fits high load serverless application requirements, there are some caveats. The price model is based on ACUs, which is used time multiplied by operational power. And since late 2019 AWS had begun providing for a pure serverless relational database - Aurora PostgreSQL serverless. AWS cloud provides many more services for implementing pure serverless application - Lambdas (code execute), Step functions (process orchestration), CloudFront (HTTPS server + web cache provider), and so on. Developing a pure serverless application meant that all its parts should be server-free. ![]()
0 Comments
Leave a Reply. |