Common misconceptions - Amazon Aurora MySQL Database Administrator’s Handbook

Common misconceptions

The following are common misconceptions for database connection management.

  • If the server uses connection pooling, you don’t need a pool on the application side. As explained previously, this isn’t true for workloads where connections are opened and torn down very frequently, and clients run relatively few statements per connection.

    You might not need a connection pool if your connections are long lived. This means that connection activity time is much longer than the time required to open and close the connection. You can run a packet trace with tcpdump and see how many packets you need to open or close connections versus how many packets you need to run your queries within those connections. Even if the connections are long lived, you can still benefit from using a connection pool to protect the database against connection surges, that is, large bursts of new connection attempts.

  • Idle connections don’t use memory. This isn’t true because the operating system and the database process both allocate an in-memory descriptor for each user connection. What is typically true is that Aurora MySQL uses less memory than MySQL Community Edition to maintain the same number of connections. However, memory usage for idle connections is still not zero, even with Aurora MySQL.

    The general best practice is to avoid opening significantly more connections than you need.

  • Downtime depends entirely on database stability and database features. This isn’t true because the application design and configuration play an important role in determining how fast user traffic can recover following a database event. For more details, refer to the Best practices section of this whitepaper.