Server configuration - Amazon Aurora MySQL Database Administrator’s Handbook

Server configuration

There are two major server configuration variables worth mentioning in the context of this whitepaper: max_connections and max_connect_errors.

Configuration variable max_connections

The configuration variable max_connections limits the number of database connections per Aurora DB instance. The best practice is to set it slightly higher than the maximum number of connections you expect to open on each instance.

If you also enabled performance_schema, be extra careful with the setting. The Performance Schema memory structures are sized automatically based on server configuration variables, including max_connections. The higher you set the variable, the more memory Performance Schema uses. In extreme cases, this can lead to out-of-memory issues on smaller instance types.

Note for T2 and T3 instance families

Using Performance Schema on T2 and T3 Aurora DB instances with less than 8 GB of memory isn’t recommended. To reduce the risk of out-of-memory issues on T2 and T3 instances:

  • Don’t enable Performance Schema.

  • If you must use Performance Schema, leave max_connections at the default value.

  • Disable Performance Schema if you plan to increase max_connections to a value significantly greater than the default value.

Refer to the MySQL Reference Manual for details about the max_connections variable.

Configuration variable max_connect_errors

The configuration variable max_connect_errors determines how many successive interrupted connection requests are permitted from a given client host. If the client host exceeds the number of successive failed connection attempts, the server blocks it. Further connection attempts from that client yield an error:

Host 'host_name' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts'

A common (but incorrect) practice is to set the parameter to a very high value to avoid client connectivity issues. This practice isn’t recommended because it:

  • Allows application owners to tolerate connection problems rather than identify and resolve the underlying cause. Connection issues can impact your application health, so they should be resolved rather than ignored.

  • Can hide real threats, for example, someone actively trying to break into the server.

If you experience “host is blocked” errors, increasing the value of the max_connect_errors variable isn’t the correct response. Instead, investigate the server’s diagnostic counters in the aborted_connects status variable and the host_cache table. Then use the information to identify and fix clients that run into connection issues. Also note that this parameter has no effect if skip_name_resolve is set to 1 (default).

Refer to the MySQL Reference Manual for details on the following: