如何实现监控mysql,并将有变动的数据表写入指定的文件夹?

如何实现监控mysql,并将有变动的数据表写入指定的文件夹?,第1张

首先介绍下 pt-stalk,它是 Percona-Toolkit 工具包中的一个工具,说起 PT 工具包大家都不陌生,平时常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于这个工具包,这里就不多介绍了。

pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息,这其中包括:

1. OS 层面的 CPU、IO、内存、磁盘、网络等信息;

2. MySQL 层面的行锁等待、会话连接、主从复制,状态参数等信息。

而且 pt-stalk 是一个 Shell脚本,对于我这种看不懂 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-bin.000001

若原来没设置过的朋友,需要重新配置一下(过程就翻上去看一下)

-将 id 为 8 的用户name改成飞龙2

修改 my.cnf 添加 binlog-do-db

保存退出 并重启mysql

这样mysql就开启了 binlong 日志功能

前言

上篇文章简单介绍canal概念,本文结合常见的缓存业务去讲解canal使用。在实际开发过程中,通常都会把数据往redis缓存中保存一份,做下简单的查询优化。如果这时候数据库数据发生变更 *** 作,就不得不在业务代码中写一段同步更新redis的代码,但是这种 数据同步的代码和业务代码糅合在一起 看起来不是很优雅,而且还会出现数据不一致问题。那能不能把这部分同步代码从中抽离出来,形成独立模块呢?答案是肯定的,下面通过canal结合Kafka来实现mysql与redis之间的数据同步。

架构设计

通过上述结构设计图可以很清晰的知道用到的组件:MySQL、Canal、Kafka、ZooKeeper、Redis。

Kafka&Zookeeper搭建

首先在 官网 下载Kafka:

下载后解压文件夹,可以看到以下几个文件:

Kafka内部自带了zookeeper,所以暂不需要去下载搭建zookeeper集群,本文就使用Kafka自带zookeeper来实现。

通过上述zookeeper启动命令以及Kafka启动命令把服务启动,可以通过以下简单实现下是否成功:

Canal搭建

canal搭建具体可以参考上文,这里只讲解具体的参数配置:

找到/conf目录下的canal.properties配置文件:

然后配置instance,找到/conf/example/instance.properties配置文件:

经过上述配置后,就可以启动canal了。

测试

环境搭建完成后,就可以编写代码进行测试。

1、引入pom依赖

2、封装Redis工具类

在application.yml文件增加以下配置:

封装一个 *** 作Redis的工具类:

3、创建MQ消费者进行同步

创建一个CanalBean对象进行接收:

最后就可以创建一个消费者CanalConsumer进行消费:

测试Mysql与Redis同步

mysql对应的表结构如下:

启动项目后,新增一条数据:

可以在控制台看到以下输出:

如果更新呢?试一下Update语句:

同样可以在控制台看到以下输出:

经过测试完全么有问题。

总结

既然canal这么强大,难道就没缺点嘛?答案当然是存在的啦,比如:canal只能同步增量数据、不是实时同步而是准实时同步、MQ顺序问题等; 尽管有一些缺点,毕竟没有一样技术或者产品是完美的,最重要是合适。比如公司目前有个视图服务提供宽表搜索查询功能就是通过 同步Mysql数据到Es采用Canal+Kafka的方式来实现的。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/8497831.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-17
下一篇 2023-04-17

发表评论

登录后才能评论

评论列表(0条)

保存