现有TiDB集群扩展pump/drainer作为binlog文件落地

WechatIMG126.jpeg

tiup工具的使用

目前建议使用tiup 对TiDB集群进行管理和维护， tiup工具对集群的操作命令整理如下

列举当前所有TiDB集群

tiup cluster list

查看具体的集群状态

tiup cluster display neibu-tidb

查看具体的集群配置

tiup cluster show-config neibu-tidb

编辑具体的集群配置

tiup cluster edit-config neibu-tidb

编辑集群配置之后需要reload

tiup cluster reload neibu-tidb

集群扩容

tiup cluster scale-out neibu-tidb scale-out-binlog.yaml -uroot -p

binlog 架构

tidb-arch.png

具体的架构说明参考： get-started-with-tidb-binlog

扩容binlog组件

因为本次扩容的目的是把TiDB的changelogs落地为binlog文件，而非同步到下游的MySQL或者Kafka，所以不用提前准备下游环境

1、准备tidb用户的免密登录

因为tiup 工具是部署在独立的主机节点下的 tidb 用户下，所有部署之前一定要保证 tiup主机节点和其他要部署组件的主机节点之间打通ssh免密登录

有ansible编写的playbook，直接修改对应的host，执行playbook即可

ansible-play /etc/ansible/mission/tidb-user.yml

2、新增扩容文件 scale-out-binlog.yaml

这里deploy/data/log 三个目录接口和集群中保持统一，可以通过 tiup cluster show-config neibu-tidb 来查看其他组件的配置

pump_servers:
 - host: 192.168.3.106
   ssh_port: 22
   port: 8250
   deploy_dir: /opt/app/tidb-deploy/pump-8250
   data_dir: /data/tidb-data/pump-8250
   log_dir: /opt/app/tidb-deploy/pump-8250/log
   arch: amd64
   os: linux
drainer_servers:
 - host: 192.168.3.107
   ssh_port: 22
   port: 8249
   deploy_dir: /opt/app/tidb-deploy/drainer-8249
   data_dir: /data/tidb-data/drainer-8249
   log_dir: /opt/app/tidb-deploy/drainer-8249/log
   arch: amd64
   os: linux
   config:
     syncer.db-type: "file"

3、扩容前查看集群状态
4、进行扩容

tiup cluster scale-out neibu-tidb scale-out-binlog.yaml -uroot -p

tiup-cluster-scale-out-20220817.png

4、扩容完毕，查看集群状态

发现多了 pump节点和drainer节点

20220817-tiup-cluster-dispaly-after.png

开启Binlog

登录数据库查看binlog开启状态

MySQL [(none)]> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | OFF   |
+---------------+-------+
1 row in set (0.02 sec)

使用tiup cluster edit-config 来开启binlog

tiup cluster edit-config neibu-tidb

server_configs:
  tidb:
    binlog.enable: true
    binlog.ignore-error: true

然后reload使配置生效

tiup cluster reload neibu-tidb

最后再次检查binlog 是否开启并查看 pump节点和drainer节点状态

MySQL [(none)]> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.04 sec)
MySQL [(none)]> show pump status;
+--------------------+--------------------+--------+--------------------+---------------------+
| NodeID             | Address            | State  | Max_Commit_Ts      | Update_Time         |
+--------------------+--------------------+--------+--------------------+---------------------+
| 192.168.3.106:8250 | 192.168.3.106:8250 | online | 435347930332266498 | 2022-08-17 15:16:01 |
+--------------------+--------------------+--------+--------------------+---------------------+
1 row in set (0.00 sec)
MySQL [(none)]> show drainer status;
+--------------------+--------------------+--------+--------------------+---------------------+
| NodeID             | Address            | State  | Max_Commit_Ts      | Update_Time         |
+--------------------+--------------------+--------+--------------------+---------------------+
| 192.168.3.107:8249 | 192.168.3.107:8249 | online | 435347623626670082 | 2022-08-17 14:56:29 |
+--------------------+--------------------+--------+--------------------+---------------------+
1 rows in set (0.00 sec)

检查binlog落地

这个时候分别查看 pump 和 drainer的日志

1、pump的日志中有

[2022/08/17 14:27:45.752 +08:00] [INFO] [server.go:562] ["server info tick"] [writeBinlogCount=182] [alivePullerCount=1] [MaxCommitTS=435347171074375681]

注意这里的writeBinlogCount=182 就是代表有binlog 在写入, 0的话就是pump没有获取到binlog

2、drainer的日志

[2022/08/17 15:03:02.684 +08:00] [INFO] [syncer.go:260] ["write save point"] [ts=435347726701690882] [version=2737]
[2022/08/17 15:03:06.708 +08:00] [INFO] [syncer.go:260] ["write save point"] [ts=435347727750266881] [version=2737]
[2022/08/17 15:03:09.726 +08:00] [INFO] [syncer.go:260] ["write save point"] [ts=435347728549543937] [version=2737]

这里需要注意 version=2737，如果是 version=0 的代表 drainer 没有从pump获取到binlog

3、检查 drainer 的数据目录，发现有 binlog-0000000000001511-20220817115052 就是落地的binlog文件

tidb 中binlog的格式有text和 json 两种，默认是text

缩容binlog组件pump/drainer

官网给的伸缩容案例中无 binlog组件 pump/drainer 的缩容案例

进过多次试验得出缩容binlog组件pump/drainer的有效步骤

1、编辑集群配置文件，设置binlog.enable 为 false

2、执行scale-in 先缩容 drainer 节点

3、执行scale-in 先缩容 pump 节点

这里有个问题：
缩容 pump节点之后， display展示结果中 pump节点的状态依然是 UP 但是在最后有提示

There are some nodes can be pruned:
    Nodes: [192.168.3.106:8250 192.168.3.107:8249]
    You can destroy them with the command: `tiup cluster prune neibu-tidb`

4、所以需要根据提示执行如下命令

tiup cluster prune neibu-tidb

最后出现 Destroy success 代表缩容完成

5、再次display查看集群状态，显示已经没有 pump 和 drainer

但是存在个问题，

1）这个时候登录tidb，查看 pump 状态依旧是 online

MySQL [(none)]> show pump status;
+--------------------+--------------------+--------+--------------------+---------------------+
| NodeID             | Address            | State  | Max_Commit_Ts      | Update_Time         |
+--------------------+--------------------+--------+--------------------+---------------------+
| 192.168.3.106:8250 | 192.168.3.106:8250 | online | 435347930332266498 | 2022-08-17 15:16:01 |
+--------------------+--------------------+--------+--------------------+---------------------+
1 row in set (0.00 sec)

然后在 tidb-server 的日志文件中会看到如下报错

2）此时是没有pump/drainer 节点的，但是如果开启了 binlog 会在 tidb server 日志，每隔30s 有如下报错

[2022/08/17 15:30:00.603 +08:00] [WARN] [client.go:294] ["[pumps client] write binlog to pump failed"] [NodeID=192.168.3.106:8250] ["binlog type"=Prewrite] ["start ts"=435348150832332802] ["commit ts"=0] [length=62088] [error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp 192.168.3.106:8250: connect: connection refused\""]

这两个问题虽然不影响使用，但是会有错误日志产生，或者信息误导。

大家有解决方案的，欢迎交流。

❤️ 欢迎关注我的公众号，一起学习新知识！一起进步！

————————————————————————————————————————————————————
公众号：全栈运维
个人博客: http://blog.colinspace.com
知乎：https://www.zhihu.com/people/colin-31-49/posts
CSDN ：https://blog.csdn.net/eagle5063
简书：https://www.jianshu.com/u/6d793fbacc88
————————————————————————————————————————————————————