应用端对接MySQL数据库报Communications link failure
发布时间：2022-03-25 15:48:49 所属栏目：编程 来源：互联网
导读：Long long ago，there was a story about the Arguments between DBAs and the Developers... 这个故事，并没有童话故事里王子和公主幸福的各种浪。那么就随我，揭示故事发生的原因。 事情的起因： 某项目的开发同学突然Q我们组的某同学，要求我们调整MySQL
|
Long long ago，there was a story about the Arguments between DBAs and the Developers... 这个故事，并没有童话故事里王子和公主幸福的各种浪。那么就随我，揭示故事发生的原因。 事情的起因： 某项目的开发同学突然Q我们组的某同学，要求我们调整MySQL的连接等待超时参数wait_timeout。要求我们从28800s调整到31536000s（也就是一年） 所以为了避免出现这种情况，DBAs的立场是非常明确的，绝对不允许轻易修改生产环境数据库的参数。这个原因我后面给出。那么现在我们继续focus到眼前的问题。 既然不允许更改数据库参数，但是问题还在，那么如何定位问题的真正原因呢？这里我将根据我在处理这个问题时的思路，引导大家掌握基本的排障方法。 开发同学给出的答案是： 1. 确实使用了连接池（dbcp原生的）。 2. 经过和运维相关同学协调，发现tomcat里确实缺少连接回收的参数。 解决方案： OK，那么我基本可以定位问题了，下面就是给出解决方案： 1. Tomcat增加removeAbandoned=true、removeAbandonedTimeout=60、testOnBorrow=true和validationQuery=select now()。目的是让webserver的连接池自己在连接前先判断数据库侧是否已经将连接释放掉，如果释放掉则会回收并重建连接。注：removeAbandoned和removeAbandonedTimeout两个参数我在给出时略有犹豫，因为这两个参数可能会导致连接在removeAbandonedTimeout所设置的时间内没有处理完时，也会被连接池强制回收，从而导致请求没有返回数据就断开了。所以一般生产环境中不会设置这两个参数，不过在得知是测试环境后，我决定先尝试一下看是否能定位问题就是连接池。 2. 如果上述方法不能解决，那么可以尝试更换c3p0这样的第三方连接池。 3. 如果更换c3p0还不能解决，那么请检查综测环境里的这台机器是否开启了防火墙，或者是否selinux的策略有问题。这样做主要是我发现错误日志中的连接断开时间非常有规律。如下图： 后记： 这个小故事，我总结了下面几点请大家借鉴： 1. 所有你看到的故障只是它在某一时间段的某一表象。那么怎么根据这些表象迅速定位问题呢？除了工作经验的积累外，还要掌握把分散的知识点联系起来的能力。这在处理故障时会大有用处。 2. 开发人员不要轻易要求DBA修改数据库。包括参数、数据等等等等。前文提到不允许轻易修改生产数据库的参数，这也是我在每次分享时都要强调的。数据是一个公司的核心，数据库是存放这一核心的工具。数据库最大的特点是稳定，也最需要稳定。不管前端应用开发的多么花里胡哨，实现了多么复杂的逻辑，如果数据库没有稳定支撑，而是在不断变动，那么应用只会出现展现数据不正确（错误数据）或者数据不一致（脏数据）的情况。所以烦请开发同学们对每次提给数据库组的请求一定要慎之又慎。 3. 尽可能的多了解自己工作之外的世界。做技术要有刨根问底的精神，多了解些和本职工作无关的，甚至是其他人的本质工作，你会发现你的职业道路会越走越宽~ PS： 很多人会混淆这两个概念。在one-thread-per-connection的传统配置里，连接和线程就是1对1的关系。但是在thread pool的概念提出后，这种情况就不再是这样的了。这里我用不是DBA就能看懂的语言简单的解释一下： 连接池实现在Client端。由于Client端频繁的创建和释放连接会增加请求的平均响应时间，因此Client端往往会预先创建一些连接，通过这些连接来完成针对数据库的所有请求。在Client端请求繁忙时，还可以通过请求排队机制，缓解数据库并发压力。 不知道这样解释，你明白了吗？ （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
