dumper+lightning+drainer做集群同步的问题

🪐 TiDB 技术问题 备份&数据迁移
1
  • 【TiDB 版本】：3.0.18
  • 【问题描述】：

在使用mydumper备份，lightning导入，metadata的点位让drainer做增量同步的时候，发现了一些问题。

drainer status和日志里的point，都是在启动drainer时间范围的点位，并没有从提前编写好的–initial-commit-ts开始。

导致我不确定当前同步的真实进度，以及中间的数据是否已经丢失？
可以确认point的时间还在gc的有效范围内，720h。

image
image2559×768 277 KB

2

Hello ～ 根据你的描述，Drainer log 中如果一直有 write savepoint ts 记录，说明正常消费 binlog 日志。如果想确认同步的延迟情况，可以关注 Drainer 的监控，里面也会有详细的介绍。
https://docs.pingcap.com/zh/tidb/stable/monitor-tidb-binlog-cluster

3

可是那个drainer是我新部署的， 有点奇怪。

那请问对于这种情况，怎么使用mydumper中的ts点位继续增量同步呢？

4

给一下 drainer toml 文件看下，主要关注 commt-ts 的设置，并提供下如何获取的 mudumper 导出的 ts 信息。
提供下集群部署方式。
tidb binlog 版本信息

5

集群版本：

v3.0.11

mydumper metadata:

Started dump at: 2020-09-01 14:37:48
SHOW MASTER STATUS:
Log: tidb-binlog
Pos: 419153121987791863
GTID:

Finished dump at: 2020-09-06 03:06:58

drainer.toml

detect-interval = 10

[syncer]
ignore-schemas = "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql"
txn-batch = 512
worker-count = 1024
disable-dispatch = false
safe-mode = false
db-type = "tidb"
ignore-txn-commit-ts = []

[[syncer.replicate-do-table]]
db-name ="sds_data"
tbl-name = "fvp_scan_gun"

[[syncer.replicate-do-table]]
db-name ="sds_data"
tbl-name = "oms_waybill_tidb"

[[syncer.replicate-do-table]]
db-name ="sds_data"
tbl-name = "sgs_waybill_tidb"

[syncer.to]
host = "10.189.200.15"
user = "tidb_test"
password = "xxx"
port = 4000

run_drainer.sh

#!/bin/bash
set -e
ulimit -n 1000000

DEPLOY_DIR=/home/tidb/tidb_sds-v3

cd "${DEPLOY_DIR}" || exit 1

# WARNING: This file was auto-generated. Do not edit!
#          All your edit might be overwritten!

exec bin/drainer \
    --addr="10.189.200.13:8249" \
    --pd-urls="http://10.188.36.2:4250,http://10.188.36.3:4250,http://10.188.36.4:4250" \
    --data-dir="/home/tidb/tidb_sds-v3/data.drainer" \
    --log-file="/home/tidb/tidb_sds-v3/log/drainer.log" \
    --config=conf/drainer.toml \
    --initial-commit-ts="419153121987791863" 2>> "/home/tidb/tidb_sds-v3/log/drainer_stderr.log"
6

先确认下 tidb binlog 版本和 tidb 集群版本是否相符哈，从提供的信息目前无法判断。

initial-commit-ts 加载 drainer toml 试下。run-drainer.sh 不需要手动修改。

7

./pump -V

Release Version: v3.0.11
Git Commit Hash: 56ced1e197735eacae5179c7da3bd749bac55690
Build TS: 2020-03-04 12:03:46
Go Version: go1.13
Go OS/Arch: linux/amd64

./drainer -V

Release Version: v3.0.11
Git Commit Hash: 56ced1e197735eacae5179c7da3bd749bac55690
Build TS: 2020-03-04 12:04:10
Go Version: go1.13
Go OS/Arch: linux/amd64

部署方式是ansible, run-drainer.sh是自动下发的，点位也正确。我理解跟写conf里没什么区别？？

drainer_tidb ansible_host=10.189.200.13 initial_commit_ts=“419153121987791863”

8

你好，那个集群版本是 3.0.18 ？如果是请先统一下版本在进行测试

9

源端是3.0.11， 下游新集群是3.0.18

之前我从2.x用这种方式升级到了3.0.11，都没这个问题！

除了initial_commit_ts，还有其他参数可以强制点位吗？

10

期待回复， 这是否是一个bug?

11

那版本这是没问题的。

那你的 initial-commit-ts 在哪里设置的呢，在 drainer toml 也没看到。。

与此参数平级，设置下：

initial-commit-ts: 419153121987791863

12

ansible部署后，自动打到shell脚本里的。

我发的日志里你可也可以看到，读取到了正确的initial_commit_ts。 但是后面就跳到其他点位了。

13

当前的问题是什么，辛苦在讲下，有点搞蒙了

这个值得是什么？initial_commit_ts 一次使用就没效了。 drainer 会刷新当前的 commit ts 预期的，如果 drainer log 中没有 error 等明显报错可以通过 sync-diff-inspector 工具验证数据的准确性

14

日志截图里，很清楚的可以看到，正确读取到了initial_commit_ts，随后在write save point和show drainer status里面看到的，都是非常新的点位， 中间6天的数据就直接忽略了。

是我描述的有问题吗？？？？

15

上游 binlog 拉取应该是顺序拉取，消费会保证按顺序消费，但是读取 binlog 不一定是连续的。所以不用担心这个 position 位置差异问题，我们那会保证同步到下游数据是有序的。

16

感谢回复，show drainer status里面看到的是消费顺序吗？

我看到也是最新的ts位置，并且查询了一下没有期望的增量数据写入进来，写入的都是最新的数据。

不过source端的集群原来有过其他drainer，或许没有正常下线，本次是新增的drainer，跟这有关系吗？

17

通过 drainer.log 更加清晰一些

期望的增量数据指的是什么，如果是 initial_commit_ts 之后的数据新增没有同步到下游不符合预期的（请查看是否增加了其他的过滤条件）。
show drainer status; 展示内容如下，可以通过 State 字段看下状态是否为 online。
https://docs.pingcap.com/zh/tidb/stable/sql-statement-show-drainer-status#show-drainer-status

18

结贴，pump gc =1，binlog被清理导致丢失中间增量数据。

感谢两位支持。@SUN-PingCAP @户口舟亢

19

感谢反馈解决方案，如果你有其他问题，麻烦提交新的问题帖子。