dm: add LOCK TABLES privilege note for managed MySQL sources#21467
dm: add LOCK TABLES privilege note for managed MySQL sources#21467qiancai wants to merge 4 commits intopingcap:masterfrom
Conversation
|
[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 |
|
@qiancai: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
| @@ -67,8 +67,12 @@ tiup dmctl check-task ./task.yaml | |||
| * (必须)上游数据库的 dump 权限 | |||
|
|
|||
| - 检查是否有 INFORMATION_SCHEMA 和 dump 表的 SELECT 权限。 | |||
There was a problem hiding this comment.
| - 检查是否有 INFORMATION_SCHEMA 和 dump 表的 SELECT 权限。 | |
| - 检查是否有 `INFORMATION_SCHEMA` 和 dump 表的 `SELECT` 权限。 |
| - 检查是否有 INFORMATION_SCHEMA 和 dump 表的 SELECT 权限。 | ||
| - 如果 consistency=flush,将检查是否有 RELOAD 权限。 | ||
| - 如果 consistency=flush/lock,将检查是否有 dump 表的 LOCK TABLES 权限。 | ||
| - 如果 `consistency=flush`,将检查是否有 RELOAD 权限。 |
There was a problem hiding this comment.
| - 如果 `consistency=flush`,将检查是否有 RELOAD 权限。 | |
| - 如果 `consistency=flush`,将检查是否有 `RELOAD` 权限。 |
|
|
||
| > **注意:** | ||
| > | ||
| > 当 `consistency=auto`(默认值)时,DM 会首先尝试执行 `FLUSH TABLES WITH READ LOCK`(FTWRL)。如果 FTWRL 不可用,DM 会回退使用 `LOCK TABLES`。这种回退在托管型 MySQL 服务中较为常见(例如 Amazon RDS、Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL 和 Google Cloud SQL),因为这些服务通常不允许执行 FTWRL。在这种情况下,运行时需要具备 `LOCK TABLES` 权限,但当前的 precheck 并不会验证该权限。完整的权限列表,请参见[上游数据库用户权限](/dm/dm-worker-intro.md#上游数据库用户权限)。 |
There was a problem hiding this comment.
| > 当 `consistency=auto`(默认值)时,DM 会首先尝试执行 `FLUSH TABLES WITH READ LOCK`(FTWRL)。如果 FTWRL 不可用,DM 会回退使用 `LOCK TABLES`。这种回退在托管型 MySQL 服务中较为常见(例如 Amazon RDS、Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL 和 Google Cloud SQL),因为这些服务通常不允许执行 FTWRL。在这种情况下,运行时需要具备 `LOCK TABLES` 权限,但当前的 precheck 并不会验证该权限。完整的权限列表,请参见[上游数据库用户权限](/dm/dm-worker-intro.md#上游数据库用户权限)。 | |
| > 当 `consistency=auto`(默认值)时,DM 会首先尝试执行 `FLUSH TABLES WITH READ LOCK` (FTWRL)。如果 FTWRL 不可用,DM 会回退使用 `LOCK TABLES`。这种回退在托管型 MySQL 服务中较为常见(例如 Amazon RDS、Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL 和 Google Cloud SQL),因为这些服务通常不允许执行 FTWRL。在这种情况下,运行时需要具备 `LOCK TABLES` 权限,但当前的 precheck 并不会验证该权限。完整的权限列表,请参见[上游数据库用户权限](/dm/dm-worker-intro.md#上游数据库用户权限)。 |
|
|
||
| > **注意:** | ||
| > | ||
| > 如果从托管型 MySQL 服务(例如 Amazon RDS、Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL 或 Google Cloud SQL)迁移数据,且该服务不允许执行 `FLUSH TABLES WITH READ LOCK`(FTWRL),还需要授予 `LOCK TABLES` 权限。使用默认的 `consistency=auto` 设置时,如果 FTWRL 不可用,DM 会回退到 `LOCK TABLES`。 |
There was a problem hiding this comment.
| > 如果从托管型 MySQL 服务(例如 Amazon RDS、Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL 或 Google Cloud SQL)迁移数据,且该服务不允许执行 `FLUSH TABLES WITH READ LOCK`(FTWRL),还需要授予 `LOCK TABLES` 权限。使用默认的 `consistency=auto` 设置时,如果 FTWRL 不可用,DM 会回退到 `LOCK TABLES`。 | |
| > 如果从托管型 MySQL 服务(例如 Amazon RDS、Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL 或 Google Cloud SQL)迁移数据,且该服务不允许执行 `FLUSH TABLES WITH READ LOCK` (FTWRL),还需要授予 `LOCK TABLES` 权限。使用默认的 `consistency=auto` 设置时,如果 FTWRL 不可用,DM 会回退到 `LOCK TABLES`。 |
| GRANT SELECT ON db1.* TO 'your_user'@'your_wildcard_of_host'; | ||
| ``` | ||
|
|
||
| 如果从不允许执行 `FLUSH TABLES WITH READ LOCK`(FTWRL)的托管型 MySQL 服务迁移数据,还需要授予 `LOCK TABLES` 权限: |
There was a problem hiding this comment.
| 如果从不允许执行 `FLUSH TABLES WITH READ LOCK`(FTWRL)的托管型 MySQL 服务迁移数据,还需要授予 `LOCK TABLES` 权限: | |
| 如果从不允许执行 `FLUSH TABLES WITH READ LOCK` (FTWRL) 的托管型 MySQL 服务迁移数据,还需要授予 `LOCK TABLES` 权限: |
[LGTM Timeline notifier]Timeline:
|
This PR is translated from: pingcap/docs#22605
What is changed, added or deleted?
Added conditional
LOCK TABLESprivilege documentation for managed MySQL sources (Amazon RDS, Aurora, Google Cloud SQL) across three DM docs pages.Background: DM defaults to
consistency=auto. On managed MySQL whereFLUSH TABLES WITH READ LOCKis restricted by the cloud provider, DM falls back toLOCK TABLES. This privilege is not needed on self-managed MySQL instances. Confirmed with @GMHDBJD (Minghao Guo): the FTWRL → LOCK TABLES fallback inautomode is by design.Changes:
dm/dm-precheck.md: Clarified thatLOCK TABLESis needed forautofallback on managed MySQL, not justflush/lockdm/dm-worker-intro.md: AddedLOCK TABLESto privilege table with managed-MySQL scope note; added conditional GRANT exampledm/quick-start-with-dm.md: Added note pointing to dm-worker-intro for managed MySQL sources (×2 instances)Evidence: Lab-06: LOCK TABLES privilege testing (9 scenarios, vanilla MySQL vs RDS)
Related:
Which TiDB version(s) do your changes apply to?
cc @GMHDBJD @qiancai @OliverS929