From b8d4658e03a027997883cb8796be9837ad7462f1 Mon Sep 17 00:00:00 2001
From: Aolin <aolinz@outlook.com>
Date: Tue, 5 Dec 2023 18:20:23 +0800
Subject: [PATCH] feat: remove copyable strings from md files (#31)

---
 sync_pr.sh                                    | 14 ++++++++
 .../grant-permissions-to-remote-storage.md    | 16 ---------
 .../grant-permissions-to-remote-storage.md    | 16 ---------
 .../en/tidb/master/upgrade-tidb-using-tiup.md | 34 -------------------
 .../release-6.7/upgrade-tidb-using-tiup.md    | 34 -------------------
 .../grant-permissions-to-remote-storage.md    | 18 ----------
 .../grant-permissions-to-remote-storage.md    | 18 ----------
 .../master/develop/dev-guide-insert-data.md   |  8 -----
 ...ide-sample-application-java-spring-boot.md |  8 -----
 .../develop/dev-guide-insert-data.md          |  8 -----
 ...ide-sample-application-java-spring-boot.md |  8 -----
 .../develop/dev-guide-insert-data.md          |  8 -----
 ...ide-sample-application-java-spring-boot.md | 12 -------
 .../master/develop/dev-guide-insert-data.md   |  8 -----
 ...ide-sample-application-java-spring-boot.md |  8 -----
 .../grant-permissions-to-remote-storage.md    | 16 ---------
 .../grant-permissions-to-remote-storage.md    | 18 ----------
 17 files changed, 14 insertions(+), 238 deletions(-)

diff --git a/sync_pr.sh b/sync_pr.sh
index d4caee1..6348a33 100755
--- a/sync_pr.sh
+++ b/sync_pr.sh
@@ -87,6 +87,13 @@ generate_sync_tasks() {
   esac
 }
 
+remove_copyable() {
+  # Remove copyable strings ({{< copyable "..." >}}\n) from Markdown files.
+  $FIND . -name '*.md' | while IFS= read -r FILE; do
+    $SED -i '/{{< copyable ".*" >}}/{N;d}' "$FILE"
+  done
+}
+
 clone_repo() {
 
   # Clone repo if it doesn't exist already.
@@ -115,6 +122,9 @@ perform_sync_task() {
     git -C "$SRC_DIR" diff --merge-base --name-only --diff-filter=AMR origin/"$BASE_BRANCH" --relative | tee /dev/fd/2 |
       rsync -av --files-from=- "$SRC_DIR" "$DEST_DIR"
 
+    # Remove copyable strings.
+    (cd "$DEST_DIR" && remove_copyable)
+
     if [[ "$IS_CLOUD" && -f "$DEST_DIR/TOC-tidb-cloud.md" ]]; then
       process_cloud_toc "$DEST_DIR"
     fi
@@ -132,6 +142,10 @@ commit_changes() {
   git commit -m "$COMMIT_MESS" || echo "No changes to commit"
 }
 
+# Select appropriate versions of find and sed depending on the operating system.
+FIND=$(which gfind || which find)
+SED=$(which gsed || which sed)
+
 # Get the directory of this script.
 SCRIPT_DIR=$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" &>/dev/null && pwd)
 cd "$SCRIPT_DIR"
diff --git a/test/sync_mult_prs/data/markdown-pages/en/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md b/test/sync_mult_prs/data/markdown-pages/en/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
index 2e66079..003596e 100644
--- a/test/sync_mult_prs/data/markdown-pages/en/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
+++ b/test/sync_mult_prs/data/markdown-pages/en/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
@@ -17,8 +17,6 @@ The AWS client can read `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` from the
 
 Create the `s3-secret` secret by running the following command. Use the AWS account's AccessKey and SecretKey. The secret stores the credential used for accessing S3-compatible storage.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1
 ```
@@ -70,8 +68,6 @@ If you associate the user's [IAM](https://aws.amazon.com/cn/iam/) role with the
 
     When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on S3-compatible storage as the BR Pod does. Therefore, you need to add annotations to the TiKV Pod to associate it with the IAM role.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"annotations":{"iam.amazonaws.com/role":"arn:aws:iam::123456789012:role/user"}}}}'
     ```
@@ -126,8 +122,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 3. Associate the IAM role with the `ServiceAccount` resources.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl annotate sa tidb-backup-manager eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test1
     ```
@@ -142,8 +136,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 4. Associate the `ServiceAccount` with the TiKV Pod:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"serviceAccount": "tidb-backup-manager"}}}'
     ```
@@ -160,8 +152,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 Create the `gcs-secret` secret which stores the credential used to access GCS. The `google-credentials.json` file stores the service account key that you have downloaded from the Google Cloud console. Refer to [Google Cloud documentation](https://cloud.google.com/docs/authentication/getting-started) for details.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1
 ```
@@ -176,8 +166,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT` and `AZURE_STORAGE_KEY` from t
 
 Run the following command to create the `azblob-secret` secret and use your Azure account access key to grant permissions. The secret stores the credential used for accessing Azure Blob Storage.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic azblob-secret --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_STORAGE_KEY=yyy --namespace=test1
 ```
@@ -188,8 +176,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT`, `AZURE_CLIENT_ID`, `AZURE_TEN
 
 1. Create the `azblob-secret-ad` secret by running the following command. Use the Active Directory (AD) of your Azure account. The secret stores the credential used for accessing Azure Blob Storage.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl create secret generic azblob-secret-ad --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_CLIENT_ID=yyy --from-literal=AZURE_TENANT_ID=zzz --from-literal=AZURE_CLIENT_SECRET=aaa --namespace=test1
     ```
@@ -198,8 +184,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT`, `AZURE_CLIENT_ID`, `AZURE_TEN
 
     When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on Azure Blob Storage as the BR Pod does. Therefore, you need to associate the TiKV Pod with the secret.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"envFrom":[{"secretRef":{"name":"azblob-secret-ad"}}]}}}'
     ```
diff --git a/test/sync_mult_prs/data/markdown-pages/en/tidb-in-kubernetes/release-6.7/grant-permissions-to-remote-storage.md b/test/sync_mult_prs/data/markdown-pages/en/tidb-in-kubernetes/release-6.7/grant-permissions-to-remote-storage.md
index 2e66079..003596e 100644
--- a/test/sync_mult_prs/data/markdown-pages/en/tidb-in-kubernetes/release-6.7/grant-permissions-to-remote-storage.md
+++ b/test/sync_mult_prs/data/markdown-pages/en/tidb-in-kubernetes/release-6.7/grant-permissions-to-remote-storage.md
@@ -17,8 +17,6 @@ The AWS client can read `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` from the
 
 Create the `s3-secret` secret by running the following command. Use the AWS account's AccessKey and SecretKey. The secret stores the credential used for accessing S3-compatible storage.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1
 ```
@@ -70,8 +68,6 @@ If you associate the user's [IAM](https://aws.amazon.com/cn/iam/) role with the
 
     When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on S3-compatible storage as the BR Pod does. Therefore, you need to add annotations to the TiKV Pod to associate it with the IAM role.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"annotations":{"iam.amazonaws.com/role":"arn:aws:iam::123456789012:role/user"}}}}'
     ```
@@ -126,8 +122,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 3. Associate the IAM role with the `ServiceAccount` resources.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl annotate sa tidb-backup-manager eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test1
     ```
@@ -142,8 +136,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 4. Associate the `ServiceAccount` with the TiKV Pod:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"serviceAccount": "tidb-backup-manager"}}}'
     ```
@@ -160,8 +152,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 Create the `gcs-secret` secret which stores the credential used to access GCS. The `google-credentials.json` file stores the service account key that you have downloaded from the Google Cloud console. Refer to [Google Cloud documentation](https://cloud.google.com/docs/authentication/getting-started) for details.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1
 ```
@@ -176,8 +166,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT` and `AZURE_STORAGE_KEY` from t
 
 Run the following command to create the `azblob-secret` secret and use your Azure account access key to grant permissions. The secret stores the credential used for accessing Azure Blob Storage.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic azblob-secret --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_STORAGE_KEY=yyy --namespace=test1
 ```
@@ -188,8 +176,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT`, `AZURE_CLIENT_ID`, `AZURE_TEN
 
 1. Create the `azblob-secret-ad` secret by running the following command. Use the Active Directory (AD) of your Azure account. The secret stores the credential used for accessing Azure Blob Storage.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl create secret generic azblob-secret-ad --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_CLIENT_ID=yyy --from-literal=AZURE_TENANT_ID=zzz --from-literal=AZURE_CLIENT_SECRET=aaa --namespace=test1
     ```
@@ -198,8 +184,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT`, `AZURE_CLIENT_ID`, `AZURE_TEN
 
     When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on Azure Blob Storage as the BR Pod does. Therefore, you need to associate the TiKV Pod with the secret.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"envFrom":[{"secretRef":{"name":"azblob-secret-ad"}}]}}}'
     ```
diff --git a/test/sync_mult_prs/data/markdown-pages/en/tidb/master/upgrade-tidb-using-tiup.md b/test/sync_mult_prs/data/markdown-pages/en/tidb/master/upgrade-tidb-using-tiup.md
index 700c2d4..804aaa9 100644
--- a/test/sync_mult_prs/data/markdown-pages/en/tidb/master/upgrade-tidb-using-tiup.md
+++ b/test/sync_mult_prs/data/markdown-pages/en/tidb/master/upgrade-tidb-using-tiup.md
@@ -59,8 +59,6 @@ Before upgrading your TiDB cluster, you first need to upgrade TiUP or TiUP mirro
 
 1. Upgrade the TiUP version. It is recommended that the TiUP version is `1.11.3` or later.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup update --self
     tiup --version
@@ -68,8 +66,6 @@ Before upgrading your TiDB cluster, you first need to upgrade TiUP or TiUP mirro
 
 2. Upgrade the TiUP Cluster version. It is recommended that the TiUP Cluster version is `1.11.3` or later.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup update cluster
     tiup cluster --version
@@ -83,8 +79,6 @@ Before upgrading your TiDB cluster, you first need to upgrade TiUP or TiUP mirro
 
 Refer to [Deploy a TiDB Cluster Using TiUP - Deploy TiUP offline](/production-deployment-using-tiup.md#deploy-tiup-offline) to download the TiUP mirror of the new version and upload it to the control machine. After executing `local_install.sh`, TiUP will complete the overwrite upgrade.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tar xzvf tidb-community-server-${version}-linux-amd64.tar.gz
 sh tidb-community-server-${version}-linux-amd64/local_install.sh
@@ -93,8 +87,6 @@ source /home/tidb/.bash_profile
 
 After the overwrite upgrade, run the following command to merge the server and toolkit offline mirrors to the server directory:
 
-{{< copyable "shell-regular" >}}
-
 ```bash
 tar xf tidb-community-toolkit-${version}-linux-amd64.tar.gz
 ls -ld tidb-community-server-${version}-linux-amd64 tidb-community-toolkit-${version}-linux-amd64
@@ -105,8 +97,6 @@ tiup mirror merge ../tidb-community-toolkit-${version}-linux-amd64
 
 After merging the mirrors, run the following command to upgrade the TiUP Cluster component:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup update cluster
 ```
@@ -124,8 +114,6 @@ Now, the offline mirror has been upgraded successfully. If an error occurs durin
 
 1. Enter the `vi` editing mode to edit the topology file:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster edit-config <cluster-name>
     ```
@@ -142,8 +130,6 @@ Now, the offline mirror has been upgraded successfully. If an error occurs durin
 
 To avoid the undefined behaviors or other issues during the upgrade, it is recommended to check the health status of Regions of the current cluster before the upgrade. To do that, you can use the `check` sub-command.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster check <cluster-name> --cluster
 ```
@@ -174,16 +160,12 @@ If your application has a maintenance window for the database to be stopped for
 
 #### Online upgrade
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster upgrade <cluster-name> <version>
 ```
 
 For example, if you want to upgrade the cluster to v7.1.0:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster upgrade <cluster-name> v7.1.0
 ```
@@ -207,24 +189,18 @@ tiup cluster upgrade <cluster-name> v7.1.0
 
 1. Before the offline upgrade, you first need to stop the entire cluster.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster stop <cluster-name>
     ```
 
 2. Use the `upgrade` command with the `--offline` option to perform the offline upgrade. Fill in the name of your cluster for `<cluster-name>` and the version to upgrade to for `<version>`, such as `v7.1.0`.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster upgrade <cluster-name> <version> --offline
     ```
 
 3. After the upgrade, the cluster will not be automatically restarted. You need to use the `start` command to restart it.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster start <cluster-name>
     ```
@@ -233,8 +209,6 @@ tiup cluster upgrade <cluster-name> v7.1.0
 
 Execute the `display` command to view the latest cluster version `TiDB Version`:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster display <cluster-name>
 ```
@@ -255,8 +229,6 @@ Re-execute the `tiup cluster upgrade` command to resume the upgrade. The upgrade
 
 1. Execute `tiup cluster audit` to see the operation records:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster audit
     ```
@@ -265,8 +237,6 @@ Re-execute the `tiup cluster upgrade` command to resume the upgrade. The upgrade
 
 2. Execute `tiup cluster replay <audit-id>` to retry the corresponding operation:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster replay <audit-id>
     ```
@@ -275,8 +245,6 @@ Re-execute the `tiup cluster upgrade` command to resume the upgrade. The upgrade
 
 You can specify `--force`. Then the processes of transferring PD leader and evicting TiKV leader are skipped during the upgrade. The cluster is directly restarted to update the version, which has a great impact on the cluster that runs online. In the following command, `<version>` is the version to upgrade to, such as `v7.1.0`.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster upgrade <cluster-name> <version> --force
 ```
@@ -285,8 +253,6 @@ tiup cluster upgrade <cluster-name> <version> --force
 
 You can upgrade the tool version by using TiUP to install the `ctl` component of the corresponding version:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup install ctl:v7.1.0
 ```
diff --git a/test/sync_mult_prs/data/markdown-pages/en/tidb/release-6.7/upgrade-tidb-using-tiup.md b/test/sync_mult_prs/data/markdown-pages/en/tidb/release-6.7/upgrade-tidb-using-tiup.md
index 700c2d4..804aaa9 100644
--- a/test/sync_mult_prs/data/markdown-pages/en/tidb/release-6.7/upgrade-tidb-using-tiup.md
+++ b/test/sync_mult_prs/data/markdown-pages/en/tidb/release-6.7/upgrade-tidb-using-tiup.md
@@ -59,8 +59,6 @@ Before upgrading your TiDB cluster, you first need to upgrade TiUP or TiUP mirro
 
 1. Upgrade the TiUP version. It is recommended that the TiUP version is `1.11.3` or later.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup update --self
     tiup --version
@@ -68,8 +66,6 @@ Before upgrading your TiDB cluster, you first need to upgrade TiUP or TiUP mirro
 
 2. Upgrade the TiUP Cluster version. It is recommended that the TiUP Cluster version is `1.11.3` or later.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup update cluster
     tiup cluster --version
@@ -83,8 +79,6 @@ Before upgrading your TiDB cluster, you first need to upgrade TiUP or TiUP mirro
 
 Refer to [Deploy a TiDB Cluster Using TiUP - Deploy TiUP offline](/production-deployment-using-tiup.md#deploy-tiup-offline) to download the TiUP mirror of the new version and upload it to the control machine. After executing `local_install.sh`, TiUP will complete the overwrite upgrade.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tar xzvf tidb-community-server-${version}-linux-amd64.tar.gz
 sh tidb-community-server-${version}-linux-amd64/local_install.sh
@@ -93,8 +87,6 @@ source /home/tidb/.bash_profile
 
 After the overwrite upgrade, run the following command to merge the server and toolkit offline mirrors to the server directory:
 
-{{< copyable "shell-regular" >}}
-
 ```bash
 tar xf tidb-community-toolkit-${version}-linux-amd64.tar.gz
 ls -ld tidb-community-server-${version}-linux-amd64 tidb-community-toolkit-${version}-linux-amd64
@@ -105,8 +97,6 @@ tiup mirror merge ../tidb-community-toolkit-${version}-linux-amd64
 
 After merging the mirrors, run the following command to upgrade the TiUP Cluster component:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup update cluster
 ```
@@ -124,8 +114,6 @@ Now, the offline mirror has been upgraded successfully. If an error occurs durin
 
 1. Enter the `vi` editing mode to edit the topology file:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster edit-config <cluster-name>
     ```
@@ -142,8 +130,6 @@ Now, the offline mirror has been upgraded successfully. If an error occurs durin
 
 To avoid the undefined behaviors or other issues during the upgrade, it is recommended to check the health status of Regions of the current cluster before the upgrade. To do that, you can use the `check` sub-command.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster check <cluster-name> --cluster
 ```
@@ -174,16 +160,12 @@ If your application has a maintenance window for the database to be stopped for
 
 #### Online upgrade
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster upgrade <cluster-name> <version>
 ```
 
 For example, if you want to upgrade the cluster to v7.1.0:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster upgrade <cluster-name> v7.1.0
 ```
@@ -207,24 +189,18 @@ tiup cluster upgrade <cluster-name> v7.1.0
 
 1. Before the offline upgrade, you first need to stop the entire cluster.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster stop <cluster-name>
     ```
 
 2. Use the `upgrade` command with the `--offline` option to perform the offline upgrade. Fill in the name of your cluster for `<cluster-name>` and the version to upgrade to for `<version>`, such as `v7.1.0`.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster upgrade <cluster-name> <version> --offline
     ```
 
 3. After the upgrade, the cluster will not be automatically restarted. You need to use the `start` command to restart it.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster start <cluster-name>
     ```
@@ -233,8 +209,6 @@ tiup cluster upgrade <cluster-name> v7.1.0
 
 Execute the `display` command to view the latest cluster version `TiDB Version`:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster display <cluster-name>
 ```
@@ -255,8 +229,6 @@ Re-execute the `tiup cluster upgrade` command to resume the upgrade. The upgrade
 
 1. Execute `tiup cluster audit` to see the operation records:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster audit
     ```
@@ -265,8 +237,6 @@ Re-execute the `tiup cluster upgrade` command to resume the upgrade. The upgrade
 
 2. Execute `tiup cluster replay <audit-id>` to retry the corresponding operation:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster replay <audit-id>
     ```
@@ -275,8 +245,6 @@ Re-execute the `tiup cluster upgrade` command to resume the upgrade. The upgrade
 
 You can specify `--force`. Then the processes of transferring PD leader and evicting TiKV leader are skipped during the upgrade. The cluster is directly restarted to update the version, which has a great impact on the cluster that runs online. In the following command, `<version>` is the version to upgrade to, such as `v7.1.0`.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster upgrade <cluster-name> <version> --force
 ```
@@ -285,8 +253,6 @@ tiup cluster upgrade <cluster-name> <version> --force
 
 You can upgrade the tool version by using TiUP to install the `ctl` component of the corresponding version:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup install ctl:v7.1.0
 ```
diff --git a/test/sync_mult_prs/data/markdown-pages/zh/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md b/test/sync_mult_prs/data/markdown-pages/zh/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
index deab93b..6aba9d3 100644
--- a/test/sync_mult_prs/data/markdown-pages/zh/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
+++ b/test/sync_mult_prs/data/markdown-pages/zh/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
@@ -17,8 +17,6 @@ AWS 的客户端支持读取进程环境变量中的 `AWS_ACCESS_KEY_ID` 以及
 
 创建 `s3-secret` secret，在以下命令中使用 AWS 账号的 AccessKey 和 SecretKey 进行授权。该 secret 存放用于访问 S3 兼容存储的凭证。
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1
 ```
@@ -66,8 +64,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
     在使用 BR 备份的过程中，TiKV Pod 和 BR Pod 一样需要对 S3 存储进行读写操作，所以这里需要给 TiKV Pod 打上 annotation 来绑定 IAM 角色。
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"annotations":{"iam.amazonaws.com/role":"arn:aws:iam::123456789012:role/user"}}}}'
     ```
@@ -94,8 +90,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
     如果是进行基于 AWS EBS 快照的备份和恢复，除完整的 S3 权限 `AmazonS3FullAccess` 外，还需要以下权限：
 
-    {{< copyable "shell-regular" >}}
-
     ```json
             {
             "Effect": "Allow",
@@ -124,8 +118,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
 3. 绑定 IAM 到 ServiceAccount 资源上：
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl annotate sa tidb-backup-manager eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test1
     ```
@@ -140,8 +132,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
 4. 将 ServiceAccount 绑定到 TiKV Pod：
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"serviceAccount": "tidb-backup-manager"}}}'
     ```
@@ -158,8 +148,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
 创建 `gcs-secret` secret。该 secret 存放用于访问 GCS 的凭证。`google-credentials.json` 文件存放用户从 Google Cloud console 上下载的 service account key。具体操作参考 [Google Cloud 官方文档](https://cloud.google.com/docs/authentication/getting-started)。
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1
 ```
@@ -174,8 +162,6 @@ Azure 的客户端支持读取进程环境变量中的 `AZURE_STORAGE_ACCOUNT` 
 
 创建 `azblob-secret` secret，在以下命令中使用 Azure 账号的访问密钥进行授权。该 secret 存放用于访问 Azure Blob Storage 的凭证。
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic azblob-secret --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_STORAGE_KEY=yyy --namespace=test1
 ```
@@ -186,8 +172,6 @@ Azure 的客户端支持读取进程环境变量中的 `AZURE_STORAGE_ACCOUNT`
 
 1. 创建 `azblob-secret-ad` secret，在以下命令中使用 Azure 账号的 AD 进行授权。该 secret 存放用于访问 Azure Blob Storage 的凭证。
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl create secret generic azblob-secret-ad --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_CLIENT_ID=yyy --from-    literal=AZURE_TENANT_ID=zzz --from-literal=AZURE_CLIENT_SECRET=aaa --namespace=test1
     ```
@@ -196,8 +180,6 @@ Azure 的客户端支持读取进程环境变量中的 `AZURE_STORAGE_ACCOUNT`
 
     在使用 BR 备份的过程中，TiKV Pod 和 BR Pod 一样需要对 Azure Blob Storage 进行读写操作，所以这里需要给 TiKV Pod 绑定 secret。
 
-     {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"envFrom":[{"secretRef":{"name":"azblob-secret-ad"}}]}}}'
     ```
diff --git a/test/sync_mult_prs/data/markdown-pages/zh/tidb-in-kubernetes/release-6.7/grant-permissions-to-remote-storage.md b/test/sync_mult_prs/data/markdown-pages/zh/tidb-in-kubernetes/release-6.7/grant-permissions-to-remote-storage.md
index deab93b..6aba9d3 100644
--- a/test/sync_mult_prs/data/markdown-pages/zh/tidb-in-kubernetes/release-6.7/grant-permissions-to-remote-storage.md
+++ b/test/sync_mult_prs/data/markdown-pages/zh/tidb-in-kubernetes/release-6.7/grant-permissions-to-remote-storage.md
@@ -17,8 +17,6 @@ AWS 的客户端支持读取进程环境变量中的 `AWS_ACCESS_KEY_ID` 以及
 
 创建 `s3-secret` secret，在以下命令中使用 AWS 账号的 AccessKey 和 SecretKey 进行授权。该 secret 存放用于访问 S3 兼容存储的凭证。
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1
 ```
@@ -66,8 +64,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
     在使用 BR 备份的过程中，TiKV Pod 和 BR Pod 一样需要对 S3 存储进行读写操作，所以这里需要给 TiKV Pod 打上 annotation 来绑定 IAM 角色。
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"annotations":{"iam.amazonaws.com/role":"arn:aws:iam::123456789012:role/user"}}}}'
     ```
@@ -94,8 +90,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
     如果是进行基于 AWS EBS 快照的备份和恢复，除完整的 S3 权限 `AmazonS3FullAccess` 外，还需要以下权限：
 
-    {{< copyable "shell-regular" >}}
-
     ```json
             {
             "Effect": "Allow",
@@ -124,8 +118,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
 3. 绑定 IAM 到 ServiceAccount 资源上：
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl annotate sa tidb-backup-manager eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test1
     ```
@@ -140,8 +132,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
 4. 将 ServiceAccount 绑定到 TiKV Pod：
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"serviceAccount": "tidb-backup-manager"}}}'
     ```
@@ -158,8 +148,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
 创建 `gcs-secret` secret。该 secret 存放用于访问 GCS 的凭证。`google-credentials.json` 文件存放用户从 Google Cloud console 上下载的 service account key。具体操作参考 [Google Cloud 官方文档](https://cloud.google.com/docs/authentication/getting-started)。
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1
 ```
@@ -174,8 +162,6 @@ Azure 的客户端支持读取进程环境变量中的 `AZURE_STORAGE_ACCOUNT` 
 
 创建 `azblob-secret` secret，在以下命令中使用 Azure 账号的访问密钥进行授权。该 secret 存放用于访问 Azure Blob Storage 的凭证。
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic azblob-secret --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_STORAGE_KEY=yyy --namespace=test1
 ```
@@ -186,8 +172,6 @@ Azure 的客户端支持读取进程环境变量中的 `AZURE_STORAGE_ACCOUNT`
 
 1. 创建 `azblob-secret-ad` secret，在以下命令中使用 Azure 账号的 AD 进行授权。该 secret 存放用于访问 Azure Blob Storage 的凭证。
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl create secret generic azblob-secret-ad --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_CLIENT_ID=yyy --from-    literal=AZURE_TENANT_ID=zzz --from-literal=AZURE_CLIENT_SECRET=aaa --namespace=test1
     ```
@@ -196,8 +180,6 @@ Azure 的客户端支持读取进程环境变量中的 `AZURE_STORAGE_ACCOUNT`
 
     在使用 BR 备份的过程中，TiKV Pod 和 BR Pod 一样需要对 Azure Blob Storage 进行读写操作，所以这里需要给 TiKV Pod 绑定 secret。
 
-     {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"envFrom":[{"secretRef":{"name":"azblob-secret-ad"}}]}}}'
     ```
diff --git a/test/sync_mult_prs/data/markdown-pages/zh/tidb/master/develop/dev-guide-insert-data.md b/test/sync_mult_prs/data/markdown-pages/zh/tidb/master/develop/dev-guide-insert-data.md
index aef7b5a..26e2df0 100644
--- a/test/sync_mult_prs/data/markdown-pages/zh/tidb/master/develop/dev-guide-insert-data.md
+++ b/test/sync_mult_prs/data/markdown-pages/zh/tidb/master/develop/dev-guide-insert-data.md
@@ -23,16 +23,12 @@ aliases: ['/zh/tidb/dev/insert-data']
 
 - 一个**多行插入语句**：
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (1, 1000, 1), (2, 230, 2), (3, 300, 5);
     ```
 
 - 多个**单行插入语句**：
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (1, 1000, 1);
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (2, 230, 2);
@@ -273,16 +269,12 @@ ERROR 8216 (HY000): Invalid auto random: Explicit insertion on auto_random colum
 
 - (推荐) 插入语句中去除此列，使用 TiDB 帮你初始化的 `AUTO_RANDOM` 值。这样符合 `AUTO_RANDOM` 的语义。
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `bookshop`.`users` (`balance`, `nickname`) VALUES (0.00, 'nicky');
     ```
 
 - 如果你确认一定需要指定此列，那么可以使用 [SET 语句](/sql-statements/sql-statement-set-variable.md)通过更改用户变量的方式，允许在插入时，指定 `AUTO_RANDOM` 的列。
 
-    {{< copyable "sql" >}}
-
     ```sql
     SET @@allow_auto_random_explicit_insert = true;
     INSERT INTO `bookshop`.`users` (`id`, `balance`, `nickname`) VALUES (1, 0.00, 'nicky');
diff --git a/test/sync_mult_prs/data/markdown-pages/zh/tidb/master/develop/dev-guide-sample-application-java-spring-boot.md b/test/sync_mult_prs/data/markdown-pages/zh/tidb/master/develop/dev-guide-sample-application-java-spring-boot.md
index f823f4e..6a06a87 100644
--- a/test/sync_mult_prs/data/markdown-pages/zh/tidb/master/develop/dev-guide-sample-application-java-spring-boot.md
+++ b/test/sync_mult_prs/data/markdown-pages/zh/tidb/master/develop/dev-guide-sample-application-java-spring-boot.md
@@ -42,16 +42,12 @@ aliases: ['/zh/tidb/dev/dev-guide-sample-application-spring-boot', '/zh/tidb/dev
 
 - macOS 安装：
 
-    {{< copyable "shell-regular" >}}
-
     ```
     brew install maven
     ```
 
 - 基于 Debian 的 Linux 发行版上安装（如 Ubuntu 等）：
 
-    {{< copyable "shell-regular" >}}
-
     ```
     apt-get install maven
     ```
@@ -60,16 +56,12 @@ aliases: ['/zh/tidb/dev/dev-guide-sample-application-spring-boot', '/zh/tidb/dev
 
 - dnf 包管理器
 
-    {{< copyable "shell-regular" >}}
-
     ```
     dnf install maven
     ```
 
 - yum 包管理器
 
-    {{< copyable "shell-regular" >}}
-
     ```
     yum install maven
     ```
diff --git a/test/sync_mult_prs/data/markdown-pages/zh/tidb/release-6.7/develop/dev-guide-insert-data.md b/test/sync_mult_prs/data/markdown-pages/zh/tidb/release-6.7/develop/dev-guide-insert-data.md
index aef7b5a..26e2df0 100644
--- a/test/sync_mult_prs/data/markdown-pages/zh/tidb/release-6.7/develop/dev-guide-insert-data.md
+++ b/test/sync_mult_prs/data/markdown-pages/zh/tidb/release-6.7/develop/dev-guide-insert-data.md
@@ -23,16 +23,12 @@ aliases: ['/zh/tidb/dev/insert-data']
 
 - 一个**多行插入语句**：
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (1, 1000, 1), (2, 230, 2), (3, 300, 5);
     ```
 
 - 多个**单行插入语句**：
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (1, 1000, 1);
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (2, 230, 2);
@@ -273,16 +269,12 @@ ERROR 8216 (HY000): Invalid auto random: Explicit insertion on auto_random colum
 
 - (推荐) 插入语句中去除此列，使用 TiDB 帮你初始化的 `AUTO_RANDOM` 值。这样符合 `AUTO_RANDOM` 的语义。
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `bookshop`.`users` (`balance`, `nickname`) VALUES (0.00, 'nicky');
     ```
 
 - 如果你确认一定需要指定此列，那么可以使用 [SET 语句](/sql-statements/sql-statement-set-variable.md)通过更改用户变量的方式，允许在插入时，指定 `AUTO_RANDOM` 的列。
 
-    {{< copyable "sql" >}}
-
     ```sql
     SET @@allow_auto_random_explicit_insert = true;
     INSERT INTO `bookshop`.`users` (`id`, `balance`, `nickname`) VALUES (1, 0.00, 'nicky');
diff --git a/test/sync_mult_prs/data/markdown-pages/zh/tidb/release-6.7/develop/dev-guide-sample-application-java-spring-boot.md b/test/sync_mult_prs/data/markdown-pages/zh/tidb/release-6.7/develop/dev-guide-sample-application-java-spring-boot.md
index f823f4e..6a06a87 100644
--- a/test/sync_mult_prs/data/markdown-pages/zh/tidb/release-6.7/develop/dev-guide-sample-application-java-spring-boot.md
+++ b/test/sync_mult_prs/data/markdown-pages/zh/tidb/release-6.7/develop/dev-guide-sample-application-java-spring-boot.md
@@ -42,16 +42,12 @@ aliases: ['/zh/tidb/dev/dev-guide-sample-application-spring-boot', '/zh/tidb/dev
 
 - macOS 安装：
 
-    {{< copyable "shell-regular" >}}
-
     ```
     brew install maven
     ```
 
 - 基于 Debian 的 Linux 发行版上安装（如 Ubuntu 等）：
 
-    {{< copyable "shell-regular" >}}
-
     ```
     apt-get install maven
     ```
@@ -60,16 +56,12 @@ aliases: ['/zh/tidb/dev/dev-guide-sample-application-spring-boot', '/zh/tidb/dev
 
 - dnf 包管理器
 
-    {{< copyable "shell-regular" >}}
-
     ```
     dnf install maven
     ```
 
 - yum 包管理器
 
-    {{< copyable "shell-regular" >}}
-
     ```
     yum install maven
     ```
diff --git a/test/sync_pr_docs/data/markdown-pages/en/tidb/release-6.5/develop/dev-guide-insert-data.md b/test/sync_pr_docs/data/markdown-pages/en/tidb/release-6.5/develop/dev-guide-insert-data.md
index c75bdc4..66a2f3c 100644
--- a/test/sync_pr_docs/data/markdown-pages/en/tidb/release-6.5/develop/dev-guide-insert-data.md
+++ b/test/sync_pr_docs/data/markdown-pages/en/tidb/release-6.5/develop/dev-guide-insert-data.md
@@ -22,16 +22,12 @@ There are two ways to insert multiple rows of data. For example, if you need to
 
 - A **multi-line insertion statement**:
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (1, 1000, 1), (2, 230, 2), (3, 300, 5);
     ```
 
 - Multiple **single-line insertion statements**:
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (1, 1000, 1);
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (2, 230, 2);
@@ -284,16 +280,12 @@ There are two solutions to handle this error:
 
 - (Recommended) Remove this column from the insert statement and use the `AUTO_RANDOM` value that TiDB initialized for you. This fits the semantics of `AUTO_RANDOM`.
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `bookshop`.`users` (`balance`, `nickname`) VALUES (0.00, 'nicky');
     ```
 
 - If you are sure that you **_must_** specify this column, then you can use the [`SET` statement](https://docs.pingcap.com/zh/tidb/stable/sql-statement-set-variable) to allow the column of `AUTO_RANDOM` to be specified during insertion time by changing the user variable.
 
-    {{< copyable "sql" >}}
-
     ```sql
     SET @@allow_auto_random_explicit_insert = true;
     INSERT INTO `bookshop`.`users` (`id`, `balance`, `nickname`) VALUES (1, 0.00, 'nicky');
diff --git a/test/sync_pr_docs/data/markdown-pages/en/tidb/release-6.5/develop/dev-guide-sample-application-java-spring-boot.md b/test/sync_pr_docs/data/markdown-pages/en/tidb/release-6.5/develop/dev-guide-sample-application-java-spring-boot.md
index df23c8d..37affc0 100644
--- a/test/sync_pr_docs/data/markdown-pages/en/tidb/release-6.5/develop/dev-guide-sample-application-java-spring-boot.md
+++ b/test/sync_pr_docs/data/markdown-pages/en/tidb/release-6.5/develop/dev-guide-sample-application-java-spring-boot.md
@@ -52,16 +52,12 @@ To install **Maven** from the command line.
 
 - macOS:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     brew install maven
     ```
 
 - Debian-based Linux distributions (such as Ubuntu):
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     apt-get install maven
     ```
@@ -70,16 +66,12 @@ To install **Maven** from the command line.
 
     - dnf:
 
-        {{< copyable "shell-regular" >}}
-
         ```shell
         dnf install maven
         ```
 
     - yum:
 
-        {{< copyable "shell-regular" >}}
-
         ```shell
         yum install maven
         ```
@@ -156,16 +148,12 @@ If you prefer to build manually, follow these steps:
 
 1. Clear cache and package:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     mvn clean package
     ```
 
 2. Run applications with JAR files:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     java -jar target/spring-jpa-hibernate-0.0.1.jar
     ```
diff --git a/test/sync_pr_docs_cn/data/markdown-pages/zh/tidb/master/develop/dev-guide-insert-data.md b/test/sync_pr_docs_cn/data/markdown-pages/zh/tidb/master/develop/dev-guide-insert-data.md
index aef7b5a..26e2df0 100644
--- a/test/sync_pr_docs_cn/data/markdown-pages/zh/tidb/master/develop/dev-guide-insert-data.md
+++ b/test/sync_pr_docs_cn/data/markdown-pages/zh/tidb/master/develop/dev-guide-insert-data.md
@@ -23,16 +23,12 @@ aliases: ['/zh/tidb/dev/insert-data']
 
 - 一个**多行插入语句**：
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (1, 1000, 1), (2, 230, 2), (3, 300, 5);
     ```
 
 - 多个**单行插入语句**：
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (1, 1000, 1);
     INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (2, 230, 2);
@@ -273,16 +269,12 @@ ERROR 8216 (HY000): Invalid auto random: Explicit insertion on auto_random colum
 
 - (推荐) 插入语句中去除此列，使用 TiDB 帮你初始化的 `AUTO_RANDOM` 值。这样符合 `AUTO_RANDOM` 的语义。
 
-    {{< copyable "sql" >}}
-
     ```sql
     INSERT INTO `bookshop`.`users` (`balance`, `nickname`) VALUES (0.00, 'nicky');
     ```
 
 - 如果你确认一定需要指定此列，那么可以使用 [SET 语句](/sql-statements/sql-statement-set-variable.md)通过更改用户变量的方式，允许在插入时，指定 `AUTO_RANDOM` 的列。
 
-    {{< copyable "sql" >}}
-
     ```sql
     SET @@allow_auto_random_explicit_insert = true;
     INSERT INTO `bookshop`.`users` (`id`, `balance`, `nickname`) VALUES (1, 0.00, 'nicky');
diff --git a/test/sync_pr_docs_cn/data/markdown-pages/zh/tidb/master/develop/dev-guide-sample-application-java-spring-boot.md b/test/sync_pr_docs_cn/data/markdown-pages/zh/tidb/master/develop/dev-guide-sample-application-java-spring-boot.md
index f823f4e..6a06a87 100644
--- a/test/sync_pr_docs_cn/data/markdown-pages/zh/tidb/master/develop/dev-guide-sample-application-java-spring-boot.md
+++ b/test/sync_pr_docs_cn/data/markdown-pages/zh/tidb/master/develop/dev-guide-sample-application-java-spring-boot.md
@@ -42,16 +42,12 @@ aliases: ['/zh/tidb/dev/dev-guide-sample-application-spring-boot', '/zh/tidb/dev
 
 - macOS 安装：
 
-    {{< copyable "shell-regular" >}}
-
     ```
     brew install maven
     ```
 
 - 基于 Debian 的 Linux 发行版上安装（如 Ubuntu 等）：
 
-    {{< copyable "shell-regular" >}}
-
     ```
     apt-get install maven
     ```
@@ -60,16 +56,12 @@ aliases: ['/zh/tidb/dev/dev-guide-sample-application-spring-boot', '/zh/tidb/dev
 
 - dnf 包管理器
 
-    {{< copyable "shell-regular" >}}
-
     ```
     dnf install maven
     ```
 
 - yum 包管理器
 
-    {{< copyable "shell-regular" >}}
-
     ```
     yum install maven
     ```
diff --git a/test/sync_pr_operator/data/markdown-pages/en/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md b/test/sync_pr_operator/data/markdown-pages/en/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
index 2e66079..003596e 100644
--- a/test/sync_pr_operator/data/markdown-pages/en/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
+++ b/test/sync_pr_operator/data/markdown-pages/en/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
@@ -17,8 +17,6 @@ The AWS client can read `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` from the
 
 Create the `s3-secret` secret by running the following command. Use the AWS account's AccessKey and SecretKey. The secret stores the credential used for accessing S3-compatible storage.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1
 ```
@@ -70,8 +68,6 @@ If you associate the user's [IAM](https://aws.amazon.com/cn/iam/) role with the
 
     When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on S3-compatible storage as the BR Pod does. Therefore, you need to add annotations to the TiKV Pod to associate it with the IAM role.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"annotations":{"iam.amazonaws.com/role":"arn:aws:iam::123456789012:role/user"}}}}'
     ```
@@ -126,8 +122,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 3. Associate the IAM role with the `ServiceAccount` resources.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl annotate sa tidb-backup-manager eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test1
     ```
@@ -142,8 +136,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 4. Associate the `ServiceAccount` with the TiKV Pod:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"serviceAccount": "tidb-backup-manager"}}}'
     ```
@@ -160,8 +152,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 Create the `gcs-secret` secret which stores the credential used to access GCS. The `google-credentials.json` file stores the service account key that you have downloaded from the Google Cloud console. Refer to [Google Cloud documentation](https://cloud.google.com/docs/authentication/getting-started) for details.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1
 ```
@@ -176,8 +166,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT` and `AZURE_STORAGE_KEY` from t
 
 Run the following command to create the `azblob-secret` secret and use your Azure account access key to grant permissions. The secret stores the credential used for accessing Azure Blob Storage.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic azblob-secret --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_STORAGE_KEY=yyy --namespace=test1
 ```
@@ -188,8 +176,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT`, `AZURE_CLIENT_ID`, `AZURE_TEN
 
 1. Create the `azblob-secret-ad` secret by running the following command. Use the Active Directory (AD) of your Azure account. The secret stores the credential used for accessing Azure Blob Storage.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl create secret generic azblob-secret-ad --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_CLIENT_ID=yyy --from-literal=AZURE_TENANT_ID=zzz --from-literal=AZURE_CLIENT_SECRET=aaa --namespace=test1
     ```
@@ -198,8 +184,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT`, `AZURE_CLIENT_ID`, `AZURE_TEN
 
     When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on Azure Blob Storage as the BR Pod does. Therefore, you need to associate the TiKV Pod with the secret.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"envFrom":[{"secretRef":{"name":"azblob-secret-ad"}}]}}}'
     ```
diff --git a/test/sync_pr_operator/data/markdown-pages/zh/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md b/test/sync_pr_operator/data/markdown-pages/zh/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
index deab93b..6aba9d3 100644
--- a/test/sync_pr_operator/data/markdown-pages/zh/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
+++ b/test/sync_pr_operator/data/markdown-pages/zh/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
@@ -17,8 +17,6 @@ AWS 的客户端支持读取进程环境变量中的 `AWS_ACCESS_KEY_ID` 以及
 
 创建 `s3-secret` secret，在以下命令中使用 AWS 账号的 AccessKey 和 SecretKey 进行授权。该 secret 存放用于访问 S3 兼容存储的凭证。
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1
 ```
@@ -66,8 +64,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
     在使用 BR 备份的过程中，TiKV Pod 和 BR Pod 一样需要对 S3 存储进行读写操作，所以这里需要给 TiKV Pod 打上 annotation 来绑定 IAM 角色。
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"annotations":{"iam.amazonaws.com/role":"arn:aws:iam::123456789012:role/user"}}}}'
     ```
@@ -94,8 +90,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
     如果是进行基于 AWS EBS 快照的备份和恢复，除完整的 S3 权限 `AmazonS3FullAccess` 外，还需要以下权限：
 
-    {{< copyable "shell-regular" >}}
-
     ```json
             {
             "Effect": "Allow",
@@ -124,8 +118,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
 3. 绑定 IAM 到 ServiceAccount 资源上：
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl annotate sa tidb-backup-manager eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test1
     ```
@@ -140,8 +132,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
 4. 将 ServiceAccount 绑定到 TiKV Pod：
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"serviceAccount": "tidb-backup-manager"}}}'
     ```
@@ -158,8 +148,6 @@ kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-lit
 
 创建 `gcs-secret` secret。该 secret 存放用于访问 GCS 的凭证。`google-credentials.json` 文件存放用户从 Google Cloud console 上下载的 service account key。具体操作参考 [Google Cloud 官方文档](https://cloud.google.com/docs/authentication/getting-started)。
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1
 ```
@@ -174,8 +162,6 @@ Azure 的客户端支持读取进程环境变量中的 `AZURE_STORAGE_ACCOUNT` 
 
 创建 `azblob-secret` secret，在以下命令中使用 Azure 账号的访问密钥进行授权。该 secret 存放用于访问 Azure Blob Storage 的凭证。
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic azblob-secret --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_STORAGE_KEY=yyy --namespace=test1
 ```
@@ -186,8 +172,6 @@ Azure 的客户端支持读取进程环境变量中的 `AZURE_STORAGE_ACCOUNT`
 
 1. 创建 `azblob-secret-ad` secret，在以下命令中使用 Azure 账号的 AD 进行授权。该 secret 存放用于访问 Azure Blob Storage 的凭证。
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl create secret generic azblob-secret-ad --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_CLIENT_ID=yyy --from-    literal=AZURE_TENANT_ID=zzz --from-literal=AZURE_CLIENT_SECRET=aaa --namespace=test1
     ```
@@ -196,8 +180,6 @@ Azure 的客户端支持读取进程环境变量中的 `AZURE_STORAGE_ACCOUNT`
 
     在使用 BR 备份的过程中，TiKV Pod 和 BR Pod 一样需要对 Azure Blob Storage 进行读写操作，所以这里需要给 TiKV Pod 绑定 secret。
 
-     {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"envFrom":[{"secretRef":{"name":"azblob-secret-ad"}}]}}}'
     ```