Streaming MySQL Backups with Percona XtraBackup – Another Alternative

使用Percona XtraBackup流式传输MySQL备份-另一种选择

今天我将向你介绍另一种使用Percona XtraBackup在服务器间创建并传递备份的方式. 这个方法和网上的其他方法有什么不同吗? 其实并没有很大不同, 但是在性能和可用性方面很有趣.

我们将xbstream实用程序与pigz和socat的功能结合在一起, 以在拥有多个处理器的情况下利用多处理功能, 同时在此组件成为瓶颈的情况下, 减少对网络带宽的使用. 因此, 让我们解释每个组件:

socat: 代表SOcket CAT. 它是一个用于在两个地址之间进行数据传输的实用程序.

使socat如此通用的原因是地址可以代表网络套接字, 任何文件描述符, Unix域数据报或流套接字, TCP和UDP（在IPv4和IPv6上）, 在IPv4 / IPv6上的SOCKS 4 / 4a, SCTP , PTY, 数据报和流套接字, 命名管道和未命名管道, 原始IP套接字, OpenSSL, 或者在Linux上甚至任何任意网络设备上

Pigz: 它代表gzip的并行实现, 它是gzip的全功能替代品, 在压缩数据时利用了多个处理器和多个内核.

xbstream : （具有并行性）并行处理多个文件.

所需软件包: pigz, socat, 当然还有 Percona XtraBackup

TiDB Syncer不同表名库名同步且支持pt-osc改表

mysql端库名叫sysbench, 表名sbtest11
tidb端库名ptosc_sysbench,表名ptosc_sbtest11

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

[[replicate-do-table]]
db-name = "ptosc_sysbench"
tbl-name = "ptosc_sbtest11"


[[replicate-do-table]]
db-name = "ptosc_sysbench"
tbl-name = "~.*_sbtest11_new"


[[replicate-do-table]]
db-name = "ptosc_sysbench"
tbl-name = "~.*_sbtest11_old"


[[route-rules]]
pattern-schema = "sysbench"
pattern-table = "sbtest11"
target-schema = "ptosc_sysbench"
target-table = "ptosc_sbtest11"

Drainer不支持的DDL-1

版本3.0.5

1.rename table t1 to b_db.b_t1

已经做好TiDB->MySQL的同步, 开启了pump, drainer

尝试将10.133.1.46加入192.168.2.224的集群失败

需要设置参数group_replication_ip_whitelist

此参数虽然是动态参数, 但是要使之生效需要节点重新加入集群

To specify a whitelist manually, use the group_replication_ip_whitelist option. You cannot change the whitelist on a server while it is an active member of a replication group. If the member is active, you must issue a STOP GROUP_REPLICATION statement before changing the whitelist, and a START GROUP_REPLICATION statement afterwards.

TiDB Binlog部署

环境信息

中控机是10.152.x.133

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

[tidb_servers]
10.152.x.10
10.152.x.11
10.152.x.12

[tikv_servers]
10.152.x.10
10.152.x.11
10.152.x.12

[pd_servers]
10.152.x.10
10.152.x.11
10.152.x.12


## Monitoring Part
# prometheus and pushgateway servers
[monitoring_servers]
10.152.x.133

[grafana_servers]
10.152.x.133

# node_exporter and blackbox_exporter servers
[monitored_servers]
10.152.x.10
10.152.x.11
10.152.x.12
10.152.x.133

[alertmanager_servers]
10.152.x.133

ProxySQL平滑下线节点

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

KO我司自研php中间件

环境介绍

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)

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)

如何自己制作机械键盘

本文记录自己的初次”客制化”经历, 键圈大佬请略过, 错误之处请指正, 装逼犯自动忽视~

材料准备

轴体

轴体这里就不做介绍了, 如果你也是萌新的话, 就先了解这四种轴吧:

• 青轴
• 茶轴
• 红轴
• 黑轴

MySQL Error log监控

告警日志监控其实比较简单了, 怎么做都行. 目前我们这里是使用下面的方法
FileBeat采集日志 -> Kafka -> 自己写脚本消费出来 -> 企业微信机器人告警

效果如下

记一次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慢查询平台架构方案

方案1

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