cloud: Premium supports data migration

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

@@ -105,7 +105,7 @@ To prevent this, create the target tables in the downstream database before star
 
 <CustomContent plan="premium">
 
-- For {{{ .premium }}}, both logical mode (default) and physical mode are supported. Logical mode exports data from MySQL source databases as SQL statements and then executes them on the target {{{ .premium }}} instance, which consumes Request Capacity Units (RCUs) during the load. Physical mode uses `IMPORT INTO` on the target {{{ .premium }}} instance and is recommended for large datasets when you prioritize load throughput and cost efficiency.
+- For {{{ .premium }}}, both logical mode (default) and physical mode are supported. Logical mode exports data from MySQL source databases as SQL statements and then executes them on the target {{{ .premium }}} instance, which consumes Request Capacity Units (RCUs) during the load. Physical mode uses `IMPORT INTO` on the target {{{ .premium }}} instance and is recommended for large datasets when you prioritize load throughput and cost efficiency.
 - When you use physical mode and the migration job has started, do **NOT** enable PITR (Point-in-time Recovery) or have any changefeed on the {{{ .premium }}} instance. Otherwise, the migration job stops. If you need to enable PITR or have any changefeed, use logical mode instead to migrate data.
 - When you use physical mode, you cannot create a second migration job or import task for the {{{ .premium }}} instance before the existing data migration is completed.
 
@@ -178,7 +178,7 @@ For {{{ .essential }}}, the Data Migration feature supports the following data s
 
 <CustomContent plan="premium">
 
-For {{{ .premium }}}, the Data Migration feature supports the following MySQL-compatible source databases, and **MySQL** is the only data source type available in the migration job wizard. For supported connection methods, see [Ensure network connectivity](#ensure-network-connectivity).
+For {{{ .premium }}}, the Data Migration feature supports the following MySQL-compatible source databases, and **MySQL** is the only data source type available in the migration job wizard. For supported connection methods, see [Ensure network connectivity](#ensure-network-connectivity).
 
 | Data source                                      | Supported versions |
 |:-------------------------------------------------|:-------------------|
@@ -433,7 +433,7 @@ AWS does not support direct PrivateLink access to RDS or Aurora. Therefore, you
 
     For detailed instructions, see [Manage permissions](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-permissions) in AWS documentation.
 
-4. Optional: Test connectivity from a bastion or client inside the same VPC before starting the migration:
+4. Optional: Test connectivity from a bastion or client inside the same VPC before starting the migration:
 
     ```shell
     mysql -h <private‑host> -P 3306 -u <user> -p --ssl-ca=<path-to-provider-ca.pem> -e "SELECT version();"
@@ -520,7 +520,7 @@ AWS does not support direct PrivateLink access to RDS or Aurora. Therefore, you
 
     For detailed instructions, see [Manage permissions](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-permissions) in AWS documentation.
 
-4. Optional: Test connectivity from a bastion or client inside the same VPC before starting the migration:
+4. Optional: Test connectivity from a bastion or client inside the same VPC before starting the migration:
 
     ```shell
     mysql -h <private‑host> -P 3306 -u <user> -p --ssl-ca=<path-to-provider-ca.pem> -e "SELECT version();"
@@ -560,7 +560,7 @@ If you use AWS VPC peering or Google Cloud VPC network peering, see the followin
 
 If your MySQL service is in an AWS VPC, take the following steps:
 
-1. [Set up a VPC peering connection](/tidb-cloud/set-up-vpc-peering-connections.md) between the VPC of the MySQL service and your <CustomContent plan="dedicated">{{{ .dedicated }}} cluster</CustomContent>.
+1. [Set up a VPC peering connection](/tidb-cloud/set-up-vpc-peering-connections.md) between the VPC of the MySQL service and your <CustomContent plan="dedicated">{{{ .dedicated }}} cluster</CustomContent>.
 
 2. Modify the inbound rules of the security group that the MySQL service is associated with.
 
@@ -638,7 +638,7 @@ GRANT SELECT, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dm_source
 GRANT SELECT, RELOAD, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dm_source_user'@'%';
 ```
 
-#### Grant required privileges in the target TiDB Cloud resource
+#### Grant required privileges in the target TiDB Cloud resource
 
 For testing purposes, you can use the `root` account of your <CustomContent plan="dedicated">{{{ .dedicated }}} cluster</CustomContent><CustomContent plan="essential">{{{ .essential }}} instance</CustomContent><CustomContent plan="premium">{{{ .premium }}} instance</CustomContent>.
 
@@ -807,6 +807,12 @@ In the **Choose migration job type** step, you can choose to migrate both existi
 
 </CustomContent>
 
+<CustomContent plan="premium">
+
+In the **Migration Type** step, you can choose **Full + Incremental** to migrate both existing data and incremental data, or **Incremental only** to migrate only incremental data.
+
+</CustomContent>
+
 ### Migrate existing data and incremental data
 
 <CustomContent plan="dedicated">
@@ -821,8 +827,8 @@ You can use **physical mode** or **logical mode** to migrate **existing data** a
 
 > **Note:**
 >
-> - When you use physical mode, you cannot create a second migration job or import task for the <CustomContent plan="dedicated">{{{ .dedicated }}} cluster</CustomContent><CustomContent plan="essential">{{{ .essential }}} instance</CustomContent><CustomContent plan="premium">{{{ .premium }}} instance</CustomContent> before the existing data migration is completed.
-> - When you use physical mode and the migration job has started, do **NOT** enable PITR (Point-in-time Recovery) or have any changefeed on the <CustomContent plan="dedicated">{{{ .dedicated }}} cluster</CustomContent><CustomContent plan="essential">{{{ .essential }}} instance</CustomContent><CustomContent plan="premium">{{{ .premium }}} instance</CustomContent>. Otherwise, the migration job stops. If you need to enable PITR or have any changefeed, use logical mode instead to migrate data.
+> - When you use physical mode, you cannot create a second migration job or import task for the {{{ .dedicated }}} cluster before the existing data migration is completed.
+> - When you use physical mode and the migration job has started, do **NOT** enable PITR (Point-in-time Recovery) or have any changefeed on the {{{ .dedicated }}} cluster. Otherwise, the migration job stops. If you need to enable PITR or have any changefeed, use logical mode instead to migrate data.
 
 Physical mode exports the MySQL source data as fast as possible, so [different specifications](/tidb-cloud/tidb-cloud-billing-dm.md#specifications-for-data-migration) have different performance impacts on QPS and TPS of the MySQL source database during data export. The following table shows the performance regression of each specification.
 
@@ -842,6 +848,23 @@ Currently you can only use **logical mode** to migrate **existing data**. This m
 
 </CustomContent>
 
+<CustomContent plan="premium">
+
+To migrate data to {{{ .premium }}} once and for all, choose **Full + Incremental**, which ensures data consistency between the source and target databases.
+
+You can use **physical mode** or **logical mode** for **existing data migration**:
+
+- The default mode is **logical mode**. This mode exports data from MySQL source databases as SQL statements and then executes them on the target {{{ .premium }}} instance. In this mode, the target tables can be either empty or non-empty before migration, but performance is slower than physical mode.
+
+- For large datasets, you can choose **physical mode**. This mode uses `IMPORT INTO` on the target {{{ .premium }}} instance for faster loading. Physical mode requires the target tables to be empty before migration. If precheck detects that the selected target tables are not empty, the migration job automatically falls back to logical mode.
+
+> **Note:**
+>
+> - When you use physical mode, you cannot create a second migration job or import task for the {{{ .premium }}} instance before the existing data migration is completed.
+> - When you use physical mode and the migration job has started, do **NOT** enable PITR (Point-in-time Recovery) or have any changefeed on the {{{ .premium }}} instance. Otherwise, the migration job stops. If you need to enable PITR or have any changefeed, use logical mode instead to migrate data.
+
+</CustomContent>
+
 <CustomContent plan="dedicated">
 
 ### Migrate only existing data
@@ -896,6 +919,22 @@ If you encounter any problems during the migration, see [Migration errors and so
 
 </CustomContent>
 
+<CustomContent plan="premium">
+
+## Step 6: Monitor the migration progress
+
+After the migration job is created, you can view the migration progress on the **Migration Job Details** page. The migration progress is displayed in the **Stage and Status** area.
+
+You can pause or delete a migration job when it is running. If a migration job has failed, you can resume it after solving the problem. You can delete a migration job in any status.
+
+If you encounter any problems during the migration, see [Migration errors and solutions](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions).
+
+> **Note:**
+>
+> {{{ .premium }}} automatically manages migration job resources. The worker pool scales up and down based on the number of active migration jobs, so you do not need to choose a specification or perform manual scaling.
+
+</CustomContent>
+
 <CustomContent plan="dedicated">
 
 ## Step 6: Choose a spec and start migration
@@ -938,7 +977,7 @@ When scaling a migration job specification, note the following:
 
 1. Log in to the [TiDB Cloud console](https://tidbcloud.com/) and navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page.
 
-2. Click the name of your target <CustomContent plan="dedicated">{{{ .dedicated }}} cluster</CustomContent><CustomContent plan="essential">{{{ .essential }}} instance</CustomContent><CustomContent plan="premium">{{{ .premium }}} instance</CustomContent> to go to its overview page, and then click **Data** > **Data Migration** in the left navigation pane.
+2. Click the name of your target {{{ .dedicated }}} cluster to go to its overview page, and then click **Data** > **Data Migration** in the left navigation pane.
 
 3. On the **Data Migration** page, locate the migration job you want to scale. In the **Action** column, click **...** > **Scale Up/Down**.