This is an automated email from the ASF dual-hosted git repository.
wangdan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-pegasus-website.git
The following commit(s) were added to refs/heads/master by this push:
new 7350d38a Update table migration doc (#111)
7350d38a is described below
commit 7350d38a5b91918d8742b718a03df193724a9cdd
Author: Samunroyu <[email protected]>
AuthorDate: Mon May 26 15:30:41 2025 +0800
Update table migration doc (#111)
Update table-migration zh and en docs (#1740)
issue (https://github.com/apache/incubator-pegasus/issues/1740)
---
_docs/en/administration/table-migration.md | 200 +++++++++++++++++++++++-
_docs/zh/administration/table-migration.md | 235 +++++++++++++++--------------
2 files changed, 320 insertions(+), 115 deletions(-)
diff --git a/_docs/en/administration/table-migration.md
b/_docs/en/administration/table-migration.md
index c7b641d0..e0806eb5 100644
--- a/_docs/en/administration/table-migration.md
+++ b/_docs/en/administration/table-migration.md
@@ -2,4 +2,202 @@
permalink: administration/table-migration
---
-TRANSLATING
+Table migration refers to moving all data of a table from one Pegasus cluster
to another Pegasus cluster.
+
+Currently, four table migration methods are provided:
+
+1. The Shell tool command migration;
+2. Cold backup and restore;
+3. Dual-write with bulkload;
+4. Online (hot) migration;
+
+Below, we explain the principles and step-by-step operations of each migration
method:
+
+# Shell Tool Command Migration
+
+## Principle
+
+The Shell tool’ s [copy_data command](/overview/shell#copy_data) works by
reading each record from the source table via the client and writing it one by
one into the target table. Specifically, it uses the `scan` interface to fetch
entries from the table in the source cluster, then uses the `set` interface to
insert or overwrite entries in the target cluster’ s table.
+
+## Step‑by‑Step Operation
+
+The `copy_data` command syntax is:
+
+```
+copy_data <-c|--target_cluster_name str> <-a|--target_app_name
str>
+ [-p|--partition num] [-b|--max_batch_count num]
[-t|--timeout_ms num]
+ [-h|--hash_key_filter_type anywhere|prefix|postfix]
+ [-x|--hash_key_filter_pattern str]
+ [-s|--sort_key_filter_type
anywhere|prefix|postfix|exact]
+ [-y|--sort_key_filter_pattern str]
+ [-v|--value_filter_type anywhere|prefix|postfix|exact]
+ [-z|--value_filter_pattern str]
[-m|--max_multi_set_concurrency]
+ [-o|--scan_option_batch_size] [-e|--no_ttl]
[-n|--no_overwrite]
+ [-i|--no_value] [-g|--geo_data] [-u|--use_multi_set]
+```
+
+Assume the source cluster is `ClusterA`, the target cluster is `ClusterB`, and
the table to migrate is `TableA`. The migration steps are:
+
+1. **Create the table on the target cluster.**
+ The `copy_data` command does not auto-create tables on the target cluster.
You must manually create a table (for example, named `TableB`). The new table’
s name and partition count may differ from the original.
+
+2. **Add the target cluster’s configuration to the Shell config file.**
+ Since you specify the target cluster with `-c`, you need to list
`ClusterB`’ s MetaServer addresses in `src/shell/config.ini`. In the Shell
working directory, append:
+
+ ```ini
+ [pegasus.clusters]
+ ClusterB = {MetaServer addresses of ClusterB}
+ ```
+
+3. **Run the `copy_data` command in the Shell:**
+
+ ```shell
+ >>> use TableA
+ >>> copy_data -c ClusterB -a TableB -t 10000
+ ```
+
+4. **Monitor the copy process.**
+ If everything is set up correctly, copying will begin and progress will
print every second. Typical throughput exceeds 100,000 records per second. If
the process fails (e.g., due to write throttling or write stalls), shuold
resolve the issue and retry.
+
+# Cold Backup Migration
+
+## Principle
+
+Cold backup migration uses Pegasus’ s [cold backup
feature](/administration/cold-backup) to back up data to HDFS (or other
storage) and then restore or bulkload it into the new table.
+
+**Advantages of cold backup migration:**
+
+- **Higher speed:** Cold backup copies files directly, which is much faster
than row-by-row copying.
+- **Greater fault tolerance:** The cold backup process includes retry logic to
handle network instability, whereas `copy_data` must restart on failure.
+- **Multiple targets friendly:** You can back up once and restore multiple
times to different clusters.
+
+## Step‑by‑Step Operation
+
+**Cold backup consists of two main phases:**
+
+1. **Create checkpoints**
+ Checkpoint creation on all primaries and replicas, preparing data for
upload. Larger partitions incur higher disk I/O and may cause brief read/write
spikes.
+
+2. **Upload checkpoints**
+ Uploading checkpoints to HDFS, consuming network bandwidth. Without rate
limiting,this may saturate the network.
+
+**Recommended practices:**
+
+- **Rate‑limit network I/O before backup via Shell:**
+
+ ```shell
+ # For versions ≤ 2.3.x
+ remote_command -t replica-server nfs.max_send_rate_megabytes 50
+ # For versions ≥ 2.4.x
+ remote_command -t replica-server nfs.max_send_rate_megabytes_per_disk 50
+ ```
+
+- **Initiate the backup via `admin-cli`, specifying table ID, HDFS region, and
path:**
+
+ ```shell
+ backup 3 hdfs_xyz /user/pegasus/backup
+ ```
+
+ The `hdfs_xyz` region is defined in `config.ini`:
+
+ ```ini
+ [block_service.hdfs_xyz]
+ type = hdfs_service
+ args = hdfs://xxxprc-hadoop/
+ ```
+
+- **Monitor progress.**
+ Once disk I/O drops, the upload phase has begun. You may incrementally
increase the rate limit (e.g., to 100 MB/s) to speed up:
+
+ ```shell
+ # version ≤ 2.3.x
+ remote_command -t replica-server nfs.max_send_rate_megabytes 100
+ # version ≥ 2.4.x
+ remote_command -t replica-server nfs.max_send_rate_megabytes_per_disk 100
+ ```
+
+- **Handle failures.**
+ If a ReplicaServer restarts, the backup fails and must restart. Watch the
`cold.backup.max.upload.file.size` metric; when it resets to zero, the failed
backup has ended. Delete the HDFS backup directory and retry.
+
+**Data restoration methods:**
+
+1. **Using `restore`:**
+
+ ```shell
+ restore -c ClusterA -a single -i 4 -t 1742888751127 -b hdfs_x -r
/user/pegasus/backup
+ ```
+
+ - `restore` auto‑creates the table and does not support changing partition
count.
+ - The source table (`TableA`) must exist; otherwise, use Bulkload.
+
+2. **Using Bulkload:**
+
+ - Convert cold backup files to Bulkload format via Pegasus-spark’ s offline
split.
+ - In Shell, run:
+
+ ```shell
+ >>> use TableB
+ >>> set_app_envs rocksdb.usage_scenario bulk_load
+ >>> start_bulk_load -a TableB -c ClusterB -p hdfs_xyz -r
/user/pegasus/split
+ ```
+
+# Dual‑Write with Bulkload
+
+Both `copy_data` and cold backup migrate only existing data; incremental
writes require a maintenance window. From version `v2.3.x`, Pegasus supports
**online migration** with dual‑write plus Bulkload.
+
+## Principle
+
+- **Dual‑write:** from the application to both the source and target tables,
ensuring real‑time sync of new writes.
+- **Bulkload:** existing data via cold backup, offline split, and
`IngestBehind`, ensuring correct ordering between old and new data.
+
+RocksDB’ s `IngestBehind` assigns a global sequence number of 0 to ingested
SST files, placing them below existing data so that incremental writes (with
higher sequence numbers) remain in order.
+
+## Step‑by‑Step Operation
+
+- **Create the target table with `rocksdb.allow_ingest_behind=true`:**
+
+ ```sql
+ create TableB -p 64 -e rocksdb.allow_ingest_behind=true
+ ```
+
+- **Implement dual‑write in your application, with retry logic on failures for
both tables.**
+- **Prepare Bulkload data via cold backup and offline split.**
+- **Start Bulkload with `--ingest_behind`:**
+
+ ```shell
+ >>> use TableB
+ >>> set_app_envs rocksdb.usage_scenario bulk_load
+ >>> start_bulk_load -a TableB -c ClusterB -p hdfs_xyz -r
/user/pegasus/split --ingest_behind
+ ```
+
+- **Rate‑limit Bulkload network I/O as needed.**
+- **Partition counts may differ between source and target tables.**
+
+# Online (Hot) Migration
+
+From version `v2.4.x`, Pegasus supports hot backup. See [Cross‑datacenter
Replication](/administration/duplication) for details. Hot backup enables
zero‑downtime migration with minimal steps.
+
+## Step‑by‑Step Operation
+
+- **Replace ip straigt**
+ Route all clients through `MetaProxy`— no direct MetaServer IPs allowed.
+- **Start backup**
+ Establish hot backup from source to target cluster (setup omitted).
+- **Switch ZooKeeper**
+ Switch `MetaProxy` in ZooKeeper to point to the target cluster’ s
MetaServer addresses.
+- **Refresh topology**
+ Block reads/writes on the source table to force clients to refresh topology.
+
+ ```shell
+ >>> use TableB
+ >>> set_app_envs replica.deny_client_request reconfig*all
+ ```
+
+- **Verify migration**
+ Verify migration success by observing that:
+ - QPS on the source table drops to zero;
+ - QPS on the target table rises to match the original;
+ - `dup.disabled_non_idempotent_write_count` remains at 0 on both clusters;
+ - `recent.read.fail.count` and `recent.write.fail.count` remain at 0 on
both clusters.
+
+**Note:** C++ and Python clients currently do not support connecting via
MetaProxy.
diff --git a/_docs/zh/administration/table-migration.md
b/_docs/zh/administration/table-migration.md
index fbbb13ea..6c8dd2c9 100644
--- a/_docs/zh/administration/table-migration.md
+++ b/_docs/zh/administration/table-migration.md
@@ -2,52 +2,60 @@
permalink: administration/table-migration
---
-Table迁移是指将某个Pegasus集群的一张表所有数据迁移到另一个Pegasus集群中。
+Table 迁移是指将某个 Pegasus 集群的一张表所有数据迁移到另一个 Pegasus 集群中。
-目前提供了四种Table迁移方法：
+目前提供了四种 Table 迁移方法：
-1. Shell工具copy_data命令；
-2. 冷备份恢复；
-3. 业务双写配合Bulkload；
-4. 热备迁移；
+1. Shell 工具命令迁移 ;
+2. 冷备份恢复 ;
+3. 业务双写配合 Bulkload;
+4. 热备迁移 ;
下面开始讲述这些迁移方法的原理、具体操作方式：
-# Shell工具copy_data命令迁移
+# Shell 工具命令迁移
## 原理
-Shell工具的[copy_data命令](/overview/shell#copy_data)原理是通过客户端将原表数据逐条读出并逐条写入新表。具体就是通过scan接口从原集群的表中逐条读入数据，然后通过set接口将数据逐条写入到目标集群的表中。如果set的数据在目标集群的表中已经存在，会直接覆盖。
+Shell 工具的 [copy_data 命令 ](/overview/shell#copy_data)
原理是通过客户端将原表数据逐条读出并逐条写入新表。具体就是通过 scan 接口从原集群的表中逐条读入数据，然后通过 set
接口将数据逐条写入到目标集群的表中。如果 set 的数据在目标集群的表中已经存在，会直接覆盖。
## 具体操作方式
-copy_data命令：
+copy_data 命令：
+
```
- copy_data <-c|--target_cluster_name str>
<-a|--target_app_name str>
- [-p|--partition num] [-b|--max_batch_count
num] [-t|--timeout_ms num]
- [-h|--hash_key_filter_type
anywhere|prefix|postfix]
- [-x|--hash_key_filter_pattern str]
- [-s|--sort_key_filter_type
anywhere|prefix|postfix|exact]
- [-y|--sort_key_filter_pattern str]
- [-v|--value_filter_type
anywhere|prefix|postfix|exact]
- [-z|--value_filter_pattern str]
[-m|--max_multi_set_concurrency]
- [-o|--scan_option_batch_size] [-e|--no_ttl]
[-n|--no_overwrite]
- [-i|--no_value] [-g|--geo_data]
[-u|--use_multi_set]
+copy_data <-c|--target_cluster_name str> <-a|--target_app_name
str>
+ [-p|--partition num] [-b|--max_batch_count num]
[-t|--timeout_ms num]
+ [-h|--hash_key_filter_type anywhere|prefix|postfix]
+ [-x|--hash_key_filter_pattern str]
+ [-s|--sort_key_filter_type anywhere|prefix|postfix|exact]
+ [-y|--sort_key_filter_pattern str]
+ [-v|--value_filter_type anywhere|prefix|postfix|exact]
+ [-z|--value_filter_pattern str]
[-m|--max_multi_set_concurrency]
+ [-o|--scan_option_batch_size] [-e|--no_ttl]
[-n|--no_overwrite]
+ [-i|--no_value] [-g|--geo_data] [-u|--use_multi_set]
```
-假设原集群为ClusterA，目标集群为ClusterB，需要迁移的表为TableA。迁移步骤如下：
-* 在目标集群上建表。由于copy_data命令并不会自动在目标集群上创建表，所以需要自己先建表。相对原表，新表的表名可以不同，partition
count也可以不同。假设在目标集群上新建的表名为TableB。
-*
在Shell工具的配置文件中添加目标集群的配置。因为copy_data命令需要通过```-c```参数指定目标集群，所以需要配置目标集群的MetaServer地址列表。在执行Shell所在文件夹，修改配置文件[src/shell/config.ini](https://github.com/apache/incubator-pegasus/blob/master/src/shell/config.ini)，在文件最后添加如下几行（将ClusterB替换为你自己的集群名）：
-```
-[pegasus.clusters]
- ClusterB = {ClusterB的MetaServer地址}
-```
-* 在Shell中执行命令：
-```
->>> use TableA
->>> copy_data -c ClusterB -a TableB -t 10000
-```
-*
如果以上步骤都没有问题，copy操作应当就开始执行了，每隔1秒会打印进度。通常来说，copy速度应当在10万/秒以上。copy过程中如果出现问题终止了（比如遭遇写限流，write
stall等），需排查问题后再重新执行命令。
+假设原集群为 ClusterA，目标集群为 ClusterB，需要迁移的表为 TableA。迁移步骤如下：
+
+1. **在目标集群上建表.**
+ 由于 copy_data 命令并不会自动在目标集群上创建表，所以需要自己先建表。相对原表，新表的表名可以不同， partition count
也可以不同。假设在目标集群上新建的表名为 TableB。
+
+2. **在 Shell 工具的配置文件中添加目标集群的配置.**
+ 因为 copy_data 命令需要通过 ```-c``` 参数指定目标集群，所以需要配置目标集群的 MetaServer 地址列表。在执行 Shell
所在文件夹，修改配置文件
[src/shell/config.ini](https://github.com/apache/incubator-pegasus/blob/master/src/shell/config.ini)，在文件最后添加如下几行（将
ClusterB 替换为你自己的集群名）：
+ ```
+ [pegasus.clusters]
+ ClusterB = {ClusterB 的 MetaServer 地址 }
+ ```
+
+3. **在 Shell 中执行命令.**
+ ```
+ >>> use TableA
+ >>> copy_data -c ClusterB -a TableB -t 10000
+ ```
+
+4. **监控迁移进度.**
+ 如果以上步骤都没有问题， copy 操作应当就开始执行了，每隔 1 秒会打印进度。通常来说， copy 速度应当在 10 万 / 秒以上。 copy
过程中如果出现问题终止了（比如遭遇写限流， write stall 等），需排查问题后再重新执行命令。
@@ -55,143 +63,142 @@ copy_data命令：
## 原理
-所谓冷备份迁移，就是利用Pegasus的[冷备份功能](/administration/cold-backup)，先将数据备份到HDFS或者其他介质上，然后通过restore或bulkload恢复到新的表中。
+所谓冷备份迁移，就是利用 Pegasus 的 [ 冷备份功能 ](/administration/cold-backup)，先将数据备份到 HDFS
或者其他介质上，然后通过 restore 或 bulkload 恢复到新的表中。
-冷备份迁移的好处：
-* 速度更快：因为冷备份是拷贝文件，相对copy_data的逐条拷贝，速度要快很多。
-* 错误容忍度高：冷备份功能有很多容错逻辑，避免因为网络抖动等问题带来的影响。如果用copy_data，中途出错就需要从头再来。
-* 多次迁移更友好：如果要从一个表拷贝到多个地方，只需要备份一次，然后执行多次恢复。
+**冷备份迁移的好处**
+- **速度更快:** 因为冷备份是拷贝文件，相对 copy_data 的逐条拷贝，速度要快很多。
+- **错误容忍度高:** 冷备份功能有很多容错逻辑，避免因为网络抖动等问题带来的影响。如果用 copy_data，中途出错就需要从头再来。
+- **多次迁移更友好:** 如果要从一个表拷贝到多个地方，只需要备份一次，然后执行多次恢复。
## 具体操作方式
**冷备份大致分为两个阶段：**
-1. 表的所有主副本通过创建checkpoints为上传HDFS做准备。此过程期间冷备表分片越大，占用的磁盘IO越大，会产生短暂的读写毛刺。
-2. 创建checkpoints后调用HDFS接口进行上传。此过程期间将占用较多网络资源，若不限速，容易造成网络带宽打满。
+1. 表的所有主副本通过创建 checkpoints 为上传 HDFS 做准备。此过程期间冷备表分片越大，占用的磁盘 IO 越大，会产生短暂的读写毛刺。
+2. 创建 checkpoints 后调用 HDFS 接口进行上传。此过程期间将占用较多网络资源，若不限速，容易造成网络带宽打满。
冷备份最佳实践方式如下：
-- 冷备之前通过Pegasus Shell工具设置限速规避网络带宽资源的占用。
+- 冷备之前通过 Pegasus Shell 工具设置限速规避网络带宽资源的占用。
-```shell
-#2.3.x版本及以前设置方式
-remote_command -t replica-server nfs.max_send_rate_megabytes 50
-#2.4.x版本及以后设置方式
-remote_command -t replica-server nfs.max_send_rate_megabytes_per_disk 50
-```
+ ```shell
+ #2.3.x 版本及以前设置方式
+ remote_command -t replica-server nfs.max_send_rate_megabytes 50
+ #2.4.x 版本及以后设置方式
+ remote_command -t replica-server nfs.max_send_rate_megabytes_per_disk 50
+ ```
-- 通过admin-cli发起冷备并等待，参数依次为表id，HDFS所在Region，HDFS存储路径。
+- 通过 admin-cli 发起冷备并等待，参数依次为表 id， HDFS 所在 Region， HDFS 存储路径。
-```
-backup 3 hdfs_zjy /user/pegasus/backup
-```
+ ```
+ backup 3 hdfs_xyz /user/pegasus/backup
+ ```
-其中HDFS所在Region字段会匹配config.ini文件中的以下内容来连接HDFS：
+ 其中 HDFS 所在 Region 字段会匹配 config.ini 文件中的以下内容来连接 HDFS：
-```
-[block_service.hdfs_zjy]
-type = hdfs_service
-args = hdfs://zjyprc-hadoop /
-```
+ ```
+ [block_service.hdfs_xyz]
+ type = hdfs_service
+ args = hdfs://xyzprc-hadoop /
+ ```
-- 观察监控磁盘IO逐渐降低，代表冷备份进入第二阶段。此时可以不断观察监控中网络带宽占用情况，适当放开限速来加速冷备，经验值是每次递增50。
+- 观察监控磁盘 IO 逐渐降低，代表冷备份进入第二阶段。此时可以不断观察监控中网络带宽占用情况，适当放开限速来加速冷备，经验值是每次递增 50 。
-```shell
-#2.3.x版本及以前设置方式
-remote_command -t replica-server nfs.max_send_rate_megabytes 100
-#2.4.x版本及以后设置方式
-remote_command -t replica-server nfs.max_send_rate_megabytes_per_disk 100
-```
+ ```shell
+ #2.3.x 版本及以前设置方式
+ remote_command -t replica-server nfs.max_send_rate_megabytes 100
+ #2.4.x 版本及以后设置方式
+ remote_command -t replica-server nfs.max_send_rate_megabytes_per_disk 100
+ ```
--
一旦发生ReplicaServer节点重启将造成冷备份失败，并且只能等待，目前不支持取消冷备。此时需要观察监控`cold.backup.max.upload.file.size`，此指标归零后表示失败的冷备结束。后续需要删除HDFS上的冷备目录，重新发起冷备操作。
+- 一旦发生 ReplicaServer 节点重启将造成冷备份失败，并且只能等待，目前不支持取消冷备。此时需要观察监控
`cold.backup.max.upload.file.size`，此指标归零后表示失败的冷备结束。后续需要删除 HDFS 上的冷备目录，重新发起冷备操作。
**冷备份数据恢复到新表有两种方式：**
-1. [冷备份功能](/administration/cold-backup)中介绍的restore命令来将数据恢复到新表。
-
-restore执行方式如下：
+1. [ 冷备份功能 ](/administration/cold-backup) 中介绍的 restore 命令来将数据恢复到新表。
-```
-restore -c ClusterA -a single -i 4 -t 1742888751127 -b hdfs_zjy -r
/user/pegasus/backup
-```
+ restore 执行方式如下：
-执行此命令需要注意：
+ ```
+ restore -c ClusterA -a single -i 4 -t 1742888751127 -b hdfs_xyz -r
/user/pegasus/backup
+ ```
-- restore命令会自动创建表，因此restore命令不支持变更表分片数。
-- restore命令强制要求原表TableA存在，否则无法执行此命令。因此原表不存在时，只能通过Bulkload将数据灌入新表。
-- 注意限速避免打满网络带宽，限速方式于冷备份限速方式相同。
+ 执行此命令需要注意：
+ - restore 命令会自动创建表，因此 restore 命令不支持变更表分片数。
+ - restore 命令强制要求原表 TableA 存在，否则无法执行此命令。因此原表不存在时，只能通过 Bulkload 将数据灌入新表。
+ - 注意限速避免打满网络带宽，限速方式于冷备份限速方式相同。
-2. [Bulkload功能](/2020/02/18/bulk-load-design.html)中介绍的Bulkload功能来将数据灌入到新表。
+2. [Bulkload 功能 ](/2020/02/18/bulk-load-design.html) 中介绍的 Bulkload 功能来将数据灌入到新表。
-Bulkload功能可以将冷备份数据灌入新表，最佳实践方式如下：
+ Bulkload 功能可以将冷备份数据灌入新表，最佳实践方式如下：
--
由于Bulkload需要特定格式数据，使用Pegasus-spark提供的离线split操作将冷备数据转换为所需格式。Pegasus-spark的使用方式此处不进行介绍。
-- 使用Pegasus-spark提供的Bulkload操作功能将处理好的数据灌入Pegasus中。
- - Pegasus
shell命令行同样支持发起Bulkload，假设离线split处理后的数据在`/user/pegasus/split`目录中，具体操作方式如下：
+ - 由于 Bulkload 需要特定格式数据，使用 Pegasus-spark 提供的离线 split 操作将冷备数据转换为所需格式。
Pegasus-spark 的使用方式此处不进行介绍。
+ - 使用 Pegasus-spark 提供的 Bulkload 操作功能将处理好的数据灌入 Pegasus 中。
+ - Pegasus shell 命令行同样支持发起 Bulkload，假设离线 split 处理后的数据在
`/user/pegasus/split` 目录中，具体操作方式如下：
-```
->>> use TableB
->>> set_app_envs rocksdb.usage_scenario bulk_load
->>> start_bulk_load -a TableB -c ClusterB -p hdfs_zjy -r /user/pegasus/split
-```
+ ```
+ >>> use TableB
+ >>> set_app_envs rocksdb.usage_scenario bulk_load
+ >>> start_bulk_load -a TableB -c ClusterB -p hdfs_xyz -r /user/pegasus/split
+ ```
-# 业务双写配合Bulkload
+# 业务双写配合 Bulkload
-copy_data命令迁移和冷备份迁移都只能迁移存量数据，若业务有增量数据，则需要业务停写迁移。`v2.3.x`及以后版本支持了**业务不停写迁移方案**，即业务双写配合Bulkload。
+copy_data 命令迁移和冷备份迁移都只能迁移存量数据，若业务有增量数据，则需要业务停写迁移。`v2.3.x` 及以后版本支持了
**业务不停写迁移方案**，即业务双写配合 Bulkload。
## 原理
1. 业务侧双写原表和目标表，保证增量数据的同步。
-2. 服务侧通过冷备、离线Split、Bulkload IngestBehind三步来迁移存量数据，保证存量数据同步。
+2. 服务侧通过冷备、离线 Split、 Bulkload IngestBehind 三步来迁移存量数据，保证存量数据同步。
-Rocksdb支持IngestBehind功能，Rocksdb内部的sst文件由global
seqno号来表示sst文件的新旧，并且是递增的。Rocksdb通过ingest功能会为即将导入的外部sst文件分配global
seqno号，IngestBehind功能则表示为导入的sst文件分配的global
seqno号为0。这样存量数据将被导入Rocksdb引擎底部，进而保证增量数据和存量数据的读取顺序。
+Rocksdb 支持 IngestBehind 功能， Rocksdb 内部的 sst 文件由 global seqno 号来表示 sst
文件的新旧，并且是递增的。 Rocksdb 通过 ingest 功能会为即将导入的外部 sst 文件分配 global seqno 号，
IngestBehind 功能则表示为导入的 sst 文件分配的 global seqno 号为 0 。这样存量数据将被导入 Rocksdb
引擎底部，进而保证增量数据和存量数据的读取顺序。
## 具体操作方式
-- 创建目标表时需指定`rocksdb.allow_ingest_behind=true`，若不指定此参数将无法使用IngestBehind功能！
+- 创建目标表时需指定 `rocksdb.allow_ingest_behind=true`，若不指定此参数将无法使用 IngestBehind 功能！
-```SQL
-create TableB -p 64 -e rocksdb.allow_ingest_behind=true
-```
+ ```
+ create TableB -p 64 -e rocksdb.allow_ingest_behind=true
+ ```
- 与业务侧沟通让其双写原表和目标表。
- 需注意双写两张表均需增加写失败重试机制。
-- 业务侧双写改造完成后，服务侧通过冷备、离线Split将Bulkload所需数据准备好。
-- 通过Pegasus shell发起Bulkload操作，与普通Bulkload操作不同的是需指定`--ingest_behind`参数。
+- 业务侧双写改造完成后，服务侧通过冷备、离线 Split 将 Bulkload 所需数据准备好。
+- 通过 Pegasus shell 发起 Bulkload 操作，与普通 Bulkload 操作不同的是需指定 `--ingest_behind` 参数。
-```
->>> use TableB
->>> set_app_envs rocksdb.usage_scenario bulk_load
->>> start_bulk_load -a TableB -c ClusterB -p hdfs_zjy -r /user/pegasus/split
--ingest_behind
-```
+ ```
+ >>> use TableB
+ >>> set_app_envs rocksdb.usage_scenario bulk_load
+ >>> start_bulk_load -a TableB -c ClusterB -p hdfs_xyz -r
/user/pegasus/split --ingest_behind
+ ```
-- 若Bulkload占用过多网络带宽资源，仍然可以通过上述介绍的`max_send_rate_megabytes`进行限速。
+- 若 Bulkload 占用过多网络带宽资源，仍然可以通过上述介绍的 `max_send_rate_megabytes` 进行限速。
- 此方式不要求原表分片数和目标表分片数一致，故可自由调整目标表分片数。
# 热备迁移
-`v2.4.x`及之后版本支持了热备份，[跨机房同步](/administration/duplication)有详细介绍，这里不再阐述。热备份可以实现业务无感迁移，且操作流程简单。
+`v2.4.x` 及之后版本支持了热备份，[ 跨机房同步 ](/administration/duplication)
有详细介绍，这里不再阐述。热备份可以实现业务无感迁移，且操作流程简单。
## 具体操作方式
-- 热备份迁移要求业务所有Client通过MetaProxy组件来访问Pegasus。不能有直连Metaserver
IP地址的客户端！关于Pegasus直连IP客户端检测，可咨询Pegasus社区。
-- 业务侧全部客户端接入MetaProxy后，开始向目标集群建立热备，此处省略如何建立热备。
+- 热备份迁移要求业务所有 Client 通过 MetaProxy 组件来访问 Pegasus。不能有直连 Metaserver IP 地址的客户端！关于
Pegasus 直连 IP 客户端检测，可咨询 Pegasus 社区。
+- 业务侧全部客户端接入 MetaProxy 后，开始向目标集群建立热备，此处省略如何建立热备。
-- 热备建立后，修改MetaProxy依赖Zookeeper中相应信息，改为目标集群的MetaServer IP地址。
-- 对于原表TableA进行阻读阻写，以此触发业务侧Client重新从MetaProxy拉取拓扑。
+- 热备建立后，修改 MetaProxy 依赖 Zookeeper 中相应信息，改为目标集群的 MetaServer IP 地址。
+- 对于原表 TableA 进行阻读阻写，以此触发业务侧 Client 重新从 MetaProxy 拉取拓扑。
-```
->>> use TableB
->>> set_app_envs replica.deny_client_request reconfig*all
-```
+ ```
+ >>> use TableB
+ >>> set_app_envs replica.deny_client_request reconfig*all
+ ```
- 观察下列监控指标符合预期即为迁移成功：
- - 观察监控原表QPS流量消失；
- - 目标表QPS上涨并恢复至原表相当的流量；
- - 原集群、目标集群热备监控中`dup.disabled_non_idempotent_write_count`为0；
- - 原集群、目标集群监控中读写失败次数`recent.read.fail.count recent.write.fail.count`为0;
-- 需注意：目前C++ Client和Python Client暂不支持连入MetaProxy。
+ - 观察监控原表 QPS 流量消失 ;
+ - 目标表 QPS 上涨并恢复至原表相当的流量 ;
+ - 原集群、目标集群热备监控中 `dup.disabled_non_idempotent_write_count` 为 0;
+ - 原集群、目标集群监控中读写失败次数 `recent.read.fail.count recent.write.fail.count` 为 0;
+- 需注意：目前 C++ Client 和 Python Client 暂不支持连入 MetaProxy。
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
