怎么监控mysql表操作 mysql 实时监控

mysql 如何监控表结构修改Online DDL 工具:pt-osc
对于 MySQL Online DDL 目前主流的有三种工具:
原生 Online DDL;
pt-osc(online-schema-change),
gh-ost
本文主要讲解 pt-online-schema-change 的使用以及三种工具的简单对比 。
一、原理及限制
1.1 原理
1. 创建一个与原表结构相同的空表 , 表名是 _new 后缀;
2. 修改步骤 1 创建的空表的表结构;
3. 在原表上加三个触发器:delete/update/insert,用于 copy 数据过程中,将原表中要执行的语句在新表中执行;
4. 将原表数据以数据块(chunk)的形式 copy 到新表;
5. rename 原表为 old 表,并把新表 rename 为原表名,然后删除旧表;
6. 删除触发器 。
如何监控MySQL首先介绍下 pt-stalk怎么监控mysql表操作,它是 Percona-Toolkit 工具包中的一个工具,说起 PT 工具包大家都不陌生,平时常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于这个工具包,这里就不多介绍了 。
pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息,这其中包括:
1. OS 层面的 CPU、IO、内存、磁盘、网络等信息;
2. MySQL 层面的行锁等待、会话连接、主从复制,状态参数等信息 。
而且 pt-stalk 是一个 Shell脚本,对于怎么监控mysql表操作我这种看不懂 perl 的人来说比较友好,脚本里面的监控逻辑与监控命令也可以拿来参考,用于构建自己的监控体系 。
三、使用
接着我们来看下如何使用这个工具 。
pt-stalk 通常以后台服务形式监控 MySQL 并等待触发条件,当触发条件时收集相关诊断数据 。
触发条件相关的参数有以下几个:
function:
° 默认为 status,代表监控 SHOW GLOBAL STATUS 的输出;
° 也可以设置为 processlist,代表监控 show processlist 的输出;
variable:
° 默认为 Threads_running , 代表 监控参数,根据上述监控输出指定具体的监控项;
threshold:
° 默认为 25,代表 监控阈值,监控参数超过阈值 , 则满足触发条件;
° 监控参数的值非数字时,需要配合 match 参数一起使用,如 processlist 的 state 列;
cycles:
° 默认为 5,表示连续观察到五次满足触发条件时 , 才触发收集;
连接参数:host、password、port、socket 。
其他一些重要参数:
iterations:该参数指定 pt-stalk 在触发收集几次后退出,默认会一直运行 。
run-time:触发收集后,该参数指定收集多长时间的数据,默认 30 秒 。
sleep:该参数指定在触发收集后,sleep 多久后继续监控 , 默认 300 秒 。
interval:指定状态参数的检查频率,判断是否需要触发收集,默认 1 秒 。
dest:监控数据存放路径,默认为 /var/lib/pt-stalk 。
retention-time :监控数据保留时长,默认 30 天 。
daemonize:以后台服务运行,默认不开启 。
log:后台运行日志,默认为 /var/log/pt-stalk.log 。
collect:触发发生时收集诊断数据 , 默认开启 。
° collect-gdb:收集 GDB 堆栈跟踪,需要 gdb 工具 。
° collect-strace:收集跟踪数据,需要 strace 工具 。
° collect-tcpdump:收集 tcpdump 数据,需要 tcpdump 工具 。
如何监控MySQL性能一怎么监控mysql表操作 , 获取mysql用户下的进程总数
ps -ef | awk '{print $1}' | grep "mysql" | grep -v "grep" | wc-1
二 , 主机性能状态
# uptime
[root@ ~]# uptime
13:05:52 up 53 days, 52 min,1 user,load average: 0.00, 0.00, 0.00
三,CPU使用率
# top

# vmstat
四,磁盘IO量
# vmstat 或 # iostat
五 , swap进出量[内存]
# free
六,数据库性能状态
(1)QPS(每秒Query量)
QPS = Questions(or Queries) / seconds
mysqlshow /*50000 global */ status like 'Question';
(2)TPS(每秒事务量)
TPS = (Com_commitCom_rollback) / seconds
mysqlshow status like 'Com_commit';
mysqlshow status like 'Com_rollback';
(3)key Buffer 命中率
key_buffer_read_hits = (1-key_reads / key_read_requests) * 100%
key_buffer_write_hits = (1-key_writes / key_write_requests) * 100%
mysql show status like 'Key%';
(4)InnoDB Buffer命中率
innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) * 100%
mysql show status like 'innodb_buffer_pool_read%';
(5)Query Cache命中率
Query_cache_hits = (Qcahce_hits / (Qcache_hitsQcache_inserts )) * 100%;
mysql show status like 'Qcache%';
(6)Table Cache状态量
mysql show status like 'open%';
(7)Thread Cache 命中率
Thread_cache_hits = (1 - Threads_created / connections ) * 100%
mysql show status like 'Thread%';
mysql show status like 'Connections';
(8)锁定状态
mysql show status like '%lock%';
(9)复制延时量
mysqlshow slave status
(10) Tmp Table 状况(临时表状况)
mysqlshow status like 'Create_tmp%';
(11) Binlog Cache 使用状况
mysqlshow status like 'Binlog_cache%';
(12) Innodb_log_waits 量
mysqlshow status like 'innodb_log_waits';
当然怎么监控mysql表操作你也可以使用一下开源监控软件进行监控
一,RRDTool
二,Nagios
三,MRTG
四 , Cacti
如何监控MySQL主从同步情况用 pt-table-checksum 时 , 会不会影响业务性能?
实验
实验开始前 , 给大家分享一个小经验:任何性能评估 , 不要相信别人的评测结果,要在自己的环境上测试,并(大概)知晓原理 。
我们先建一对主从:
然后用 mysqlslap跑一个持续的压力:
开另外一个会话,将 master 上的 general log 打开:
然后通过 pt-table-checksum 进行一次比较:
查看 master 的 general log,由于 mysqlslap 的影响,general log 中有很多内容,我们找到与 pt-table-checksum 相关的线程:
将该线程的操作单独列出来:
操作比较多,我们一点一点来说明:
这里工具调小了 innodb 锁等待时间 。使得之后的操作,只要在 innodb 上稍微有锁等待,就会马上放弃操作,对业务影响很小 。
另外工具调小了 wait_timeout 时间,倒是没有特别的作用 。
工具将隔离级别调整为了 RR 级别,事务的维护代价会比 RC 要高 , 不过后面我们会看到工具使用的每个事务都很小 , 加上之前提到 innodb 锁等待时间调到很?。韵呱弦滴癫某杀颈冉闲?。
RR 级别是数据对比的基本要求 。
工具通过一系列操作,了解表的概况 。工具是一个数据块一个数据块进行校验,这里获取了第一个数据块的下边界 。
接下来工具获取了下一个数据块的下边界,每个 SQL前都会 EXPLAIN 一下,看一下执行成本 , 非常小心翼翼 。
之后工具获取了一个数据块的 checksum,这个数据块不大,如果跟业务流量有冲突,会马上出发 innodb 的锁超时,立刻退让 。
以上是 pt-table-checksum 的一些设计 , 可以看到这几处都是精心维护了业务流量不受影响 。
工具还设计了其他的一些机制保障业务流量,比如参数 --max-load 和 --pause-file 等,还有精心设计的数据块划分方法,索引选择方法等 。大家根据自己的情况配合使用即可达到很好的效果 。
总结
本期我们介绍了简单分析 pt-table-checksum 是否会影响业务流量,坊间会流传工具的各种参数建议或者不建议使用 , 算命的情况比较多,大家都可以用简单的实验来分析其中机制 。
还是那个观点,性能测试不能相信道听途说,得通过实验去分析 。
如何监控mysql表的变化本期我们用 MySQL 提供的 DBUG 工具来研究 MySQL 的 SQL 处理流程 。
起手先造个实例
这里得稍微改一下实例的启动文件 start , 将 CUSTOM_MYSQLD 改为 mysqld-debug:
重启一下实例,加上 debug 参数:
我们来做一两个实验,说明 DBUG 包的作用:
先设置一个简单的调试规则,我们设置了两个调试选项:
d:开启各个调试点的输出
O,/tmp/mysqld.trace:将调试结果输出到指定文件
请点击输入图片描述
然后我们创建了一张表,来看一下调试的输出结果:
请点击输入图片描述
可以看到 create table 的过程中,MySQL 的一些细节操作,比如分配内存 alloc_root 等
这样看还不够直观,我们增加一些信息:
请点击输入图片描述
来看看效果:
请点击输入图片描述
可以看到输出变成了调用树的形式,现在就可以分辨出 alloc_root 分配的内存,是为了解析 SQL 时用的(mysql_parse)
我们再增加一些有用的信息:
请点击输入图片描述
可以看到结果中增加了文件名和行号:
请点击输入图片描述
现在我们可以在输出中找一下统计表相关的信息:
请点击输入图片描述
可以看到 MySQL 在这里非常机智,直接执行了一个内置的存储过程来更新统计表 。
沿着 que_eval_sql,可以找到其他类似的统计表,比如下面这些:
请点击输入图片描述
请点击输入图片描述
本次实验中,我们借助了 MySQL 的 DBUG 包,来让 MySQL 将处理过程暴露出来 。MySQL 中类似的技术还有不少 , 比如 performance_schema,OPTIMIZER_TRACE 等等 。
这些技术将 MySQL 的不同方向的信息暴露出来,方便大家理解其中机制 。
如何实现实时监控mysql数据库主从同步的状态1、增加一个用户同步使用怎么监控mysql表操作的帐号怎么监控mysql表操作:
GRANT FILE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’;
GRANTREPLICATION SLAVE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’;
赋予10.10.8.112也就是Slave机器有File权限怎么监控mysql表操作,只赋予Slave机器有File权限还不行,还要给它REPLICATION SLAVE的权
限才可以 。
2、增加一个数据库作为同步数据库:
create databbse test;
3、创建一个表结构:
create table mytest (username varchar(20),password varchar(20));
4、修改配置文件:
修改A的/etc/my.cnf文件,在my.cnf配置项中加入下面配置:
server-id = 1#Server标识
【怎么监控mysql表操作 mysql 实时监控】log-bin
binlog-do-db=test#指定需要日志的数据库
5、重起数据库服务:
service mysqld restart
查看server-id:
show variable like ‘server_id’怎么监控mysql表操作;
实例:
mysql show variables like 'server_id';
--------------- -------
| Variable_name | Value |
--------------- -------
| server_id| 1|
--------------- -------
1 row in set (0.00 sec)
6、用show master status/G命令看日志情况 。
正常为:
mysql show master status/G
关于怎么监控mysql表操作和mysql 实时监控的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站 。

    推荐阅读