tcpdump在mySQL数据库中的应用实践

vlambda
2020-05-01

tcpdump在mySQL数据库中的应用实践

一、概述

tcpdump在我们平时运维中充当了很重要的角色，对复杂问题的排查、分析起到了至关重要的作用，确实为运维中的一大利器。

用简单的话来定义tcpdump，就是：dump the traffic on a network，根据使用者的定义对网络上的数据包进行截获的包分析工具。本文主要从两个方面介绍tcpdump，首先是介绍下tcpdump的使用方式，然后介绍下tcpdump在mySQL数据库运维过程中具体实践，如果DBA能熟练的使用tcpdump，在运维工作中一定如虎添翼

二、参数介绍

命令格式：

1.-c:指定要抓取的包数量，抓取X个包后就停止。

2.-i:interface：指定tcpdump需要监听的窗口，默认会抓取第一个网络接口。指定为any代表抓取所有网卡上的包。

3.-P:指定要抓取的包是流入还是流出的包，具体值”in”、”out”和”inout”,默认为”inout”。

4.-s:设置显示前多少个字节的包内容(snaplength)。设置为0代表显示完整的包内容。

5.-v,-vv,-vvv:详细！更详细！再详细些！冗余输出包的信息。

6.-w:结果文件输出的位置。结果文件是以tcpdump的格式存储，可以用Wireshark工具解析。

expression表达式

一个基本的表达式单元格式为:”proto dir type”

类型type

host，net，port，portrange

例如：host 192.168.1.1，net 128.2，port 20

目标dir

src，dst，src or dst，src and dst

协议proto

tcp，udp，icmp，若未给定协议类型，则匹配所有可能的类型。

三、使用示例

1. 截取所有192.168.94.128的主机收到和发出的所有数据包。

#tcpdump host 192.168.94.128

2．监听指定主机192.168.94.128和指定网卡上的数据包

#tcpdump host 192.168.94.128 -i eth0

3．监听指定网卡、端口的数据包

#tcpdump –i eth0 port 8080

4．监听所有发送到192.168.94.128的数据包

#tcpdump -i eth0 dst host 192.168.94.128

5．监听192.168.94.128和192.168.94.129或者192.168.94.130间的通讯包

# tcpdump -i eth0 host 192.168.94.128 and \(192.168.94.129 or 192.168.94.130\)

6. 监听本机3306端口的包，抓取完整包，并输出到tmp下

#tcpdump -s0 -vv port 3306 -w /tmp/`hostname`.pcap

四、在MySQL中的应用

案例一

第一个想写的是mySQL的建链和断链过程，本人在实际运维过程中遇到过由于网络原因导致的建链异常的情况，当你怀疑网络有问题时可以通过tcpdump进行分析。那我们先来一起看下MySQL的的三次握手和四次挥手吧（关于TCP协议中的三次握手和四次挥手的原理需要自行查询）。

首先我们在MySQL服务器上执行监听命令: tcpdump -i eth0 -s0 port 3306 -w 1513.pcap

tcpdump在mySQL数据库中的应用实践

可以看到我们一共抓了44个包，我们将pcap文件下载到电脑后，用Wireshark进行分析。

tcpdump在mySQL数据库中的应用实践

从图上可以看出192.168.94.1是客户端，192.168.94.128是MySQL服务端，第一个包是客户端向服务端发送了一个SYN包（Sequence 1803591875）请求建链，第二个包是服务端对客户端的请求的确认，发送了ACK包（Sequence 1803591876），同时也给客户端发送了一个SYN包（Sequence 93871103），第三个包是客户端收到服务端的SYN+ACK包后，对服务端进行了回应，发送了ACK包（Sequence 93871104），至此客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成了三次握手。完成三次握手，客户端与服务器开始传送数据。

如果客户端发送SYN包之后，一直收不到服务端的ACK包，这时候就要排查下MySQL服务器以及中间网络是否正常了。

tcpdump在mySQL数据库中的应用实践

接下来我们再看下MySQL的断链过程。首先是客户端发送了FIN包（Sequence 1803593470），服务端收到后对客户端的请求进行确认，发送给客户端了一个ACK包（Sequence 1803593471），此时客户端只能接收数据而不能发送数据了。紧接着服务端向客户端发送了一个FIN包（Sequence 93871103），客户端收到FIN包后发ACK进行确认，至此四次挥手完成，链接关闭。

如果你的应用客户端有大量CLOSE_WAIT状态的链接，很有可能就是MySQL服务异常重启了。

案例二

在实际的运维过程中，有时业务反应慢，应用端也能看到SQL执行的时间比较长，但是数据库的慢日志中并没有抓到慢SQL。首先我们能想到的原因可能是SQL执行虽然慢但是还没有达到long_query_time定义的基线，或者是数据库执行很快，但是中间的网络出现了异常，亦或者就是数据库执行SQL的时间慢。这种问题该如何定位呢？这时候仅仅说数据库没有问题是没有说服力的，必须拿出真实数据来自证其说。这时候就可以通过tcpdump来定位问题了。