MySQL 性能调优——数据库监控

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/smartbetter/article/details/93887733

对于任何系统来说,监控都是重要的组成部分。数据库是一切系统的核心组件,数据库的稳定性从一定程度上决定了系统的稳定性,所以,对于数据库的监控,就显得尤为重要了。常见的开源监控软件有 Nagios、Zabbix。这些监控软件,或是提供了数据库监控插件,或是允许用户以插件的形式开发自己对数据库的监控脚本,并且支持的脚本语言也是多种多样的,用户完全可以按照自己的习惯,来选择自己的监控软件,以及编写适合自己的监控脚本。

本篇主要关注 MySQL 数据库我们都要监控些什么?和怎么对这些要监控的资源进行监控?

了解了这些之后,不管使用任何监控软件,都可以自己完成对 MySQL 脚本的开发与部署。

对于 MySQL 来说,最基本的监控应该包含以下内容:

  • 对数据库服务可用性进行监控(通过网络连接到数据库并且确定数据库是可以对外提供服务的);
  • 对数据库性能进行监控(QPS、TPS、并发线程数量的监控);
  • 对主从复制进行监控(主从复制链路状态的监控、主从复制延迟的监控、定期的确认主从复制的数据是否一致);
  • 对服务器资源的监控(磁盘空间的监控(无论是数据目录还是日志目录的空间被占满,都会导致 MySQL 不可用)、CPU 的使用情况、内存的使用情况、Swap 分区的使用情况以及网络 IO 的情况等);

1.数据可用性监控

首先我们先来看下如何确认数据库是否可以通过网络进行连接。使用 MySQL 的本地的 SQL 文件连接数据库服务器,并不意味着可以通过网络 TCP/IP 协议能连接到 MySQL。确认数据库是否可以通过网络进行连接,通常使用以下几种方式中的一种:

  • 方案一:利用 mysqladmin -umonitor_user -p -h ping 命令在远程服务器上执行,来确认被监控的服务器是否可以连接;
  • 方案二:利用 telnet ip db_port 命令手动确认被监控的服务器是否可以连接;
  • 方案三:使用程序通过网络建立数据库连接来确认被监控的服务器是否可以连接,这是最好的方式。

可以连接到数据库并不代表数据库就是可用的,所以还需要确认数据库是否可以读写。

如何确认数据库是否可读写?

  • 定期检查主数据库的 read_only 参数是否为 off;
  • 建立监控表并对表中数据进行更改;
  • 如果只是监控数据库是否可读只需要执行简单的查询 select @@version;

可以连接到MySQL 的线程数是有限制的,如何监控数据库的连接数?

show variables like 'max_connections';   //获取MySQL能接受最大连接数的数量
show global status like 'Threads_connected';   //获取系统变量Threads_connected的值,记录了当前数据库的连接数量

例如报警就可以当 Threads_connected / max_connections > 0.8 时,就需要报警。

2.数据性能监控

性能监控不同于可用性监控,性能监控更关注的是数据库性能的变化趋势,所以在进行性能监控的脚本开发时,就需要注意记录好性能监控过程中所采集到的数据库的状态信息,以便分析数据库性能变化趋势时使用。

对于性能监控来说,可能关注最多的就是 QPS 和 TPS。

QPS = (Queries2 - Queries1) / (Uptime_since_flush_status2 - Uptime_since_flush_status1)

TPS = ((Com_insert2 + Com_update2 + Com_delete2) - (Com_insert1+ Com_update1 + Com_delete1)) /
(Uptime_since_flush_status2 - Uptime_since_flush_status1)

这几个参数获取方式:

show global status like 'Queries'
show global status like 'Uptime_since_flush_status'
show global status like 'Com_insert'
show global status like 'Com_update'
show global status like 'Com_delete'

如何监控数据库的并发请求数量?

通常情况下,数据库系统的性能会随着并发处理请求数量的增加而下降。所以并发请求数量通常还需要和 CPU 的使用率等指标结合起来分析。

数据库当前并发请求数量可以通过 show global status like ‘Threads_running’ 获取。并发处理的数量通常会远小于同一时间连接到数据库的线程的数量。

通常情况下并发请求数量是很稳定的,如果我们发现某一时刻并发量突然间增大,那么就需要检查是否出现了数据库的异常,比如数据库出现大量阻塞的情况下,就很有可能出现这种现象。

如何监控 InnoDB 的阻塞?

查询阻塞时间超过 20 秒的 SQL:

SELECT b.trx_mysql_thread_id AS '被阻塞线程'
		,b.trx_query AS '被阻塞SQL'
		,c.trx_mysql_thread_id AS '阻塞线程'
		,c.trx_query AS '阻塞SQL'
		,(UNIX_TIMESTAMP()-UNIX_TIMESTAMP(c.trx_started)) AS '阻塞时间'
FROM information_schema.innodb_lock_waits a
JOIN information_schema.innodb_trx b ON a.requesting_trx_id=b.trx_id
JOIN information_schema.innodb_trx c ON a.blocking_trx_id=c.trx_id
WHERE (UNIX_TIMESTAMP()-UNIX_TIMESTAMP(c.trx_started))>20

3.主从复制监控

如果在我们的数据库架构中,大量依赖于 MySQL 的主从复制机制的话,那么主从复制的监控也就成了必不可少的部分了。

如何监控主从复制链路的状态?

对于主从复制的监控,基本都要依赖于 show slave status 命令。

如何监控主从复制延迟?

参与复制的主从服务器之间一定存在着一些延迟,正常的情况下延迟是非常小的,基本在 1 秒之内。所以对于应用来说,影响并不大,特别是对于一些主从延迟不敏感的应用。如果由于某种原因,主从服务器之间出现了很大的延迟,就会影响到应用的正常使用了。所以必须要对主从复制延迟进行一些监控。

如果发现从服务器之间的延迟持续的增大,那么就需要进行一些检查,查找原因并及时解决。一般情况下,可以通过下面的方法对主从复制延迟进行监控:

利用 show slave status 命令返回的信息:

Master_SSL_Cipher: 
Master_SSL_Key: 
Seconds_Behind_Master: 0
_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error: 
Last_SQL_Errno: 0

Seconds_Behind_Master 就是主从复制延迟的秒数。这种获取方法比较简单,但是结果并不准确,因为这个值是根据同步到从服务器上主服务器的 binlog 和已经在从服务器上重新执行过的 binlog 日志之间的时间差,所以会有很多种情况会导致数据不准确,例如当网络出现问题的时候,主服务器上还有大量的 binlog 没有同步到从服务器上,同时已经同步到从服务器上的 binlog 都已经被完全被重用完了,这种情况下,主从之间是存在着很大的延迟的,但是通过 show slave status 命令却不能发现这种延迟。

所以为了更加准确的发现延迟,就需要另外的方法:

这个方法需要使用多线程的程序同时对于主从服务器的状态来进行检查。主服务器上执行 show master status 命令来获取主服务器上的二进制日志文件信息和偏移量:

mysql> show master status \G
***************************** 1. row *****************************
File: mysql-bin.001099
Position: 302055050

从服务器上执行 show slave status 命令获取主服务器发送过来的二进制日志文件信息和偏移量:

Master_Log_File: mysql-bin.001099
Read_Master_Log_Pos: 301855050

以及在从服务器上执行 show slave status 命令获取已经传输完成的主服务器上二进制文件的信息和偏移量:

Exec_Master_Log_Pos: 301855050
Relay_Log_Space: 301855350

通过上面三个信息的对比,就可以知道主从服务器之间是否存在大量的延迟了。如果文件名(File 和 Master_Log_File)和偏移量(Position 和 Read_Master_Log_Pos)都一样,说明当前的主从不存在任何延迟的。

当每次修复完主从复制的时候,都要检查主从复制数据的一致性。那么如何验证主从复制的数据是否一致?

这里就需要使用到 Percona 公司发布的 MySQL 工具集中的 pt-table-checksum:

pt-table-checksum u=db_user,p='db_password' \
	--databases mysql \
	--replicate test.checksums

–databases 参数指定的是数据库的名字,–replicate 参数指定的是要在 test 库下创建 checksums 这张表,并且将数据写入到这张检测表中。需要注意的是,这条命令只需要在主库上运行就可以了,它会自动发现主库下所有从库信息,并对所有从库指定的数据库的数据来进行检测。

建立数据库账户可以使用:

GRANT SELECT,PROCESS,SUPER,REPLICATION SLAVE ON *.* TO 'db_user'@'ip' IDENTIFIED BY 'db_password';
展开阅读全文

没有更多推荐了,返回首页