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.