cloud/dm: add LOCK TABLES to source privilege prerequisites#22598
cloud/dm: add LOCK TABLES to source privilege prerequisites#22598alastori wants to merge 6 commits intopingcap:release-8.5from
Conversation
Cloud DM uses consistency=flush for full data migration, which requires LOCK TABLES on the source — but the docs omitted it. Every user following the documented GRANT hits a cryptic access-denied error on full migration. - Add LOCK TABLES to privilege table and GRANT statement - Add troubleshooting entry for the access-denied error
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
ti-chi-bot
bot
added
the
missing-translation-status
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the TiDB Cloud Data Migration (DM) documentation to prevent common user errors during full data migration. It addresses a critical omission by explicitly documenting the Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
ti-chi-bot
bot
added
the
size/S
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request correctly adds the LOCK TABLES privilege to the source database requirements for Data Migration, both in the main guide and in the troubleshooting document. My review includes a minor suggestion to improve wording and terminology consistency in the new troubleshooting section, aligning it better with the documentation style guide.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
|
cc @GMHDBJD |
|
cc @yitso |
The privilege is needed for the lock fallback path, not flush directly. DM uses consistency=auto which resolves to flush (FTWRL), but falls back to lock (LOCK TABLES) if FTWRL fails — that's when the privilege is required.
|
cc @GMHDBJD @qiancai — requesting review for the LOCK TABLES privilege addition. This addresses the DM prerequisite gap discovered during Premium GA testing (RDS-specific FTWRL fallback). Lab evidence: https://github.com/alastori/tidb-sandbox/tree/main/labs/dm/lab-06-lock-tables-privilege |
LOCK TABLES is only required when migrating from managed MySQL services (RDS, Aurora) where FTWRL is restricted. Self-managed MySQL instances do not need this privilege. Updated privilege table, GRANT examples, and troubleshooting to reflect the managed-MySQL-specific scope. Lab evidence: https://github.com/alastori/tidb-sandbox/tree/main/labs/dm/lab-06-lock-tables-privilege
When migrating from managed MySQL services (RDS, Aurora) where FTWRL is restricted, DM's consistency=auto mode falls back to LOCK TABLES. Added conditional privilege documentation to dm-worker-intro, dm-precheck, and quick-start-with-dm. Confirmed with Minghao Guo: FTWRL→LOCK TABLES fallback is by design, Cloud DM defaults to consistency=auto. Lab evidence: https://github.com/alastori/tidb-sandbox/tree/main/labs/dm/lab-06-lock-tables-privilege Related: pingcap#22598 (Cloud DM docs) Related: https://tidb.atlassian.net/browse/DM-12687 (pre-check improvement)
When migrating from managed MySQL services (RDS, Aurora) where FTWRL is restricted, DM's consistency=auto mode falls back to LOCK TABLES. Added conditional privilege documentation to dm-worker-intro, dm-precheck, and quick-start-with-dm. Confirmed with Minghao Guo: FTWRL→LOCK TABLES fallback is by design, Cloud DM defaults to consistency=auto. Lab evidence: https://github.com/alastori/tidb-sandbox/tree/main/labs/dm/lab-06-lock-tables-privilege Related: pingcap#22598 (Cloud DM docs) Related: https://tidb.atlassian.net/browse/DM-12687 (pre-check improvement)
- Add Azure Database for MySQL and Google Cloud SQL to all provider lists - Fix troubleshooting note: LOCK TABLES error CAN occur on self-managed MySQL if FTWRL is unavailable for other reasons (e.g., missing RELOAD) - Use "not permitted" instead of "restricted" for consistency
When migrating from managed MySQL services (RDS, Aurora) where FTWRL is restricted, DM's consistency=auto mode falls back to LOCK TABLES. Added conditional privilege documentation to dm-worker-intro, dm-precheck, and quick-start-with-dm. Confirmed with Minghao Guo: FTWRL→LOCK TABLES fallback is by design, Cloud DM defaults to consistency=auto. Lab evidence: https://github.com/alastori/tidb-sandbox/tree/main/labs/dm/lab-06-lock-tables-privilege Related: pingcap#22598 (Cloud DM docs) Related: https://tidb.atlassian.net/browse/DM-12687 (pre-check improvement)
1 participant
Summary
LOCK TABLESto the source privilege table and GRANT statement in the Cloud DM migration guideLOCK TABLES ... Access deniederror during full migrationWhy
Cloud DM sets
consistency=autofor the dump phase (bothdataflow-serviceandserverless-servicesetConsistency: "auto"inOnTaskCreating()). For MySQL sources,autoresolves toflushat runtime (FLUSH TABLES WITH READ LOCK), which only requiresRELOAD.However, if FTWRL fails or times out (e.g., long-running queries on the source), dumpling automatically falls back to
consistency=lock, which executesLOCK TABLESSQL and requires theLOCK TABLESprivilege. Without it, the dump fails with:The DM pre-checker does not catch this because it only validates privileges for the initial
auto/flushpath, not thelockfallback (seeresolveAutoConsistency()indumpling/export/dump.goand the fallback added in tidb#36576).Granting
LOCK TABLESis defensive but correct — it ensures the dump succeeds regardless of which consistency path dumpling takes at runtime.Other TiDB Cloud docs (Dumpling migration, OSS DM precheck) already include
LOCK TABLES— this PR aligns the Cloud DM page.Test plan