技术译文 | 使用 TCP Wrappers 保护 MySQL 如何导致服务中断
亲爱的编程学习爱好者,如果你点开了这篇文章,说明你对《技术译文 | 使用 TCP Wrappers 保护 MySQL 如何导致服务中断》很感兴趣。本篇文章就来给大家详细解析一下,主要介绍一下MySQL、数据库,希望所有认真读完的童鞋们,都有实质性的提高。
作者:Ananias Tsalouchidis
翻译:孟维克
原文:https://www.percona.com/blog/...
案例
保护 MySQL 总是一个挑战。有一些通用的最佳实践可用于安装加固,但是您的设置越复杂,就越有可能遇到一些难以排查的故障的问题。
我们最近在研究一个案例,当活跃线程很高,超过一个阈值(但并不总是相同)时,MySQL 开始变得不可用。

在此期间,有许多像下面这样的日志,mysqld 有几秒钟没有响应。
2019-11-27T10:26:03.476282Z 7736563 [Note] Got an error writing communication packets 2019-11-27T10:26:03.476305Z 7736564 [Note] Got an error writing communication packets
"Got an error writing communication packets"是一个很常见的日志消息,它可能由多种原因引起。
(官方文档请参考文末链接)
我们是如何处理此问题并查找根本原因的
首先要做的是远程执行一个简单的循环,以确定这是否是随机发生的,是网络问题还是与 mysqld 本身相关的问题。
[RDBA] percona@monitoring1: ~ $ time for i in {1..100}; \ do mysql -h 10.0.2.14 -Bsse "show status like '%uptime';"; \ done Uptime 3540 Uptime 3540 Uptime 3540 Uptime 3541 Uptime 3541 Uptime 3541 Uptime 3541 Uptime 3542 Uptime 3542 Uptime 3542 Uptime 3543 Uptime 3543 Uptime 3543 Uptime 3543 Uptime 3543 Uptime 3544 ^C
最初想做的是确认客户报告的行为。因此,鉴于所有应用服务器都处于远程位置(因此客户端通过 TCP 链接),想确认是否有远程连接被丢弃(这是由于网络问题?还是处于任何原因导致 MySQL 无响应?)。还想验证是否存在一个场景,即 X 中的一个连接被丢弃或一定时间后连接被丢弃。确认场景通常有助于确认根本原因是什么。执行此远程连接循环的另一个原因是验证此问题是否仅在远程连接时发生还是在本地连接时也出现(稍后将测试本地连接)。
在网络层 troubleshooting,并没有发现任何问题,因此决定使用另外一个循环在本地通过 TCP 链接到 mysqld。这个测试表明 MySQL 确实不可用的(或者至少不能随机访问它)。不幸的是,当时并没有通过套接字测试本地连接。通过套接字连接完全绕过网络层。如果尝试使用套接字进行连接,会立即意识到这实际上不是 MySQL 问题,因为 MySQL 总是可用的(所以在网络级别上有些东西阻塞了连接)。下面是更多的细节。
继续进行 troubleshooting,netstat 显示许多连接处于 TIME_WAIT 状态。TIME_WAIT 表示源端已经关闭了连接。下面是一个在测试环境中使用 netstat 识别 TCP 连接的示例。
[RDBA] percona@db4-atsaloux: ~ $ sudo netstat -a -t Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:sunrpc 0.0.0.0:* LISTEN tcp 0 0 db4-atsaloux:42000 0.0.0.0:* LISTEN tcp 0 0 localhost:domain 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:nrpe 0.0.0.0:* LISTEN tcp 0 0 db4-atsaloux:ssh 10.0.2.10:35230 ESTABLISHED tcp 0 36 db4-atsaloux:ssh 10.0.2.10:39728 ESTABLISHED tcp 0 0 db4-atsaloux:49154 10.0.2.11:mysql ESTABLISHED tcp6 0 0 [::]:mysql [::]:* LISTEN tcp6 0 0 [::]:sunrpc [::]:* LISTEN tcp6 0 0 [::]:ssh [::]:* LISTEN tcp6 0 0 [::]:nrpe [::]:* LISTEN tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50950 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50964 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50938 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50940 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:51010 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50994 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50986 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:44110 ESTABLISHED tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50984 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50978 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:51030 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50954 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:51032 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:51042 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50996 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:51046 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:51000 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50942 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:51004 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:44108 ESTABLISHED tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50992 TIME_WAIT tcp6 0 0 db4-atsaloux:mysql 10.0.2.10:50988 TIME_WAIT
这让我们认识到,可能已经耗尽了 TCP 层上的 TCP 连接,因为 TCP 会话数量增加了,这些会话一直保持打开状态,直到出现 time_wait 超时。我们在之前写了一篇相关blog(请参考文末链接 )。这样可以让您很好地了解什么是 "TIME_WAIT" 问题,以及可以采取哪些措施进行补救。
我们最初尝试对端口范围
db4-atsaloux (none)> select @@skip_name_resolve; +---------------------+ | @@skip_name_resolve | +---------------------+ | 1 | +---------------------+ 1 row in set (0.00 sec)
为了进一步调试 MySQL 实际做了什么,我们对 mysqld 进程进行了 strace。
根本原因
我们注意到 mysqld 进程过于频繁地访问 /etc/hosts.allow 和 /etc/hosts.deny 文件。
root@db4-atsaloux:~# strace -e open,read -p$(pidof mysqld) strace: Process 693 attached # /etc/hosts.deny: list of hosts that are _not_ allowed to access the system. read(51, "# /etc/hosts.allow: list of host"..., 4096) = 464 read(51, "", 4096) = 0 # /etc/hosts.allow: list of hosts that are allowed to access the system. read(51, "# /etc/hosts.deny: list of hosts"..., 4096) = 721 read(51, "", 4096) = 0 read(51, "# /etc/hosts.allow: list of host"..., 4096) = 464 read(51, "", 4096) = 0 read(51, "# /etc/hosts.deny: list of hosts"..., 4096) = 721 read(51, "", 4096) = 0 read(51, "# /etc/hosts.allow: list of host"..., 4096) = 464 read(51, "", 4096) = 0 read(51, "# /etc/hosts.deny: list of hosts"..., 4096) = 721 read(51, "", 4096) = 0 read(51, "# /etc/hosts.allow: list of host"..., 4096) = 464 read(51, "", 4096) = 0 read(51, "# /etc/hosts.deny: list of hosts"..., 4096) = 721 read(51, "", 4096) = 0 read(51, "# /etc/hosts.allow: list of host"..., 4096) = 464 read(51, "", 4096) = 0 read(51, "# /etc/hosts.deny: list of hosts"..., 4096) = 721 read(51, "", 4096) = 0 read(51, "# /etc/hosts.allow: list of host"..., 4096) = 464 read(51, "", 4096) = 0 read(51, "# /etc/hosts.deny: list of hosts"..., 4096) = 721 read(51, "", 4096) = 0 read(51, "# /etc/hosts.allow: list of host"..., 4096) = 464 read(51, "", 4096) = 0 read(51, "# /etc/hosts.deny: list of hosts"..., 4096) = 721 read(51, "", 4096) = 0 read(51, "# /etc/hosts.allow: list of host"..., 4096) = 464 read(51, "", 4096) = 0
如我们所见,一些新的连接需要花费很长的时间来连接 MySQL。mysqld pid 上的 strace 显示频繁地访问 /etc/hosts.allow 和 /etc/hosts.deny。这些文件与 tcp wrappers 直接相关!许多系统管理员认为 TCP wrappers 是过时软件(软件开发已经停止,但是有很多替代方案),但是他们仍然被广泛使用。使用 TCP wrappers 时,必须根据 ACL 检查每个新的连接,并根据此 ACL 决定是否允许远程主机连接到服务。
在 troubleshooting 时发现 DNS 解析与 MySQL 的
[RDBA] percona@db4-atsaloux: ~ $ ldd /usr/sbin/mysqld | grep libwrap libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fa80532c000)
相关文档及博文链接:
《Communication Errors and Aborted Connections》
https://dev.mysql.com/doc/ref...
《Application Cannot Open Another Connection to MySQL》
https://www.percona.com/blog/...;)
理论要掌握,实操不能落!以上关于《技术译文 | 使用 TCP Wrappers 保护 MySQL 如何导致服务中断》的详细介绍,大家都掌握了吧!如果想要继续提升自己的能力,那么就来关注golang学习网公众号吧!

- 上一篇
- MySQL 的 LIMIT 查询优化

- 下一篇
- EMQ X 认证鉴权(一)——基于 MySQL 的 MQTT 连接认证
-
- 舒适的火
- 感谢大佬分享,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,看完之后很有帮助,总算是懂了,感谢师傅分享博文!
- 2023-03-14 08:38:57
-
- 淡然的蜜粉
- 这篇文章内容真是及时雨啊,太详细了,写的不错,码住,关注博主了!希望博主能多写数据库相关的文章。
- 2023-03-09 08:04:39
-
- 有魅力的砖头
- 很详细,mark,感谢师傅的这篇文章内容,我会继续支持!
- 2023-03-07 04:41:00
-
- 数据库 · MySQL | 3小时前 | mysql 字符集 中文乱码 utf8mb4 utf8mb4_unicode_ci
- MySQL中文乱码解决方案与字符集修改命令大全
- 339浏览 收藏
-
- 数据库 · MySQL | 1天前 | 索引 数据类型 字符集 存储引擎 CREATETABLE
- MySQL新建表操作指南与建表技巧
- 462浏览 收藏
-
- 数据库 · MySQL | 1个月前 | 条件判断
- CASEWHEN条件判断的嵌套使用详解与实战场景分析
- 469浏览 收藏
-
- 数据库 · MySQL | 1个月前 | java php
- CSV文件批量导入MySQL的性能优化秘籍大揭秘
- 289浏览 收藏
-
- 数据库 · MySQL | 1个月前 |
- GaleraCluster多主集群配置与冲突解决攻略
- 239浏览 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 542次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 508次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 497次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 484次学习
-
- 笔灵AI生成答辩PPT
- 探索笔灵AI生成答辩PPT的强大功能,快速制作高质量答辩PPT。精准内容提取、多样模板匹配、数据可视化、配套自述稿生成,让您的学术和职场展示更加专业与高效。
- 20次使用
-
- 知网AIGC检测服务系统
- 知网AIGC检测服务系统,专注于检测学术文本中的疑似AI生成内容。依托知网海量高质量文献资源,结合先进的“知识增强AIGC检测技术”,系统能够从语言模式和语义逻辑两方面精准识别AI生成内容,适用于学术研究、教育和企业领域,确保文本的真实性和原创性。
- 29次使用
-
- AIGC检测-Aibiye
- AIbiye官网推出的AIGC检测服务,专注于检测ChatGPT、Gemini、Claude等AIGC工具生成的文本,帮助用户确保论文的原创性和学术规范。支持txt和doc(x)格式,检测范围为论文正文,提供高准确性和便捷的用户体验。
- 35次使用
-
- 易笔AI论文
- 易笔AI论文平台提供自动写作、格式校对、查重检测等功能,支持多种学术领域的论文生成。价格优惠,界面友好,操作简便,适用于学术研究者、学生及论文辅导机构。
- 43次使用
-
- 笔启AI论文写作平台
- 笔启AI论文写作平台提供多类型论文生成服务,支持多语言写作,满足学术研究者、学生和职场人士的需求。平台采用AI 4.0版本,确保论文质量和原创性,并提供查重保障和隐私保护。
- 37次使用
-
- golang MySQL实现对数据库表存储获取操作示例
- 2022-12-22 499浏览
-
- 搞一个自娱自乐的博客(二) 架构搭建
- 2023-02-16 244浏览
-
- B-Tree、B+Tree以及B-link Tree
- 2023-01-19 235浏览
-
- mysql面试题
- 2023-01-17 157浏览
-
- MySQL数据表简单查询
- 2023-01-10 101浏览