mysql 监控

mysql监控

前几天跟几我的讨论到MySQL监控这块。发现自身有所欠缺，因此最近加班加点研究了一下。写个博文总结一下。

通常来讲对于mysql监控，会监控主库、从库的可用性。主从复制状态监控、数据库性能监控、数据库日志监控。

对于可用性的监控，能够经过按期去执行sql实现。这里须要注意的是主库须要监控可写入性。

数据库性能的监控，就是去监控数据库的一些状态值，对这些状态进行直接、间接（不一样状态值计算）的监控。这个须要对mysql的一些参数有详细的了解。

重点来讲说mysql复制监控这块:

不少人都知道能够经过监控show slave status\G命令输出的Seconds_Behind_Master参数的值来判断，是否有发生主从延时。

同时不少人也知道这个不许确，可是为何不许确呢？？？？

首先来看看show slave status\G重点项：

• Slave_IO_Running：该参数可做为io_thread的监控项，Yes表示io_thread的和主库链接正常并能实施复制工做，No则说明与主库通信异常，多数状况是由主从间网络引发的问题；
• Slave_SQL_Running：该参数表明sql_thread是否正常，YES表示正常，NO表示执行失败，具体就是语句是否执行经过，常会遇到主键重复或是某个表不存在。
• Seconds_Behind_Master：从库落后主库的时间；

1. NULL—表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No，而非Yes。
2.  0 — 表示主从复制良好。
3.  正值 — 表示主从已经出现延时，数字越大表示从库落后主库越多。

Seconds_Behind_Master计算方式：

是经过比较sql_thread执行的event的timestamp和io_thread复制好的event的timestamp(简写为ts)进行比较，而获得的这么一个差值。

Seconds_Behind_Master的计算方式可能带来的问题：
relay-log和主库的bin-log里面的内容彻底同样，在记录sql语句的同时会被记录上当时的ts，因此比较参考的值来自于binlog，其实主从没有必要与NTP进行同步，也就是说无需保证主从时钟的一致。其实比较动做真正是发生在io_thread与sql_thread之间，而io_thread才真正与主库有关联，因而，问题就出来了，当主库I/O负载很大或是网络阻塞，io_thread不能及时复制binlog（没有中断，也在复制），而sql_thread一直都能跟上io_thread的脚本，这时Seconds_Behind_Master的值是0，也就是咱们认为的无延时，可是，实际上不是，你懂得。这也就是为何你们要批判用这个参数来监控数据库是否发生延时不许的缘由，可是这个值并非老是不许，若是当io_thread与master网络很好的状况下，那么该值也是颇有价值的。以前，提到Seconds_Behind_Master这个参数会有负值出现，咱们已经知道该值是io_thread的最近跟新的ts与sql_thread执行到的ts差值，前者始终是大于后者的，惟一的肯能就是某个event的ts发生了错误，比以前的小了，那么当这种状况发生时，负值出现就成为可能。

因此简单点说，当IO线程有延迟的时候Seconds_Behind_Master这个值是不许的。

那么如何正确查看以及监控MySQL主从？

一、根据主从POS点比较

二、在主库创建监控表（心跳），定时写入（带时间戳）。去从库中查询对应的记录，就能够依据记录内的时间戳信息来确认延时了多少。

第二种方式单独细说。

详细说下第一种：

先说下主从查看延迟的流程。

1. 首先看 Relay_Master_Log_File 和 Master_Log_File 是否有差别；
2. 若是Relay_Master_Log_File 和 Master_Log_File 是同样的话，再来看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差别，对比SQL线程比IO线程慢了多少个binlog事件；
3. 若是Relay_Master_Log_File 和 Master_Log_File 不同，那说明延迟可能较大，须要从MASTER上取得binlog status，判断当前的binlog和MASTER上的差距；

在监控节点上，对MASTER和slave同时发起SHOW BINARY LOGS和SHOW slave STATUS\G的请求，最后判断两者binlog的差别，以及 Exec_Master_Log_Pos 和Read_Master_Log_Pos 的差别。

例如：
在MASTER上执行SHOW BINARY LOGS 的结果是：
+------------------+--------------+
| Log_name | File_size |
+------------------+--------------+
| mysql-bin.000009 | 1073742063 |
| mysql-bin.000010 | 107374193 |
+------------------+--------------+
而在slave上执行SHOW slave STATUS\G 的结果是：

Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos: 668711237
Relay_Master_Log_File: mysql-bin.000009
slave_IO_Running: Yes
slave_SQL_Running: Yes
***
Exec_Master_Log_Pos: 654409041

***
Seconds_Behind_Master: 3296
***
这时候，slave实际的延迟应该是：
mysql-bin.000009 这个binlog中的binlog position 1073742063 和 slave上读取到的binlog position之间的差别延迟，即：
1073742063 - 654409041 = 419333022 个binlog event
而且还要加上 mysql-bin.000010这个binlog已经产生的107374193个binlog event，共
107374193 + 419333022 = 526707215 个binlog event

   

附：

show slave status 参数详解 

 

Slave_IO_State：等待 master 发生事件

Master_Host：当前的主服务器主机
Master_User：被用于链接主服务器的当前用户
Master_Port：当前的主服务器接口
Connect_Retry：master-connect-retry选项的当前值
Master_Log_File：I/O线程当前正在读取的主服务器二进制日志文件的名称
Read_Master_Log_Pos：在当前的主服务器二进制日志中，I/O线程已经读取的位置
Relay_Log_File：SQL线程当前正在读取和执行的中继日志文件的名称
Relay_Log_Pos：在当前的中继日志中，SQL线程已读取和执行的位置
Relay_Master_Log_File：由SQL线程执行的包含多数近期事件的主服务器二进制日志文件的名称
Slave_IO_Running：I/O线程是否被启动并成功地链接到主服务器上
Slave_SQL_Running：SQL线程是否被启动
Replicate_Do_DB：replicate-do-db选项的当前值
Replicate_Ignore_DB：replicate-ignore-db选项的当前值
Replicate_Do_Table：replicate-do-table选项的当前值
Replicate_Ignore_Table：replicate-ignore-table选项的当前值
Replicate_Wild_Do_Table：replicate-wild-do-table选项的当前值
Replicate_Wild_Ignore_Table：replicate-wild-ignore_table选项的当前值
Last_Errno：最近一次错误码
Last_Error：最近一次错误内容
Skip_Counter：最近被使用的用于SQL_SLAVE_SKIP_COUNTER的值
Exec_Master_Log_Pos：来自主服务器的二进制日志的由SQL线程执行的上一个时间的位置（Relay_Master_Log_File）。在主服务器的二进制日志中的(Relay_Master_Log_File,Exec_Master_Log_Pos)对应于在中继日志中的(Relay_Log_File,Relay_Log_Pos)
Relay_Log_Space：全部原有的中继日志结合起来的总大小
Until_Condition：若是没有指定UNTIL子句，则没有值。若是从属服务器正在读取，直到达到主服务器的二进制日志的给定位置为止，则值为Master。若是从属服务器正在读取，直到达到其中继日志的给定位置为止，则值为Relay
Until_Log_File：用于指示日志文件名，日志文件名和位置值定义了SQL线程在哪一个点停止执行
Until_Log_Pos：用于指示日志位置值，日志文件名和位置值定义了SQL线程在哪一个点停止执行
Master_SSL_Allowed：若是容许对主服务器进行SSL链接，则值为Yes。若是不容许对主服务器进行SSL链接，则值为No。若是容许SSL链接，可是从属服务器没有让SSL支持被启用，则值为Ignored。
Master_SSL_CA_File：master-ca选项的当前值
Master_SSL_CA_Path：master-capath选项的当前值
Master_SSL_Cert：master-cert选项的当前值
Master_SSL_Cipher：master-cipher选项的当前值
Master_SSL_Key：master-key选项的当前值
Seconds_Behind_Master：本字段是从属服务器“落后”多少的一个指示。当从属SQL线程正在运行时（处理更新），本字段为在主服务器上由此线程执行的最近的一个事件的时间标记开始，已通过的秒数。当此线程被从属服务器I/O线程遇上，并进入闲置状态，等待来自I/O线程的更多的事件时，本字段为零。总之，本字段测量从属服务器SQL线程和从属服务器I/O线程之间的时间差距，单位以秒计。若是主服务器和从属服务器之间的网络链接较快，则从属服务器I/O线程会很是接近主服务器，因此本字段可以十分近似地指示，从属服务器SQL线程比主服务器落后多少。若是网络较慢，则这种指示不许确；从属SQL线程常常会遇上读取速度较慢地从属服务器I/O线程，所以，Seconds_Behind_Master常常显示值为0。即便I/O线程落后于主服务器时，也是如此。换句话说，本列只对速度快的网络有用。即便主服务器和从属服务器不具备相同的时钟，时间差计算也会起做用（当从属服务器I/O线程启动时，计算时间差。并假定今后时之后，时间差保持不变）。若是从属SQL线程不运行，或者若是从属服务器I/O线程不运行或未与主服务器链接，则Seconds_Behind_Master为NULL（意义为“未知”）。举例说明，若是在从新链接以前，从属服务器I/O线程休眠了master-connect-retry秒，则显示NULL，由于从属服务器不知道主服务器正在作什么，也不能有把握地说落后多少。本字段有一个限制。时间标记经过复制被保留，这意味着，若是一个主服务器M1自己是一个从属服务器M0，则来自M1的binlog的任何事件（经过复制来自M0的binlog的事件而产生），与原事件具备相同的时间标记。这可使MySQL成功地复制TIMESTAMP。可是，Seconds_Behind_Master的缺点是，若是M1也收到来自客户端的直接更新，则值会随机变化，由于有时最近的M1时间来自M0，有时来自直接更新，最近的时间标记也是如此。