使用drainer还原会丢失数据吗?如何使用drainer可以保证不丢失数据？

🪐 TiDB 技术问题 备份&数据迁移
1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
主库为业务库，从库使用binlog实时同步test库数据，
数据开发组使用从test库做数据开发，只读不写test

【概述】 场景 + 问题概述
数据分析使用从库得到的报表，发现与线上出现出入，
仔细查数后发现，从库缺失少量数据
新建一个相同表结构的表，将未导入的数据插入，发现从库建立相同的表，并存在主库插入的数据

【备份和数据迁移策略逻辑】
主从库都是v4.0.9
使用主库的一个BR备份还原之后开启binlong同步，主库三个pump节点收集binlog
一个Drainer打binlog到共享存储备份，一个Drainer同步到从库
同步到从库的 Drainer 配置如下：
[syncer]
db-type = “tidb”
ignore-schemas = “INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql”
txn-batch = 100
worker-count = 128
safe-mode = true
sql-mode = “”
[syncer.to]
host = “192.168.11.111”
password = “password”
port = 4000
user = “user”

【背景】 做过哪些操作
从库只有查询，没有写入操作，主库实时备份到从库

【现象】 业务和数据库现象

【问题】 当前遇到的问题
从库丢失少量数据，导致使用从库的数据生成的报表数据不完整。Drainer日志没有ERROR。

【业务影响】
从库丢失少量数据，导致使用从库的数据生成的报表数据不完整。

【TiDB 版本】
tidb-v4.0.9

【附件】

  • 相关日志、配置文件、Grafana 监控（https://metricstool.pingcap.com/)
  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息
  • TiDB-Overview 监控
  • 对应模块的 Grafana 监控（如有 BR、TiDB-binlog、TiCDC 等）
  • 对应模块日志（包含问题前后 1 小时日志）

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

2

主集群做过扩容，缩容 tidb 节点操作么？以及 tidb 是否出现过宕机操作？丢失的数据有什么特征么？

4

以前有对TiDB节点有做过扩容
丢失的数据很好几条：
格式如下的：
“id” “user_id” “attribute” “survey_id” “question_id” “question_type” “source_option_id” “source_key” “show” “option_id” “value” “sort” “update_time” “question_order” “proof”
“138XXXX598” “6c003a76ae1d9917e76da2c5195f14ec” “mobile_number” “80XXX03” “130XXXX55” “106” “0” “” “” “0” “{”“award_type”“:2,”“award_text”“:5,”“mobile_prefix”“:”“+86"”,““mobile_number””:““198XXXXXX64””,““answer_status””:1}" “0” “2022-01-14 03:02:57” “17” “198XXXXXX64”

这个是Binlog的grafana，其他日志我还在拷贝

qdtech-tidb-Binlog-1644832792733.json (47.4 KB)

5

pump-59.log (5.4 MB)
pump-60.log (5.5 MB)
pump-61.log (5.5 MB)
drainer-60.log (2.9 MB)

6

这个应该才是Grafana的图表
qdtech-tidb-Binlog_2022-02-14T11_29_49.812Z.json (554.1 KB)

7

丢失的数据什么特征？主集群什么时候扩容的？

8

建表语句如下：
CREATE TABLE dcs_application_answer_v2 (
id bigint(20) NOT NULL AUTO_INCREMENT,
user_id varchar(255) DEFAULT ‘’,
attribute varchar(64) DEFAULT ‘’,
survey_id varchar(64) DEFAULT ‘0’ ,
question_id int(11) DEFAULT ‘0’,
question_type smallint(6) DEFAULT ‘0’,
source_option_id int(11) DEFAULT ‘0’,
source_key varchar(255) DEFAULT ‘’,
show varchar(255) DEFAULT ‘’,
option_id bigint(20) DEFAULT ‘0’,
value varchar(255) DEFAULT ‘’,
sort smallint(6) DEFAULT ‘0’,
update_time timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
question_order smallint(6) DEFAULT ‘0’,
proof varchar(64) DEFAULT ‘’,
PRIMARY KEY (id),
KEY survey_user (survey_id,user_id),
KEY proof (proof),
KEY user_id (user_id),
KEY survey_question (survey_id,question_id),
KEY index_update_time (update_time),
KEY type_index (question_type)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=13957230798

丢失了20条数据，时间从“2022-01-14 00:47:16”到“2022-01-14 03:02:57”，这20条数据跟其他数据格式跟存储内容基本一致的。
TiDB节点的扩容的话，是2021年11月做的扩容了

9

如果丢数据前后没有不规范的扩容 tidb 、dump操作，那看下是否跟这个有关系，https://docs.pingcap.com/zh/tidb/v4.0/tidb-binlog-overview#注意事项。
建议主从集群做一次全量校验，确认下数据不一致范围。

10

那有没有可能跟TiDB节点的异常退出有关系？有个别机器上是pump、drainer、tidb三个组件都放在一起的。TiDB节点有时候会有OOM异常退出的情况。

11

建议：
1.建议做一次上下游数据校验，确认下数据不一致范围
2.下游丢失的数据，从 pump、drainer 的日志里找下，看在哪一层丢掉的

12

是使用 sync-diff-inspector来做数据校验吗？
我们现在发现丢失数据的表的数据量为：504890443 条没有空窗期来做这个数据校验。
还可能会有其他办法或者工具来判断和定位这个问题吗?

13

那就通过一条不一致的记录，查询下 pump、drainer 日志，先看下是在哪个步骤丢失的把，然后再去对应的日志里看下丢失的原因

14

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。