[shardingsphere] branch master updated: Update _index.cn.md (#19674)

[zh...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

zhonghongsheng pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git


The following commit(s) were added to refs/heads/master by this push:
     new be13b1050ce Update _index.cn.md (#19674)
be13b1050ce is described below

commit be13b1050ce83fbbccda523bb625a39871e567bd
Author: Mike0601 <40...@users.noreply.github.com>
AuthorDate: Fri Jul 29 14:06:17 2022 +0800

    Update _index.cn.md (#19674)
---
 .../content/reference/scaling/_index.cn.md         | 35 ++++++++++++----------
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/docs/document/content/reference/scaling/_index.cn.md b/docs/document/content/reference/scaling/_index.cn.md
index 57fbb9d2a57..768cb638091 100644
--- a/docs/document/content/reference/scaling/_index.cn.md
+++ b/docs/document/content/reference/scaling/_index.cn.md
@@ -1,19 +1,19 @@
 +++
 pre = "<b>7.5. </b>"
-title = "弹性伸缩"
+title = "数据迁移"
 weight = 5
 +++
 
 ## 原理说明
 
-考虑到 Apache ShardingSphere 的弹性伸缩模块的几个挑战，目前的弹性伸缩解决方案为：临时地使用两个数据库集群，伸缩完成后切换的方式实现。
+目前的数据迁移解决方案为：使用一个全新的数据库集群作为迁移目标库。
 
-![伸缩总揽](https://shardingsphere.apache.org/document/current/img/scaling/principle_v2.png)
+![迁移概述](https://shardingsphere.apache.org/document/current/img/scaling/overview_v2.png)
 
 这种实现方式有以下优点：
 
-1. 伸缩过程中，原始数据没有任何影响；
-2. 伸缩失败无风险；
+1. 迁移过程中，原始数据没有任何影响；
+2. 迁移失败无风险；
 3. 不受分片策略限制。
 
 同时也存在一定的缺点：
@@ -21,24 +21,25 @@ weight = 5
 1. 在一定时间内存在冗余服务器；
 2. 所有数据都需要移动。
 
-弹性伸缩模块会通过解析旧分片规则，提取配置中的数据源、数据节点等信息，之后创建伸缩作业工作流，将一次弹性伸缩拆解为 4 个主要阶段：
+一次数据迁移包括以下几个主要阶段：
 
 1. 准备阶段；
 2. 存量数据迁移阶段；
 3. 增量数据同步阶段；
-4. 规则切换阶段。
+4. 流量切换阶段。
+
+![迁移总览](https://shardingsphere.apache.org/document/current/img/scaling/principle_v2.png)
 
-![伸缩工作流](https://shardingsphere.apache.org/document/current/img/scaling/workflow.cn.png)
 
 ## 执行阶段说明
 
 ### 准备阶段
 
-在准备阶段，弹性伸缩模块会进行数据源连通性及权限的校验，同时进行存量数据的统计、日志位点的记录，最后根据数据量和用户设置的并行度，对任务进行分片。
+在准备阶段，数据迁移模块会进行数据源连通性及权限的校验，同时进行存量数据的统计、日志位点的记录，最后根据数据量和用户设置的并行度，对任务进行分片。
 
 ### 存量数据迁移阶段
 
-执行在准备阶段拆分好的存量数据迁移作业，存量迁移阶段采用 JDBC 查询的方式，直接从数据节点中读取数据，并使用新规则写入到新集群中。
+执行在准备阶段拆分好的存量数据迁移任务，存量迁移阶段采用 JDBC 查询的方式，直接从源端读取数据，基于配置的分片等规则写入到目标端。
 
 ### 增量数据同步阶段
 
@@ -48,11 +49,15 @@ weight = 5
 - MySQL：订阅并解析 binlog；
 - PostgreSQL：采用官方逻辑复制 [test_decoding](https://www.postgresql.org/docs/9.4/test-decoding.html)。
 
-这些捕获的增量数据，同样会由弹性伸缩模块根据新规则写入到新数据节点中。当增量数据基本同步完成时（由于业务系统未停止，增量数据是不断的），则进入规则切换阶段。
+这些捕获的增量数据，同样会由数据迁移模块写入到新数据节点中。当增量数据基本同步完成时（由于业务系统未停止，增量数据是不断的），则进入流量切换阶段。
+
+### 流量切换阶段
+
+在此阶段，可能存在一定时间的业务只读窗口期，通过 ShardingSphere 的停写功能或者设置数据库只读、控制源头写流量等方式，让源端数据节点中的数据短暂静态，确保增量同步完全完成。
 
-### 规则切换阶段
+这个只读窗口期时长取决于用户是否需要对数据进行一致性校验以及数据量。确认完成后，数据迁移完成。
+然后用户可以把读流量或者写流量切换到 Apache ShardingSphere。
 
-在此阶段，可能存在一定时间的业务只读窗口期，通过设置数据库只读或 ShardingSphere 的熔断机制，让旧数据节点中的数据短暂静态，确保增量同步已完全完成。
+## 相关参考
 
-这个窗口期时间短则数秒，长则数分钟，取决于数据量和用户是否需要对数据进行强校验。
-确认完成后，Apache ShardingSphere 可通过配置中心修改配置，将业务导向新规则的集群，弹性伸缩完成。
+[数据迁移的配置](/cn/user-manual/shardingsphere-proxy/scaling/)