本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
管理连接
随着对应用程序需求的增长，前端流量也随之增加。在典型场景中，您可以在应用程序层设置自动扩展，以处理激增的传入流量。因此，应用程序层开始自动扩缩，并添加更多的应用程序服务器（实例）以满足流量的增长。由于所有应用程序服务器都预先配置了数据库连接池设置，因此数据库的传入连接数与新部署的实例成比例增长。
例如，20 台应用程序服务器配置 200 个数据库连接，将总共打开 4000 个数据库连接。如果应用程序池扩展到 200 个实例（例如，在高峰时段），连接总数将达到 40000 个。在典型的工作负载下，大多数连接可能处于空闲状态。但连接的激增可能会限制您的 Amazon Aurora MySQL 兼容版数据库的扩展能力。这是因为即使是空闲连接也会消耗内存和其他服务器资源，比如文件描述符。Aurora MySQL 兼容版通常使用比 MySQL 社区版更少的内存来维持相同数量的连接。但是，空闲连接的内存使用量仍然不是零。
配置变量
您可以使用两个主要服务器配置变量来控制数据库允许的传入连接数：max_connections 和 max_connect_errors。
配置变量 max_connections
配置变量 max_connections 来限制每个 MySQL 实例的数据库连接数。最佳做法是将其设置为略高于每个数据库实例预计打开的最大连接数。
如果您还启用了 performance_schema，请特别注意 max_connections 设置。Performance Schema 内存结构根据服务器配置变量来自动调整大小，包括 max_connections。变量设置得越高，Performance Schema 使用的内存就越多。在极端情况下，这可能会导致较小的实例类型 out-of-memory出现问题。请注意，启用 Performance Insights 将自动启用 Performance Schema。
配置变量 max_connect_error
配置变量 max_connect_errors 来确定允许来自给定客户端主机的连续中断连接请求次数。如果客户端主机超过指定的连续失败连接尝试次数，服务器将会阻止主机。来自该客户端的进一步连接尝试会产生错误。
Host 'host_name' is blocked because of many connection errors. Unblock with
'mysqladmin flush-hosts'
如果您遇到 “主机被屏蔽” 错误，请避免增加max_connect_errors变量的值。而是调查 aborted_connects 状态变量和 host_cache 表中的服务器诊断计数器。使用收集的信息来识别和修复遇到连接问题的客户端。另请注意，如果 skip_name_resolve 设置为 1（默认），则此参数无效。
有关以下内容的详细信息，请参阅 MySQL 参考手册：
实施连接池
扩展事件可能会添加更多的应用程序服务器，这反过来又可能导致数据库服务器超过满载的活动连接数。在应用程序服务器和数据库之间添加连接池或代理层就像漏斗一样，可以减少数据库上的连接总数。代理的主要目的是通过多路复用来重用数据库连接。
一方面，代理通过数量受控的连接来连接到数据库。另一方面，代理又接受应用程序连接。它还提供了其他功能，比如查询缓存、连接缓冲、查询重写和路由以及负载均衡。需要对连接池层进行配置，使数据库的最大连接数保持在满载数量以下。Amazon RDS 代理
您还可以探索以下适用于 Aurora MySQL 兼容版的第三方代理：
避免连接风暴
考虑在数据库过载或副本落后主节点太多的情况下连接池的行为。配置代理服务器或连接池时，确保不要因为数据库响应缓慢（由底层硬件或存储问题或数据库资源限制所致）而重置整个连接池。
突然启动数百个连接会产生连接风暴，因为同时发起大量对数据库的新连接请求。这种风暴需要大量资源。在 MySQL 中创建新的数据库连接是一项昂贵的操作，因为后端会交换多个网络数据包，以进行初始握手、生成新进程、分配内存、处理身份验证等。如果短时间内收到大量请求，数据库可能会出现无响应的情况。
MySQL 有一种机制可以防止这种连接请求激增。将 back_log 变量设置为在 MySQL 暂时停止响应新请求之前的短时间内可以堆叠的请求数。该值由连接处理线程强制执行，而线程本身可能会被连接风暴淹没。有关更多信息，请参阅 MySQL 参考手册
如果您的连接配置为在数据库运行缓慢时重置，那么您将一次又一次地启动循环。同样，如果您预计在一天中的某些时间（例如，股市开盘时）数据库流量会突然增加，请预热您的连接池，这样就不会在高流量负载开始的同时尝试打开许多连接。
