TiDB Binlog 实践指南

网友投稿 860 2024-02-26



TiDB Binlog 是一个用于收集 TiDB 的 binlog,并提供准实时备份和同步功能的商业工具。

TiDB Binlog 实践指南

TiDB Binlog 支持以下功能场景:

数据同步:同步 TiDB 集群数据到其他数据库

实时备份和恢复:备份 TiDB 集群数据,同时可以用于 TiDB 集群故障时恢复

相关源码仓库

TiDB Binlog 的实现主要分布在 tidb-tools 和 tidb-binlog 两个源码仓库中

1. tidb-tools

Repo: https://github.com/pingcap/tidb-tools/

这个仓库除了 TiDB Binlog 还有其他工具的组件,在这里与 TiDB Binlog 关系最密切的是 tidb-binlog/pump_client 这个 package。

pump_client 实现了 Pump 的客户端接口,当 binlog 功能开启时,TiDB 使用它来给 pump 发送 binlog 。

2. tidb-binlog

Repo: https://github.com/pingcap/tidb-binlog

TiDB-Binlog 的核心组件都在这个仓库,下面是各个关键目录:

cmd:包含 pump,drainer,binlogctl,reparo,arbiter 等 5 个子目录,分别对应 5 个同名命令行工具。这些子目录下面的 main.go 是对应命令行工具的入口,而主要功能的实现则依赖下面将介绍到的各个同名 packages。

pump:Pump 源码,主要入口是 pump.NewServer 和 Server.Start;服务启动后,主要的功能是 WriteBinlog(面向 TiDB/pump_client) 和 PullBinlogs(面向 Drainer)。

drainer:Drainer 源码,主要入口是 drainer.NewServer 和 Server.Start;服务启动后,Drainer 会先找到所有 Pump 节点,然后调用 Pump 节点的 PullBinlogs 接口同步 binlog 到下游。目前支持的下游有:mysql/tidb,file(文件增量备份),kafka 。

binlogctl:Binlogctl 源码,实现一些常用的 Binlog 运维操作,例如用 -cmd pumps 参数可以查看当前注册的各个 Pump 节点信息,相应的实现就是 QueryNodesByKind。

reparo:Reparo 源码,实现从备份文件(Drainer 选择 file 下游时保存的文件)恢复数据到指定数据库的功能。

arbiter:Arbiter 源码,实现从 Kafka 消息队列中读取 binlog 同步到指定数据库的功能,binlog 在消息中以 Protobuf 格式编码。

pkg:各个工具公用的一些辅助类的 packages,例如 pkg/util 下面有用于重试函数执行的 RetryOnError,pkg/version 下面有用于打印版本信息的 PrintVersionInfo。

tests:集成测试。

配置Pump和Drainer

Pump

Pump 用于实时记录 TiDB 产生的 Binlog,并将 Binlog 按照事务的提交时间进行排序,再提供给 Drainer 进行消费。

Drainer

Drainer 从各个 Pump 中收集 Binlog 进行归并,再将 Binlog 转化成 SQL 或者指定格式的数据,最终同步到下游。

[tidb@localhost ~]$ cat scaleout-binlog.yaml

pump_servers:

  - host: 192.168.135.148

    config:

      gc: 7

drainer_servers:

  - host: 192.168.135.148

    config:

      syncer.db-type: "mysql"

      syncer.to.host: "192.168.135.148"

      syncer.to.user: "jian"

      syncer.to.password: "123456"

      syncer.to.port: 3306

[tidb@localhost ~]$ tiup cluster scale-out tidb-jiantest scaleout-binlog.yam

这里提示一下,TidbBinlog 工具需要tidb server开始binlog功能需要tidb的配置文件打开binlog功能

  config:

    binlog.enable: true

    binlog.ignore-error: true

我们可以在tidb中查看pump和drainer的状态这里我们主要关注一下下Max_Commit_Ts 

记录了pump和drainer的 binlog 已经更新到了哪个位置。

MySQL [(none)]> show pump status;

+----------------------+----------------------+--------+--------------------+---------------------+

| NodeID               | Address              | State  | Max_Commit_Ts      | Update_Time         |

+----------------------+----------------------+--------+--------------------+---------------------+

| 192.168.135.148:8250 | 192.168.135.148:8250 | online | 431846449408901121 | 2022-03-15 12:57:52 |

+----------------------+----------------------+--------+--------------------+---------------------+

MySQL [(none)]> show drainer status;

+----------------------+----------------------+--------+--------------------+---------------------+

| NodeID               | Address              | State  | Max_Commit_Ts      | Update_Time         |

+----------------------+----------------------+--------+--------------------+---------------------+

| 192.168.135.148:8249 | 192.168.135.148:8249 | online | 431846450195333121 | 2022-03-15 12:57:54 |

+----------------------+----------------------+--------+--------------------+---------------------+

1 对于开启TidbBinlog之前的数据是无法同步的

记得在上面我们准备源数据的时候创建了新的数据和表还插入了数据,但是当我们打开TidbBinlog的时候,我们可以发现之前的数据并没有复制过来,所以有数据差的话建议使用 Dumpling 工具进行数据的初始化,但是可以发现多了一个tidb_binlog,这个是tidb自己创建的用于记录复制的checkpoint信息

2 在目标端以sql的方式应用数据

可以看到在目标端复制数据会执行相应的sql,而且会更新tidb_binlog.checkpoit表

3 时间戳

在没有延迟的情况下drainer的时间戳和目标端的数据中的时间戳应该是一致的

4 如果下游数据库异常drainer也会停止

[root@localhost mysql]# systemctl stop MariaDB

192.168.135.148:8249   drainer       192.168.135.148  8249                             Linux/x86_64  Down     /tidb-data/drainer-8249       /tidb-deploy/drainer-8249

当db恢复正常时drainer也会自动恢复正常

5自增主键

对自增主键的复制也是没有问题的

SOURCE

MySQL [jian]> create table jian2(id int auto_increment primary key,name char(10));

Query OK, 0 rows affected (0.159 sec)

MySQL [jian]> insert into jian2(name) values(jian2);

Query OK, 1 row affected (0.012 sec)

TARGET

20220315 16:40:20,localhost.localdomain,jian,192.168.135.149,20,1177,QUERY,jian,INSERT INTO `jian`.`jian2`(`id`,`name`) VALUES(3,\jian2\),0

MariaDB [(none)]> select * from jian.jian2;

+----+-------+

| id | name  |

+----+-------+

|  3 | jian2 |

6 Drainer relaylog

Drainer 开启 relay log 后会先将 binlog event 写到磁盘上,然后再同步给下游集群。如果上游集群不可用,Drainer 可以通过读取 relay log 把下游集群恢复到一个一致的状态。

[root@localhost conf]# cat drainer.toml

[syncer.relay]

log-dir = "/tidb-data/drainer-8249"

max-file-size = 10485760

查看生成的relaylog

[root@localhost relaylog]# ls

binlog-0000000000000000-20220315143339

[root@localhost relaylog]# pwd

/tidb-data/drainer-8249/relaylog

7 reparo

Reparo 这部分实现像一个简化版的 Drainer 的 Sync 模块,同样有一个 Syncer 接口以及几个具体实现(除了 mysqlSyncer 还有用于调试的 printSyncer 和 memSyncer),所以就不再介绍。值得一提的是,这里也跟前面很多 MySQL / TiDB 同步相关的模块一样使用了 loader 模块。用于增量的恢复。使用 TiDB Binlog 中的 Drainer 将 binlog 按照 protobuf 格式输出到文件,通过这种方式来备份增量数据。当需要恢复增量数据时,使用 Reparo 解析文件中的 binlog,并将其应用到 TiDB/MySQL 中。

配置文件可以灵活限制需求

# 使用 start-datetime 和 stop-datetime 来选择恢复指定时间范围内的 binlog,格式为 “2006-01-02 15:04:05”。# start-datetime = ""# stop-datetime = ""

# start-tso、stop-tso 分别对应 start-datetime 和 stop-datetime,也是用于恢复指定时间范围内的 binlog,用 tso 的值来设置。如果已经设置了 start-datetime 和 stop-datetime,就不需要再设置 start-tso 和 stop-tso。# 在从全量或者上次增量位置继续同步时,start-tso 应当指定为全量 tso + 1 或者上次增量的 stop-tso + 1# start-tso = 0# stop-tso = 0

# replicate-do-db 和 replicate-do-table 用于指定恢复的库和表,replicate-do-db 的优先级高于 replicate-do-table。支持使用正则表达式来配置,需要以 ~ 开始声明使用正则表达式。# 注:replicate-do-db 和 replicate-do-table 使用方式与 Drainer 的使用方式一致。# replicate-do-db = ["~^b.*","s1"]

[tidb@localhost ~]$ reparo -config reparo.toml

8 binlogctl

也可以使用binlogctl去查看后者更改pump和drainers的状态

命令存放于tidb-binlog-cluster-latest-linux-amd64.tar.gz,解压即可用

pause-pump    暂停 Pump    bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pause-pump -node-id ip:8250

pause-drainer    暂停 Drainer    bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pause-drainer -node-id ip:8250

offline-pump    下线 Pump    bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd offline-pump -node-id ip:8250

offline-drainer    下线 Drainer    bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd offline-drainer -node-id ip:8250

例子:

[tidb@localhost tidb-community-server-v5.4.0-linux-amd64]$ binlogctl -pd-urls=http://127.0.0.1:2379-cmd pause-pump -node-id 192.168.135.148:8250 [2022/03/16 16:51:32.183 -04:00] [INFO] [nodes.go:123] ["Apply action on node success"] [action=pause] [NodeID=192.168.135.148:8250]

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:怎么使用oracle索引监控
下一篇:MSSQL程序设计:实现技术革新(mssql程序设计)
相关文章