一 前言
DBA 运维就是填坑的过程，其他人挖坑，自己填；自己挖坑，自己填，说多了都是泪。好吧言归正传，今天凌晨忙碌了一个通宵做IDC 交互机维护改造以及升级数据库服务器的事情，需要重启服务器。重启完成OS和重新部署数据库周边配套设施之后，系统没有问题，早上8点多开始数据库的error log 一直出现，别问为啥现在才处理(我补觉到11点多 ，13点才到公司。)
二 排查
上面的报警信息虽然不严重，但是error log一直有warnning信息写入，总是要解决的。遇到“Too many connections”报错通常的情况是 当前的数据库连接数超过了系统 max_connections，max_user_connections 设置的大小。从这方面入手，具体的排查思路。通常会检查
1 数据库能否登陆，登陆是否会报错，但是登陆db 无异常。
2 检查 max_connections，max_user_connections的大小配置
3 检查数据库系统的连接分布，如下图 显然都正常的 ，系统配置 4000个连接，单个用户300多个连接 ，远远小于系统设置的值。
分析到这里似乎陷入了僵局。在 当前连接数 < max_connections 且当前连接数< max_user_connections 的时候，竟然出现了 "[Warning] Too many connections ",于是乎问了其他DBA同行，拓展一下思路，他们也表示差异，也无其他思路。
和凌晨一起做变更的同事反馈目前遇到的问题，他的提示一语惊醒梦中人---我们启用sql-killer(类似pt-killer实时监测系统，有执行时间超过1.02s左右的sql 就会kill掉)是通过管理端口连接数据库。
什么是 管理端口---在MySQL启动时使用该参数extra_port指定一个端口号(不要和正常的数据库服务端口冲突)，Percona Server会监听来自该端口的请求。启用该参数可以解决使用thread_pool特性时，由于所有的连接池worker忙于处理慢querey或者被锁定导致DBA无法通过正常的端口连接DB, 以便DBA可以正常维护数据库。显然使用管理端口的初衷是好的 ，也是避免慢查询堵住数据库，sql-killer可以从管理端口连接到db，然后kill 产生慢查询的会话。
于是我们把sql-killer 停止，果然 error信息也随之停止。从管理端口方面检查发现 extra_max_connections 重启之后 变为1 ，导致sql-killer请求无法连接，报"Too many connections " 。知道原因之后 就是动态修改实例中的参数，修改配置文件中的参数，然后重启sql-killer ，至此问题解决。
三 小结
解决这个异常大概花费了大约1.5h，究其原因还是对自己的系统掌握不够，数据库配置文件方面没有进行标准化，导致一系列的后续问题，假如没有同事提醒还有工具通过管理端口进行数据库连接，估计我需要花费更久的时间来排查问题。以后自己要梳理数据库标准化的配置，统一到所有数据库。
常规的思维解决常规的问题。
DBA 运维就是填坑的过程，其他人挖坑，自己填；自己挖坑，自己填，说多了都是泪。好吧言归正传，今天凌晨忙碌了一个通宵做IDC 交互机维护改造以及升级数据库服务器的事情，需要重启服务器。重启完成OS和重新部署数据库周边配套设施之后，系统没有问题，早上8点多开始数据库的error log 一直出现，别问为啥现在才处理(我补觉到11点多 ，13点才到公司。)
- 2017-01-10 20:47:45 21194 [Warning] Too many connections
上面的报警信息虽然不严重，但是error log一直有warnning信息写入，总是要解决的。遇到“Too many connections”报错通常的情况是 当前的数据库连接数超过了系统 max_connections，max_user_connections 设置的大小。从这方面入手，具体的排查思路。通常会检查
1 数据库能否登陆，登陆是否会报错，但是登陆db 无异常。
2 检查 max_connections，max_user_connections的大小配置
3 检查数据库系统的连接分布，如下图 显然都正常的 ，系统配置 4000个连接，单个用户300多个连接 ，远远小于系统设置的值。
- SELECT substring_index(host, ':',1) AS host_name,state,count(*) FROM information_schema.processlist GROUP BY state,host_name;
分析到这里似乎陷入了僵局。在 当前连接数 < max_connections 且当前连接数< max_user_connections 的时候，竟然出现了 "[Warning] Too many connections ",于是乎问了其他DBA同行，拓展一下思路，他们也表示差异，也无其他思路。
和凌晨一起做变更的同事反馈目前遇到的问题，他的提示一语惊醒梦中人---我们启用sql-killer(类似pt-killer实时监测系统，有执行时间超过1.02s左右的sql 就会kill掉)是通过管理端口连接数据库。
什么是 管理端口---在MySQL启动时使用该参数extra_port指定一个端口号(不要和正常的数据库服务端口冲突)，Percona Server会监听来自该端口的请求。启用该参数可以解决使用thread_pool特性时，由于所有的连接池worker忙于处理慢querey或者被锁定导致DBA无法通过正常的端口连接DB, 以便DBA可以正常维护数据库。显然使用管理端口的初衷是好的 ，也是避免慢查询堵住数据库，sql-killer可以从管理端口连接到db，然后kill 产生慢查询的会话。
于是我们把sql-killer 停止，果然 error信息也随之停止。从管理端口方面检查发现 extra_max_connections 重启之后 变为1 ，导致sql-killer请求无法连接，报"Too many connections " 。知道原因之后 就是动态修改实例中的参数，修改配置文件中的参数，然后重启sql-killer ，至此问题解决。
三 小结
解决这个异常大概花费了大约1.5h，究其原因还是对自己的系统掌握不够，数据库配置文件方面没有进行标准化，导致一系列的后续问题，假如没有同事提醒还有工具通过管理端口进行数据库连接，估计我需要花费更久的时间来排查问题。以后自己要梳理数据库标准化的配置，统一到所有数据库。
常规的思维解决常规的问题。
