【最佳实践】CDB连接数被打满了，如何快速恢复和规避？

最近某W客户，新上业务逻辑把整个CDB的连接打满了，导致线上业务中断，影响公司口碑，教训极其惨重，为此本文对此进行梳理总结，让CDB连接数更加可控，确保业务稳定性。

【医治范围】针对CDB连接数打满

1. 快速止损恢复预案
2. 规避根治方案

1.事件回放

客户报障，一台线上CDB异常，业务访问全部异常，目前控制台无法立即执行重启，同时无法登录机器不能kill。需要腾讯云同学来救场。

遇到这种情况，我们可以迅速过检查监控，肯定有异常，果然发现连接数被打爆了（如下图），所以无法执行重启和登录机器，立刻建议客户去关闭对应的功能模块并授权腾讯云kill线程来恢复业务。

连接数

慢查询

2.如何快速恢复？

从上面监控数据看到，业务异常持续将近30分钟，以下两件事情做到好，业务能有效止损。

1）快速知道发生了什么

监控告警及时触达。一般接数打满肯定是瞬间突增，所以这里配置告警必须异常敏感，最小周期持续告警。

建议：

当前连接数>=实例最大连接数（max_connnecntion DB参数值）

统计周期为一分钟告警，最小粒度持续告警。

告警配置demo

2）根据告警，SOP恢复动作

常规方案：接到告警，务必马上立刻电话告知腾讯侧接口同学，授权腾讯侧授权kill线程权限，kill线程后观察连接数趋势以及业务恢复情况

兜底方案：kill线程无法有效降低连接数, 客户评估是否要关闭业务逻辑功能后，再次授权腾讯云侧kill线程或者强制重启机器。

3.如何有效规避？

如何对CDB连接数做到可控，保证个别业务功能连接数报复性增长，不会影响整个实例CDB连接数，降低业务异常范围。基于改造复杂程度，有应急方案和优化方案建议如下：

1)应急方案：CDB精细化分配，做到可控。

a)实例整体连接数保持在健康水位

用户可以根据需要自行调整max_connections的值。但是连接数越多对资源消耗也越高，结合实例规格和业务需求合理使用。

建议使用购买实例默认值。

b）连接数精细化控制，合理设置各个用户最大连接数。

根据业务实际使用情况，针对不同用户合理设置最大链接(max_user_connections)，即使某个用户有bug连接数耗尽，也只会影响该用户功能，不影响其他功能正常使用DB.

c）相关超时时间合理设置，关闭失效连接。

根据业务情况来设置超时时间，主动断开连接。DB默认值如下建议值：

connect_timeout 10

innodb_lock_wait_timeout 60

interactive_timeout 3600

wait_timeout 3600

innodb_rollback_on_timeout OFF

2)优化方案：引入连接池来管理连接

根据业务自身情况，引入对应连接池。连接池优势：

• 建立和释放连接会消耗CDB服务器性能，引入连接池会提升性能
• 降低CDB服务器内存消耗
• 动态的分配连接，满足业务需求

4.建议

1）通过DB参数配置或者引入连接池可以有效的控制连接数，但从业务梳理流来看，建议流控依次接入层，逻辑层，数据层顺序来处理。这样资源会得到更好利用，并能更及时对业务进行降维处理。

业务数据流

2）业务CDB分库分表来不断解耦业务逻辑，降低CDB异常给业务造成影响面。

3）新上业务进行质量压测和sql语句单元测试，保证业务稳定性。