ProxySQL平滑下线节点

ProxySQL平滑下线节点

因为MGR多主DDL和DML不能并发在不同节点执行, 而我们又存在即通过KO又通过ProxySQL访问的数据库的情况, 为了避免在发生故障, 我们决定将ProxySQL中配置的集群真实ip删除, 改为使用KO的vip.
本文介绍如何平滑下线ProxySQL节点, 从而做到对业务无感知.

KO我司自研php中间件

环境介绍

10.133.x.59 跑sysbench
10.133.x.52:3307 测试集群节点
10.133.x.53:3307 测试集群节点
10.133.x.54:3307 测试集群节点
VIP 访问类型 所在服务器
10.133.x.202 KO 10.133.x.202
10.133.x.203 ProxySQL 10.133.x.203

ProxySQL版本

1
2
3
4
5
6
7
admin@127.0.0.1 23:12:02 [(none)]> select version();
+-------------------+
| version() |
+-------------------+
| 2.0.8-67-g877cab1 |
+-------------------+
1 row in set (0.00 sec)

MySQL版本

1
2
3
4
5
6
7
root@localhost 23:17:56 [(none)]> select version();
+------------+
| version() |
+------------+
| 5.7.26-log |
+------------+
1 row in set (0.00 sec)

阅读全文

记一次PMM容器被误删除的恢复

记一次PMM容器被误删除的恢复

昨天PMM Data Container和PMM Server Container 都不小心被误删了, 还好是使用的docker rm container_id删的, 没有加-v. 本人docker渣渣, 后来找运维同时帮忙终于恢复了
首先找到宿主机volumes路径

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@node1 volumes]# pwd
/var/lib/docker/volumes
[root@node1 volumes]# ll
total 32
drwxr-xr-x 3 root root 26 Aug 3 2018 4430beeb61fbc26802dc1b31d9fe3a02772482d8ae31bd50110957f16256f02e
drwxr-xr-x 3 root root 26 Jul 19 18:29 47ce712fd5e32abcf60e9650f349ac1304e0c20d062bd54724123f6cb700a79e
drwxr-xr-x 3 root root 26 Aug 3 2018 6ecf1c674f9f8e6f3dda7f7da352b70860125147b4489c6a8fe00fa59892436f
drwxr-xr-x 3 root root 26 Aug 3 2018 83db182943136c354bf95c0b4d07a8272017fd1698557d27b97dae49c82a8e76
drwxr-xr-x 3 root root 26 Jul 19 18:29 c9e3a964fd76dcad88ac992933ca97ac920c41239f9807f1ca91f939bd71ea03
drwxr-xr-x 3 root root 26 Jul 19 18:29 e92a37881c9b378bc4b00094b3f7e38ace3ae3655c33677a79da1be5652a318a
drwxr-xr-x 3 root root 26 Aug 3 2018 fcddf90d2cb64035c8c69165f69c5d7a780ac580c991f02af801bc65fa2ca609
-rw------- 1 root root 65536 Jul 19 18:29 metadata.db
drwxr-xr-x 3 root root 26 Jul 19 18:26 sentry-data
drwxr-xr-x 3 root root 26 Jul 19 18:26 sentry-postgres

阅读全文

MySQL慢查询平台架构方案

MySQL慢查询平台架构方案

方案1

image

Filebeat读取slow log 到kafka , logstash从kafka消费后解析成出各个列, 然后写入MySQL, 但是这样的问题是查询语句是这样的
select * from A where id=1. 而我们需要去除谓词的SQL, 也就是select * from A where id=? 这样的, 这样才好对SQL进行聚合分析
于是用Canal拉binlog, 再写到kafka, 然后python消费, 获取id, sql文本, 使用pt-fingerprint去除谓词后再更新回去.

这个架构看起来蛮高大上 想了想还是复杂了写, 环节太些, 容易出问题.

  • 优点: 慢查询准实时获取(但可能是伪需求)
  • 缺点: 架构复制易出错, MySQL版本升级如果slow log格式发生变化, 维护logstash的grok会很麻烦

有人说为什么不用Filebeat ingest直接到ES, 这要图标用Kibana就好了. 我的考虑是:
1.还要做谓词去除
2.这样做出的图没法和我们业务的服务数关联, 业务人员查询就必须知道数据库的IP端口
详细方案可以参考下面的文档

https://www.jianshu.com/p/f3be9cce9b77
https://www.jianshu.com/p/3cf0e2a8d23d

阅读全文


Powered by Hexo and Hexo-theme-hiker

Copyright © 2013 - 2019 Fan() All Rights Reserved.

访客数 : | 访问量 :

#