MySQL巡检

操作系统层面

cpu监控

1[root@zst data]# sar -u 10 3Linux 2.6.32-642.el6.x86_64 (zst) 09/22/2017 _x86_64_ (8 CPU)10:26:44 AM  CPU %user %nice %system %iowait %steal %idle10:26:54 AM  all 0.55  0.00  0.41    5.61    0.03   93.40

内存监控

1[root@zst data]# sar -r 10 3Linux 2.6.32-642.el6.x86_64 (zst) 09/22/2017 _x86_64_ (8 CPU)10:28:36 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit10:28:46 AM 223084    32658252  99.32    143468    16549080 18774068 37.81

I/O监控

1[root@zst data]# sar -b 10 3Linux 2.6.32-642.el6.x86_64 (zst) 09/22/2017 _x86_64_ (8 CPU)10:30:25 AM       tps      rtps      wtps   bread/s   bwrtn/s10:30:35 AM     67.17     61.63      5.54  16169.99     86.20

系统SWAP监控

1[root@zst data]# sar -w 10 3Linux 2.6.32-642.el6.x86_64 (zst)  09/22/2017   _x86_64_10:31:56 AM    proc/s   cswch/s10:32:06 AM      0.00   2234.44

当然,查看当前的磁盘和内存使用情况df -h,free -m,是否使用numa和swap,或是否频繁交互信息等。当然,还有其他的监控项目,这里就不一一赘述了。 除此之外,还需要关注日志类信息,例如:

1/var/log/messages
2/var/log/dmesg

MySQL本身

MySQL本身的监控应该包含重点参数的检查,MySQL状态的检查,除此以外还应该包含自增id的使用情况(小心因为自增id使用满了 不能insert写入从而引发报警哦),及主从健康状态的巡检。

重点参数

1"innodb_buffer_pool_size""sync_binlog"'binlog_format''innodb_flush_log_at_trx_commit''read_only':
2'log_slave_updates''innodb_io_capacity''query_cache_type''query_cache_size''max_connections''max_connect_errors''server_id'

MySQL的状态

例如:每秒的tps、qps,提交了多少事务、回滚了多少事务、打开文件数、打开表数、连接数、innodb buffer使用率,及锁等待等等。 首先,查看mysql状态

1mysql> show full processlis;2mysql> show global status;3mysql> show engine innodb status\G

wait事件

Innodb_buffer_pool_wait_free
Innodb_log_waits                

MySQL锁监控

#表锁
Table_locks_waited
Table_locks_immediate
#行锁
Innodb_row_lock_current_waits,当前等待锁的行锁数量
Innodb_row_lock_time,请求行锁总耗时
Innodb_row_lock_time_avg,请求行锁平均耗时
Innodb_row_lock_time_max,请求行锁最久耗时
Innodb_row_lock_waits,行锁发生次数
#还可以定时收集INFORMATION_SCHEMA里面的信息:
INFORMATION_SCHEMA.INNODB_LOCKS; 
INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
#临时表/临时文件
Created_tmp_disk_tables/Created_tmp_files
#打开表/文件数
Open_files/Open_table_definitions/Open_tables
#并发连接数
Threads_running /Threads_created/Threads_cached
Aborted_clients 
#客户端没有正确关闭连接导致客户端终止而中断的连接数
Aborted_connects

Binlog

1Binlog_cache_disk_use 
2使用临时二进制日志缓冲但超过 binlog_cache_size 值并使用临时文件
3Binlog_cache_use
4使用临时二进制日志缓冲的事务数量
5Binlog_stmt_cache_disk_use
6当非事务语句使用二进制日志缓存
7Binlog_stmt_cache_use
8使用二进制日志缓冲非事务语句数量

链接数

1Connections 
2试图连接到(不管成不成功)mysql服务器的链接数

临时表

1Created_tmp_disk_tables
2服务器执行语句时,在硬盘上自动创建的临时表的数量,是指在排序时,内存不够用(tmp_table_size小于需要排序的结果集),所以需要创建基于磁盘的临时表进行排序
3Created_tmp_files
4服务器执行语句时自动创建的内存中的临时表的数量

索引

 1Handler_commit 内部交语句
 2Handler_rollback 内部 rollback语句数量
 3Handler_read_first  索引第一条记录被读的次数,如果高,则它表明服务器正执行大量全索引扫描
 4Handler_read_key  根据索引读一行的请求数,如果较高,说明查询和表的索引正确
 5Handler_read_last 查询读索引最后一个索引键请求数
 6Handler_read_next 按照索引顺序读下一行的请求数
 7Handler_read_prev 按照索引顺序读前一行的请求数
 8Handler_read_rnd 根据固定位置读一行的请求数,如果值较高,说明可能使用了大量需要mysql扫整个表的查询或没有正确使用索引
 9Handler_read_rnd_next 在数据文件中读下一行的请求数,如果你正进行大量的表扫,该值会较高
10Open_table_definitions 
11被缓存的.frm文件数量
12Opened_tables
13已经打开的表的数量,如果较大,table_open_cache值可能太小
14Open_tables
15当前打开的表的数量
16Queries
17已经发送给服务器的查询个数
18Select_full_join 
19没有使用索引的联接的数量,如果该值不为0,你应该仔细检查表的所有
20Select_scan
21对第一个表进行完全扫的联接的数量
22Slow_queries 
23查询时间超过long_query_time秒的查询个数
24Sort_merge_passes
25排序算法已经执行的合并的数量,如果值较大,增加sort_buffer_size大小

线程

1Threads_cached 线程缓存内的线程数量
2Threads_connected 当前打开的连接数量
3Threads_created 创建用来处理连接的线程数
4Threads_running 激活的(非睡眠状态)线程数

MySQL自增id的使用情况

1mysql> SELECT table_schema,table_name,engine, Auto_increment
2 FROM information_schema.tables where 
3  INFORMATION_SCHEMA.TABLE_SCHEMA
4 not in ("INFORMATION_SCHEMA" ,"PERFORMANCE_SCHEMA", "MYSQL", "SYS")

存储引擎是否为innodb

1mysql> SELECT TABLE_SCHEMA,TABLE_NAME,ENGINE FROM
2 INFORMATION_SCHEMA.TABLES WHERE
3 ENGINE != 'innodb' AND
4 TABLE_SCHEMA NOT IN
5  ("INFORMATION_SCHEMA" ,"PERFORMANCE_SCHEMA", "MYSQL", "SYS");

MySQL主从检测

#主从状态
mysql> show slave status\G
#主从是否延迟
Master_Log_File == Relay_Master_Log_File 
&& Read_Master_Log_Pos == Exec_Master_Log_Pos

高可用层面

MHA && keepalived

观察日志看是否有频繁主从切换,如果有的话就分析一下是什么原因导致频繁切换?

中间件的巡检

mycat && proxysql

这些中间件的巡检,首先参考系统巡检,再看一下中间件本身的日志类和状态类信息,网络延迟或丢包的检查,也是必须要做工作。

本文分享自微信公众号 - 有暗香盈袖c(Born--To_Die)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-12-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • MYSQL 小内存, 大问题

    每种数据库都有自己的管理内存的方法,MYSQL 管理内存(仅仅讨论 INNODB 数据库引擎)的方法大部分都关注在 innodb_buffer_pool_siz...

    AustinDatabases
  • 【DB笔试面试690】在Oracle中,什么是分布式事务处理?

    现代数据库系统往往伴随着复杂的结构和环境,其中,分布式数据库组成是一个重要方面。系统后台的数据库系统不再是由单个数据库构成,而是由多台独立数据库、甚至是多台异构...

    小麦苗DBA宝典
  • Spring Boot2 系列教程(二十九)Spring Boot 整合 Redis

    经过 Spring Boot 的整合封装与自动化配置,在 Spring Boot 中整合Redis 已经变得非常容易了,开发者只需要引入 Spring Data...

    江南一点雨
  • mysql基本操作以及python控制mysql(3)–python控制

    本文的测试代码,放在github上。https://github.com/luyishisi/The_python_code.git   中的python-my...

    十四君
  • mysql-使用load两分钟-千万行表快速迁移合成亿行总表

    使用load这种底层的迁移方式,会让移动速度非常快。将已经导出为txt的7.2G数据合成为接近1亿行的总表,大致耗时2分钟。

    十四君
  • mysql基本操作以及python控制mysql(1)–环境安装

    学习了虫师的博文,最近准备将人脸识别器提升到网站阅读签到信息的状态。所以打算将识别器获取的签到信息再放到数据库中,so。。加油么么哒。。

    十四君
  • docker 安装 mysql5.7

    用户4478423
  • 一篇文章讲透MySQL为什么要用B+树实现索引

    索引这个词,相信大多数人已经相当熟悉了,很多人都知道MySQL的索引主要以B+树为主,但是要问到为什么用B+树,恐怕很少有人能把前因后果讲述的很完整。本文就来从...

    用户1260737
  • 行锁:InnoDB 替代 MyISAM 的重要原因

    MySQL 5.5 之前的默认存储引擎是 MyISAM,5.5 之后改成了 InnoDB。InnoDB 后来居上最主要的原因就是:

    jeanron100
  • Microsoft Access:拥有不死之身的数据库

    只要有过一点数据库概念的人几乎都接触过Access。跟复杂的专业数据库相比,它简单易用,几乎不用做什么设置就能马上使用。但是另一方面它又极其受限,只要你想扩大一...

    IT大咖说

扫码关注云+社区

领取腾讯云代金券