diff --git a/documentation20/cn/03.architecture/docs.md b/documentation20/cn/03.architecture/docs.md
index 5eafea00c8ca84dff466d835e3016d5818e2a1d5..5041031309f22fd2aa07d29e5f6d92b2f285e557 100644
--- a/documentation20/cn/03.architecture/docs.md
+++ b/documentation20/cn/03.architecture/docs.md
@@ -301,20 +301,6 @@ Master Vnode 遵循下面的写入流程：
 
 与 master vnode 相比，slave vnode 不存在转发环节，也不存在回复确认环节，少了两步。但写内存与 WAL 是完全一样的。
 
-### 异地容灾、IDC迁移
-
-从上述 master 和 slave 流程可以看出，TDengine 采用的是异步复制的方式进行数据同步。这种方式能够大幅提高写入性能，网络延时对写入速度不会有大的影响。通过配置每个物理节点的IDC和机架号，可以保证对于一个虚拟节点组，虚拟节点由来自不同 IDC、不同机架的物理节点组成，从而实现异地容灾。因此 TDengine 原生支持异地容灾，无需再使用其他工具。
-
-另一方面，TDengine 支持动态修改副本数，一旦副本数增加，新加入的虚拟节点将立即进入数据同步流程，同步结束后，新加入的虚拟节点即可提供服务。而在同步过程中，master 以及其他已经同步的虚拟节点都可以对外提供服务。利用这一特性，TDengine 可以实现无服务中断的 IDC 机房迁移。只需要将新 IDC 的物理节点加入现有集群，等数据同步完成后，再将老的 IDC 的物理节点从集群中剔除即可。
-
-但是，这种异步复制的方式，存在极小的时间窗口，丢失写入的数据。具体场景如下：
-
-1. master vnode 完成了它的 5 步操作，已经给 APP 确认写入成功，然后宕机
-2. slave vnode 收到写入请求后，在第 2 步写入日志之前，处理失败
-3. slave vnode 将成为新的 master，从而丢失了一条记录
-
-理论上，只要是异步复制，就无法保证 100% 不丢失。但是这个窗口极小，master 与 slave 要同时发生故障，而且发生在刚给应用确认写入成功之后。
-
 ### 主从选择
 
 Vnode 会保持一个数据版本号(version)，对内存数据进行持久化存储时，对该版本号也进行持久化存储。每个数据更新操作，无论是采集的时序数据还是元数据，这个版本号将增加 1。