高可用设计之MySQL状态性能监控-【学习笔记】

 

 

高可用设计之 MySQL状态性能监控

 

 

           一个经过高可用可扩展设计的MySQL 数据库集群，如果没有一个足够精细足够强大的监控系统，同样可能会让之前在高可用设计方面所做的努力功亏一篑。一个系统，无论如何设计如何维护，都无法完全避免出现异常的可能，监控系统就是根据系统的各项状态的分析，让我们能够尽可能多的提前预知系统可能会出现的异常状况。即使没有及时发现将要发生的异常，也要在异常出现后的第一时间知道系统已经出现异常，否则之前的设计工作很可能就白费了。

 

 

一、健康状态监控

 

 

1、主机健康状态监控

在数据库运行环境，需要关注的主机状态主要有网络通信、系统软硬件错误、磁盘空间、内存使用，进程数量等。

 

● 网络通信：网络通信基本上可以说是最容易检测的了，基本上只需要通过网络ping就可以获知是否正常。如果还不放心，或者所属网段内禁用了ping，也可以从监控主机进行固定端口的telnet 尝试或者ssh 登录尝试。由于网络出现故障的时候被动的信息采集方式也会失效（无法与外界通信），所以网络通信的检测主要还是依靠主动检测。

● 系统软硬件错误：系统软硬件错误，一般只能通过检测各种日志文件的信息来实现，如主机的系统日志中基本上都会记录下OS 能够检测到的大部分错误信息，如硬件错误，IO 错误等等。我们一般使用文本监控软件，如sec、logwatch 等日志监控专用软件，通过配置相应的匹配规则，从日志文件中捕获满足条件的错误信息，再发送给信息分析模块。

● 磁盘空间：对于磁盘空间的使用状况监控，我们通过最简单的shell 脚本就可以轻松搞定，得出系统中各个分区的当前使用量，剩余可用空间。积累一定时间段的信息之后，很容易就能得出系统数据量增长趋势。

● 内存使用：系统物理内存使用量的信息采集同样非常简单，只需要一个基本的系统命令“free”，就可以获得当前系统内存总量，剩余使用量，以及文件系统的buffer和cache 两者使用量。而且，除了物理内存使用情况，还可以得到swap 使用量。通过shell 脚本对这些输出信息进行简单的处理，即可获得足够的信息。当然，如果你希望获取更多的信息，如当前系统使用内存最多的进程，可能还需要借助其他命令（如：top）才能得到。当然，不同的OS 在输出值的处理方面可能会稍有区别，

● 进程数量：系统进程总数，或者某个用户下的进程数，都可以通过“ps”命令经过简单的处理来获得。如获取mysql 用户下的进程总数：
ps -ef | awk '{print $1}' | grep "mysql" | grep -v "grep" | wc -l
如要获得更为详细的某个或者某类进程的信息，同样可以根据上述类似命令得到。

 

 

 2、 数据库健康状态信息

除了主机的状态信息之外，MySQL Server 自身也有很多的状态信息需要监控。

 

●服务端口（3306）：MySQL 端口是一个必不可少的监控项，因为这直接反应了MySQLServer 是否能够正常为外部请求提供服务。有些时候从主机层面来检查MySQL 可能很正常，可外部应用却无法通过TCP/IP 连接上MySQL。产生这种现象的原因可能有多种，如网络防火墙的问题，网络连接问题，MySQL Server 所在主机的网络设置问题，以及MySQL 本身问题都可能造成上述现象。服务端口状态的监控和主机网络连接的监控同样非常简单，只需要对3306 端口进行telnet 尝试即可。通过对3306 端口的telnet 尝试，同时还可以完成对主机网络状况的监控。

● socket 文件：对于有些环境来说，socket 的状态监控可能并不如网络服务端口的监控重要，因为很多MySQL Server 的连接并不会通过本地socket 进行连接。但是也有不少小型应用（或者某些特殊的应用）还是和MySQL 数据库处于同一台主机上，并通过本地socket 连接。另外，不少本地被动监控的信息采集脚本也是通过本地socket 来连接MySQL Server。本地socket 的监控最好是通过本地socket 的实际连接尝试的方式，虽然也可以通过检测socket 文件是否存在来监控，但是即使socket 文件确实存在，也并不一定就可以确保能够通过socket 正常登录。毕竟，在某些异常情况下，socket 文件存在并不代表就可以正常使用。

● mysqld 和mysqld_safe 进程：mysqld 进程是MySQL Server 最核心的进程。mysqld 进程crash 或者出现异常，MySQL Server 基本上也就无法正常提供服务了。当然，如果我们是通过mysqld_safe 来启动MySQL Server，则mysqld_safe会帮助我们来监控mysqld 进程的状态，当mysqld 进程crash 之后，mysqld_safe 会马上帮助我们重启mysqld 进程。但前提是我们必须通过mysqld_safe 来启动MySQL Server，这也是MySQL AB 强烈推荐的做法。如果我们通过mysqld_safe 来启动MySQL Server，那么我们也必须对mysqld_safe 进程进行监控。
无论是mysqld 还是mysqld_safe 进程的监控，都可以通过ps 命令来得到实现：
ps -ef | grep "mysqld_safe" | grep -v "grep"
和
ps -ef | grep "mysqld" | grep -v "mysqld_safe"| grep -v "grep"

● Error log：Error log 的监控目的主要是即时检测MySQL Server 运行过程中发生的各种错误，如连接异常，系统bug 等。Error log 的监控和系统软硬件状态的监控一样，都是通过对文本文件内容的监控来实现的。同样使用文本监控软件，通过配置各种错误信息的匹配规则来捕获日志文件中的错误信息。

● 复制状态：如果我们的MySQL 数据库环境使用了MySQL Replication，就必须增加对Slave 复制状态的监控。对Slave 的复制状态的监控包括对IO 线程和SQL线程二者的运行状态的监控。当然，如果希望能够监控Replication 更多的信息，如两个线程各自运行的进度等，同样可以在Slave 节点上执行相应命令轻松得到，
如下：
xxx@localhost : (none) 04:30:38> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Connecting to master
Master_Host: 10.0.77.10
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 196
Relay_Log_File: mysql-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB: example,abc
Replicate_Ignore_DB: mysql,test
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 196

Relay_Log_Space: 106
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
通过如上命令，我们可以获取获取关于Replication 的各种信息，不论是复制的监控状况，还是复制的进度，都可以很容易的获取。上面输出的各项内容中，最重要的内容就是Slave_IO_Running 和Slave_SQL_Running 这两项，分别代表了IO线程和SQL 线程的运行状态，如上面的输出就表明SQL 线程运行正常，但是IO线程并没有运行。

 

二、性能状态监控

         性能状态的监控和健康状态的监控有一定的区别，他所反应出来的主要是系统当前提供服务的响应速度，影响的更多是客户满意度。性能状态的持续恶化，则可能升级为系统不可用，也就是升级为健康状态的异常。如系统的过度负载，可能导致系统的crash。性能状态的监控同样可以分为主机和数据库层面。

 

1、主机性能状态监控

主机性能状态主要表现在三个方面：CPU、IO 以及网络，可以通过以下五个监控量来监控。

 

● 系统load 值：系统load 所包含的最关键含义是CPU 运行等待的数量，也就是侧面反应了CPU 的繁忙程度。只不过load 值并不直接等于等待队列中的进程数量。load 值的监控也非常简单，通过运行uptime 命令即可获得当前时间之前1 秒、5秒和15 秒的load 平均值。
sky@sky:~$ uptime
17:27:44 up 4:12, 3 users, load average: 0.87, 0.66, 0.61
如上面输出内容中的“load average: 0.87, 0.66, 0.61”中的三个数字，分别代表了1 秒、5 秒和15 秒的load 平均值。一般来说，load 值在不超过系统物理cpu 数目（或者cpu 总核数）之前，系统不会有太大问题。

● CPU 使用率：CPU 使用率和系统load 值一样，从另一个角度反应出CPU 的总体繁忙程度，只不过可以反应出更为详细的信息，如当前空闲的CPU 比率，系统占用的CPU 比率，用户进程占用的CPU 比率，处于IO 等待的CPU 比率等。CPU 使用率可以通过多种方法来获取，最为常用的方法是使用命令top 和vmstat来获取。当然，不同的OS 系统上的top 和vmstat 的输出可能有些许不同，且输出格式也可能各不一样，如Linux 下的top 包含IO 等待的CPU 占用律，但是Solaris 下的top 就不包含，各位读者朋友请根据自己的OS 环境进行相应的处理。

● 磁盘IO 量：磁盘IO 量直接反应出了系统磁盘繁忙程度，对于数据库这种以IO操作为主的系统来说，IO 的负载将直接影响到系统的整体响应速度。磁盘IO 量同样也可以通过vmstat 来获取，当然，我们还可以通过iostat 来获得更为详细的系统IO 信息。包括各个磁盘设备的iops，每秒吞吐量等。

● swap 进出量：swap 的使用主要表现了系统在物理内存不够的情况下使用虚拟内存的情况。当然，有些时候即使系统还有足够物理内存的时候，也可能出现使用swap的情况，这主要是由系统内核中的内存管理部分来决定。如果希望系统完全不使用swap，最直接的办法就是关闭swap。当然，前提条件是我们必须要有足够的物理内存，否则很可能会出现内存不足的错误，严重的时候可能会造成系统crash。swap 使用量的总体情况可以通过free 命令获得，但free 命令只能获得当前系统swap 的总体使用量。如果希望获得实时的swap 使用变化，还是得依赖vmstat来得到。vmstat 输出信息中包含了每秒swap 的进出量，当然，不同的OS 输出可能存在一定的差异。

● 网络流量：作为数据库系统，网络流量也是一个不容忽视的监控点。毕竟数据库系统的数据进出比普通服务器的量还是要大很多的。不论是总体吞吐量还是网络iops，都需要给予一定的关注。当然，一般非数据仓库类型的数据库，网络流量成为瓶颈的可能性还是比较小的。

网络流量的监控很少有系统自带的命令可以直接完成，而需要自行编写脚本或者通过一些第三方软件来获取数据。当然，通过对网络交换机的监控，也可以获得非常详细的网络流量信息。自行编写脚本可以通过调用ifconfig 命令来计算出基本准确的网络流量信息。第三方软件如ifstat、iftop 和nload 等则是需要另外安装的监控linux 下网络流量第三方软件，三者各有特点。

 

 

2、数据库性能状态监控

MySQL 数据库的性能状态监控点非常之多，其中很多量都是我们不能忽视的必须监控的量，且90% 以上的内容可以在连接上MySQL Server 后执行“SHOW /*!50000 GLOBAL */STATUS” 以及“SH