pingcap/tidb

Dumpling will stuck while it's expect to fallback to LOCK TABLES when FTWRL blocking for a long time

Open

#56,838 创建于 2024年10月25日

在 GitHub 查看
 (0 评论) (0 反应) (0 负责人)Go (40,090 star) (6,186 fork)batch import
good first issuetype/enhancement

描述

Enhancement

in https://github.com/pingcap/tidb/pull/36576 I want to implement a fallback strategy. But in line 1420 dumpling does not use the context with timeout https://github.com/pingcap/tidb/blob/7ce5bd752f668b4037a25ded97752f3eca258100/dumpling/export/dump.go#L1409-L1422

So current behaviour is, when upstream reports error like unsupported statement for FLUSH TABLE WITH READ LOCK, dumplling will fallback to LOCK TABLES. When upstream supports it but due to active sessions or other reason FTWRL is blocking, dumpling will stuck.

Maybe in the latter case it's also acceptable to fallback?

贡献者指南

技术栈
gosql
领域
backenddatabase
议题类型
feature
难度面向新贡献者的预计实现难度，1 表示很小改动，5 表示专家级工作。
3
预计时间有经验贡献者完成调查、实现、测试并准备 pull request 的粗略时间范围。
half day
活动状态议题当前的可参与程度：新鲜、活跃、陈旧、阻塞或等待维护者输入。
fresh
清晰度议题是否清楚说明期望改动、验收标准和下一步。
clear
前置要求
Go basicscontext/timeout usageTiDB/Dumpling internals
新手友好度1-100 的估计分数，表示该议题对首次贡献者的友好程度。
40
研究方向
Look at the referenced PR #36576 to understand the existing fallback logic. In dumpling/export/dump.go, around line 1420, the code does not use a context with timeout. You need to modify that section to use a context with a timeout so that if FTWRL blocks, it can fallback to LOCK TABLES. Check if there are any existing tests for this behavior and ensure new changes are covered.
Dumpling will stuck while it's expect to fallback to LOCK TABLES when FTWRL blocking for a long time · pingcap/tidb#56838 | Good First Issue