pt-heartbeat是用来监控主从延迟的一款percona工具,现在我们大部分的MySQL架构还是基于主从复制,例如MHA,MMM,keepalived等解决方案。而主从环境的话,我们很关心的就是主从延迟的问题,一般情况下我们在从库执行以下语句:
mysql> show slave status\G
*************************** . row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.16.16.35
Master_User: root
Master_Port:
Connect_Retry:
Master_Log_File: mysql-bin.
Read_Master_Log_Pos:
Relay_Log_File: mxqmongodb2-relay-bin.
Relay_Log_Pos:
Relay_Master_Log_File: mysql-bin.
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno:
Last_Error:
Skip_Counter:
Exec_Master_Log_Pos:
Relay_Log_Space:
Until_Condition: None
Until_Log_File:
Until_Log_Pos:
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master:
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno:
Last_IO_Error:
Last_SQL_Errno:
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id:
Master_UUID: 806ede0c-357e-11e7--00505693235d
Master_Info_File: mysql.slave_master_info
SQL_Delay:
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count:
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 806ede0c-357e-11e7--00505693235d:-
Executed_Gtid_Set: 6a4ab82c--11e7-86b0-00505693235d:-,
806ede0c-357e-11e7--00505693235d:-
Auto_Position:
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
row in set (0.00 sec)
就可以很明显看得到主从的状态,一般我们都会监控以下两个进程的状态确定主从延迟是否出现错误:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
对于主从延迟来说,我们可能监控最多的就是通过SMB(Seconds_Behind_Master)来监控,但是这个也并不是很靠谱的。或者我们通过监控Read_Master_Log_Pos-Exec_Master_Log_Pos的差值来看从库是否有延迟,是否和主库会有一定的延迟。但是这个也并不是很完美。首先看SMB,这个参数是怎么比较出来的呢,SMB是通过将服务器当前的时间戳与二进制日志中的事件时间戳相对比得到的,而且是会产生误报的情况。比如主库执行一个大事物,时间执行很久,从库接收以后对比时间戳发现已经延迟了,就会瞬间增大SMB的值。Read_Master_Log_Pos-Exec_Master_Log_Pos的值也并不是完全可靠。现在pt-heartbeat就能帮我们解决这个问题。
下面我们来看一下pt-heartbeat的原理:
pt-heartbeat会在master上创建一张表,按照一定的时间频率更新该表的字段,向该表写入当前的时间戳,然后对比从库的时间戳和pt-heartbeat所在机器的时间戳来判断主从延迟。
其实这里就有一个问题了,如果pt-heartbeat部署在从库的话,要保证主从机器的时间是同步的,这个一般都是系统会每天自动对时间,是可以实现的。如果pt-heartbeat部署在主库就不会有这个问题。其实个人感觉比较好的方法就是对比主从两个库的这张表的时间戳来得出延迟更为靠谱一点,当然这也要考虑到主从查询的问题。
下面看一下基本的用法:
先创建表:
[root@mxqmongodb2 bin]# ./pt-heartbeat --host=172.16.16.35 --port= --user=root --password= --database=test --update --create-table --daemonize
看一下表结构:
mysql> desc heartbeat;
+-----------------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------------------+------+-----+---------+-------+
| ts | varchar() | NO | | NULL | |
| server_id | int() unsigned | NO | PRI | NULL | |
| file | varchar() | YES | | NULL | |
| position | bigint() unsigned | YES | | NULL | |
| relay_master_log_file | varchar() | YES | | NULL | |
| exec_master_log_pos | bigint() unsigned | YES | | NULL | |
+-----------------------+---------------------+------+-----+---------+-------+
rows in set (0.01 sec)
mysql> select * from heartbeat\G
*************************** . row ***************************
ts: --23T09::49.001580
server_id:
file: mysql-bin.
position:
relay_master_log_file: NULL
exec_master_log_pos: NULL
row in set (0.00 sec)
具体看一下,我们看一下数据库的链接,发现有一个更新操作:
UPDATE `test`.`heartbeat` SET ts='2017-06-23T09:32:47.001330', file='mysql-bin.000016', position='
其实下面的操作只是开启了一个进程,对heartbeat表不停的进行更新,以获取最新的数据。
[root@mxqmongodb2 bin]# ./pt-heartbeat --host=172.16.16.35 --port= --user=root --password= --database=test --update --daemonize
接下来我们开启监控进程,这个是不停的刷新的:
[root@mxqmongodb2 bin]# ./pt-heartbeat -D test --monitor -h 172.16.16.34 -uroot -P3306 -p123456
.00s [ .00s, .00s, .00s ]
.00s [ .00s, .00s, .00s ]
.00s [ .00s, .00s, .00s ]
.00s [ .00s, .00s, .00s ]
.00s [ .00s, .00s, .00s ]
我们指定会发现是没有延迟的,我们现在开启压测,再观察一下:
[root@mxqmongodb2 tpcc-mysql]# ./tpcc_start -h127.0.0. -P3306 -d tpcc -u root -p123456 -w  -c  -r  -l 
观察延迟的情况:
.71s [ .68s, .16s, .05s ]
.71s [ .71s, .17s, .06s ]
.85s [ .72s, .17s, .06s ]
.93s [ .74s, .18s, .06s ]
.00s [ .74s, .18s, .06s ]
.82s [ .73s, .18s, .06s ]
.66s [ .75s, .18s, .06s ]
.00s [ .75s, .18s, .06s ]
.88s [ .74s, .18s, .06s ]
.00s [ .74s, .19s, .06s ]
我们可以看到延迟情况,我们可以把这些输出结果重定向到一个文件,对主从延迟进行监控,这也是很有效果的。
我们现在手动再从库停掉sql_thread:
mysql> stop slave sql_thread;
Query OK, rows affected (0.03 sec)
然后再看输出结果:
.00s [ .85s, .77s, .20s ]
.00s [ .75s, .94s, .26s ]
.00s [ .67s, .12s, .32s ]
.00s [ .60s, .30s, .39s ]
.00s [ .55s, .48s, .45s ]
.00s [ .52s, .67s, .51s ]
.00s [ .50s, .86s, .58s ]
.00s [ .50s, .05s, .65s ]
.00s [ .50s, .23s, .71s ]
.00s [ .50s, .42s, .78s ]
.00s [ .50s, .61s, .85s ]
.00s [ .50s, .80s, .92s ]
.00s [ .50s, .98s, .00s ]
发现是不停的递增的,一次间隔时间为一秒钟。我们再启动这个sql_thread,从库很快就跟上了主库。
或者我们可以通过下面进行监控:
[root@mxqmongodb2 bin]# ./pt-heartbeat -D test --check -h 172.16.16.34 -uroot -P3306 -p123456
1.00
[root@mxqmongodb2 bin]# ./pt-heartbeat -D test --check -h 172.16.16.34 -uroot -P3306 -p123456
0.00
他是会直接返回一个延迟的秒数,这个也是比较靠谱的。我们可以直接拿这个值进行监控。
 
 
 

pt-heartbeat(percona toolkit)的更多相关文章

  1. pt-query-digest(percona toolkit)小解

    pt-query-digest可以通过logs, processlist, 和tcpdump来分析MySQL的查询相关信息,基本语法如下: pt-query-digest [OPTIONS] [FIL ...

  2. pt-variable-advisor(percona toolkit)

    pt-variable-advisor是一款分析参数,并且给出参数设置建议的一款PT工具,基本语法 pt-variable-advisor [OPTIONS] [DSN] 如下我们可以获取本地参数的一 ...

  3. (转)Linux-HA开源软件Heartbeat(配置篇)

    原文:http://ixdba.blog.51cto.com/2895551/548625 http://gzsamlee.blog.51cto.com/9976612/1828870 Linux-H ...

  4. mysql全备和增量备份以及恢复过程(percona工具)

    实验环境 系统环境,内核版本和xtrabackup工具版本 [root@linux-node1 mysql]# cat /etc/redhat-release CentOS Linux release ...

  5. 黄聪:Microsoft office 2013版下载、安装及破解工具下载破解教程(Windows Toolkit)

    Microsoft Office 2013(Office 15)是微软的新一代Office办公软件,全面采用Metro界面.Microsoft Office 2013官方下载(Office2013专业 ...

  6. Percona Toolkit工具连接MySQL 8报错的解决方案

    使用Percona Toolkit的工具连接MySQL 8.x数据库时,会遇到类似"failed: Plugin caching_sha2_password could not be loa ...

  7. HA(High available)--Heartbeat高可用性集群(双机热备)菜鸟入门级

    HA(High available)--Heartbeat高可用性集群(双机热备)   1.理解:两台服务器A和B ,当A提供服务,B闲置待命,当A服务宕机,会自动切换至B机器继续提供服务.当主机恢复 ...

  8. docker1.12 安装pxc(Percona XtraDB Cluster )测试

    docker1.12 安装pxc(Percona XtraDB Cluster )测试

  9. 国内三大PT(Private Tracker)站分析

    除这一行外,下面全部内容都是转载.出处不明. 国内三大PT(Private Tracker)站分析 先郑重的声明一下:本文以下的内容所有是复制粘贴的,不代表老夫的观点. 事实上内容我也没细致看. 贴这 ...

随机推荐

  1. Vue-cil结合Element-ui开发(一)

    前几天用了一下Vue.js结合Element-ui,踩了很多坑,现在总结一下以备以后复习-------------------------------------------------------- ...

  2. grunt 实例构建(四)

    相关插件的引用: grunt-usemin  对页面的操作 grunt-contrib-cssmin  压缩css load-grunt-tasks 瘦身gruntfile grunt-rev给md5 ...

  3. Android中直接打开高德APP进行导航

    1.判断是否安装有高德APP //高德APPprivate PackageManager mPackageManager;private static List<String> mPack ...

  4. VS2013诡异问题,虚方法、泛型,通通躺枪

    最近在调代码,发现一个很诡异的问题,简单复原一下 创建4.0控制台项目 以下代码 class Program { static void Main(string[] args) { var item ...

  5. android actionbar viewpager 实现类微信主界面布局

    1 Activity public class MainActivity extends FragmentActivity { private ViewPager pager; private Act ...

  6. Spark on YARN模式的安装(spark-1.6.1-bin-hadoop2.6.tgz + hadoop-2.6.0.tar.gz)(master、slave1和slave2)(博主推荐)

    说白了 Spark on YARN模式的安装,它是非常的简单,只需要下载编译好Spark安装包,在一台带有Hadoop YARN客户端的的机器上运行即可.  Spark on YARN简介与运行wor ...

  7. An internal error occurred during: "Initializing Java Tooling". Eclipse启动发生的错误

    An internal error occurred during: “Initializing Java Tooling” 错误经常是莫名其妙的出现这种总错误,解决办法: 1.eclipse -&g ...

  8. 理解C#反射

    参考文章:http://blog.csdn.net/educast/article/details/2894892 上面的文章将C#反射要用到的方法都给出了,下面我将写个例子,帮助理解 [1.使用反射 ...

  9. C 标准库 - string.h之strcpy使用

    strcpy Copies the C string pointed by source into the array pointed by destination, including the te ...

  10. 浅谈Java中的hashcode方法(转载)

    哈希表这个数据结构想必大多数人都不陌生,而且在很多地方都会利用到hash表来提高查找效率.在Java的Object类中有一个方法: 1 public native int hashCode(); 根据 ...