cloud/dm: add LOCK TABLES to source privilege prerequisites (#22598)

Author: alastori

tidb-cloud/migrate-from-mysql-using-data-migration.md

@@ -465,11 +465,16 @@ For production workloads, it is recommended to have a dedicated user for data du
 | `RELOAD` | Global | Ensures consistent snapshots during full dump |
 | `REPLICATION SLAVE` | Global | Enables binlog streaming for incremental data migration |
 | `REPLICATION CLIENT` | Global | Provides access to binlog position and server status |
+| `LOCK TABLES` | Tables | Required when the source is a managed MySQL service (such as Amazon RDS, Aurora, ApsaraDB RDS for MySQL, Azure Database for MySQL, or Google Cloud SQL) where `FLUSH TABLES WITH READ LOCK` (FTWRL) is not permitted. In this case, DM falls back to `LOCK TABLES` to ensure consistency during full data export. Not required for self-managed MySQL instances where FTWRL is available. |
 
 For example, you can use the following `GRANT` statement in your source MySQL instance to grant corresponding privileges:
 
 ```sql
+-- For self-managed MySQL:
 GRANT SELECT, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dm_source_user'@'%';
+
+-- For managed MySQL services (such as Amazon RDS and Aurora), also grant the LOCK TABLES privilege:
+GRANT SELECT, RELOAD, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dm_source_user'@'%';
 ```
 
 #### Grant required privileges in the target <CustomContent plan="dedicated">{{{ .dedicated }}} cluster</CustomContent><CustomContent plan="essential">{{{ .essential }}} instance</CustomContent>

tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md

@@ -94,6 +94,22 @@ Failed to create a schema in the downstream TiDB cluster. This error means that
 
 To resolve this issue, you can create a schema in the TiDB cluster based on a [supported collation](/character-set-and-collation.md#character-sets-and-collations-supported-by-tidb), and then resume the task by clicking **Restart**.
 
+### Error message: "LOCK TABLES ... Access denied"
+
+The full data export fails because the source database user does not have the `LOCK TABLES` privilege. This error typically occurs when migrating from a managed MySQL service (such as Amazon RDS, Aurora, ApsaraDB RDS for MySQL, Azure Database for MySQL, or Google Cloud SQL), where `FLUSH TABLES WITH READ LOCK` (FTWRL) is not permitted by the cloud provider. In this scenario, DM uses the default `consistency=auto` mode, which falls back to `LOCK TABLES` to ensure data consistency during full export. This operation requires the `LOCK TABLES` privilege.
+
+> **Note:** 
+>
+> This error can also occur on self-managed MySQL instances if FTWRL is unavailable for other reasons, such as a missing `RELOAD` privilege.
+
+To resolve this issue, grant the `LOCK TABLES` privilege to the migration user on the source MySQL database:
+
+```sql
+GRANT LOCK TABLES ON *.* TO 'dm_source_user'@'%';
+```
+
+Then resume the task by clicking **Restart**.
+
 ## Alerts
 
 You can subscribe to TiDB Cloud alert emails to be informed in time when an alert occurs.