You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@doris.apache.org by ji...@apache.org on 2022/04/15 08:33:11 UTC
[incubator-doris] branch master updated: add doc for ops monitor (#9029)
This is an automated email from the ASF dual-hosted git repository.
jiafengzheng pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-doris.git
The following commit(s) were added to refs/heads/master by this push:
new dbb340c330 add doc for ops monitor (#9029)
dbb340c330 is described below
commit dbb340c330ca6c9fe80fba7f9e9de0dae31dd3dd
Author: wudi <67...@qq.com>
AuthorDate: Fri Apr 15 16:33:07 2022 +0800
add doc for ops monitor (#9029)
add doc for ops monitor
---
.../maint-monitor/be-olap-error-code.md | 4 +-
.../en/admin-manual/maint-monitor/disk-capacity.md | 2 -
.../maint-monitor/metadata-operation.md | 6 +-
.../maint-monitor/tablet-repair-and-balance.md | 2 +-
.../maint-monitor/be-olap-error-code.md | 234 ++++++-
.../admin-manual/maint-monitor/disk-capacity.md | 136 +++-
.../admin-manual/maint-monitor/doris-error-code.md | 152 ++++-
.../maint-monitor/metadata-operation.md | 370 +++++++++-
.../admin-manual/maint-monitor/monitor-alert.md | 284 +++++++-
.../maint-monitor/monitor-metrics/be-metrics.md | 56 ++
.../maint-monitor/monitor-metrics/fe-metrics.md | 127 ++++
.../admin-manual/maint-monitor/tablet-meta-tool.md | 121 +++-
.../maint-monitor/tablet-repair-and-balance.md | 750 ++++++++++++++++++++-
.../maint-monitor/tablet-restore-tool.md | 117 +++-
14 files changed, 2344 insertions(+), 17 deletions(-)
diff --git a/new-docs/en/admin-manual/maint-monitor/be-olap-error-code.md b/new-docs/en/admin-manual/maint-monitor/be-olap-error-code.md
index 5b4514cf76..dd4bae44fe 100644
--- a/new-docs/en/admin-manual/maint-monitor/be-olap-error-code.md
+++ b/new-docs/en/admin-manual/maint-monitor/be-olap-error-code.md
@@ -27,10 +27,8 @@ under the License.
# Description of the return value of the OLAP function on the BE side
-
-
| Return value name | Return value | Return value description |
-| ------------------------------------------------ | ------ | ------------------------------------------- ----------------- |
+| ------------------------------------------------ | ------ | ------------------------------------------------------------ |
| OLAP_SUCCESS | 0 | Success |
| OLAP_ERR_OTHER_ERROR | -1 | Other errors |
| OLAP_REQUEST_FAILED | -2 | Request failed |
diff --git a/new-docs/en/admin-manual/maint-monitor/disk-capacity.md b/new-docs/en/admin-manual/maint-monitor/disk-capacity.md
index 71027d9f6e..710386928a 100644
--- a/new-docs/en/admin-manual/maint-monitor/disk-capacity.md
+++ b/new-docs/en/admin-manual/maint-monitor/disk-capacity.md
@@ -32,8 +32,6 @@ If Doris' data disk capacity is not controlled, the process will hang because th
## Glossary
-* FE：Doris Frontend Node. Responsible for metadata management and request access.
-* BE：Doris Backend Node. Responsible for query execution and data storage.
* Data Dir：Data directory, each data directory specified in the `storage_root_path` of the BE configuration file `be.conf`. Usually a data directory corresponds to a disk, so the following **disk** also refers to a data directory.
## Basic Principles
diff --git a/new-docs/en/admin-manual/maint-monitor/metadata-operation.md b/new-docs/en/admin-manual/maint-monitor/metadata-operation.md
index abc5aaca35..fd1a774b5a 100644
--- a/new-docs/en/admin-manual/maint-monitor/metadata-operation.md
+++ b/new-docs/en/admin-manual/maint-monitor/metadata-operation.md
@@ -32,7 +32,7 @@ For the time being, read the [Doris metadata design document](../../internal/met
## Important tips
-* Current metadata design is not backward compatible. That is, if the new version has a new metadata structure change (you can see whether there is a new VERSION in the `FeMetaVersion.java` file in the FE code), it is usually impossible to roll back to the old version after upgrading to the new version. Therefore, before upgrading FE, be sure to test metadata compatibility according to the operations in the [Upgrade Document](../../installing/upgrade_EN.md).
+* Current metadata design is not backward compatible. That is, if the new version has a new metadata structure change (you can see whether there is a new VERSION in the `FeMetaVersion.java` file in the FE code), it is usually impossible to roll back to the old version after upgrading to the new version. Therefore, before upgrading FE, be sure to test metadata compatibility according to the operations in the [Upgrade Document](../upgrade.md).
## Metadata catalog structure
@@ -136,7 +136,7 @@ Single node FE is the most basic deployment mode. A complete Doris cluster requi
### Add FE
-Adding FE processes is described in detail in the [Deployment and Upgrade Documents](../../installing/install-deploy.md#Adding%20FE%20nodes) and will not be repeated. Here are some points for attention, as well as common problems.
+Adding FE processes is described in detail in the [Elastic Expansion Documents](../elastic-expansion.html) and will not be repeated. Here are some points for attention, as well as common problems.
1. Notes
@@ -333,7 +333,7 @@ The third level can display the value information of the specified key.
## Best Practices
-The deployment recommendation of FE is described in the Installation and [Deployment Document](../../installing/install-deploy_EN.md). Here are some supplements.
+The deployment recommendation of FE is described in the Installation and [Deployment Document](../../install/install-deploy.md). Here are some supplements.
* **If you don't know the operation logic of FE metadata very well, or you don't have enough experience in the operation and maintenance of FE metadata, we strongly recommend that only one FOLLOWER-type FE be deployed as MASTER in practice, and the other FEs are OBSERVER, which can reduce many complex operation and maintenance problems.** Don't worry too much about the failure of MASTER single point to write metadata. First, if you configure it properly, FE as a java process is very diff [...]
diff --git a/new-docs/en/admin-manual/maint-monitor/tablet-repair-and-balance.md b/new-docs/en/admin-manual/maint-monitor/tablet-repair-and-balance.md
index e924e626ae..efafc96821 100644
--- a/new-docs/en/admin-manual/maint-monitor/tablet-repair-and-balance.md
+++ b/new-docs/en/admin-manual/maint-monitor/tablet-repair-and-balance.md
@@ -28,7 +28,7 @@ under the License.
Beginning with version 0.9.0, Doris introduced an optimized replica management strategy and supported a richer replica status viewing tool. This document focuses on Doris data replica balancing, repair scheduling strategies, and replica management operations and maintenance methods. Help users to more easily master and manage the replica status in the cluster.
-> Repairing and balancing copies of tables with Collocation attributes can be referred to `docs/documentation/cn/administrator-guide/colocation-join.md'.`
+> Repairing and balancing copies of tables with Collocation attributes can be referred to [HERE](../../advanced/colocation-join.html)
## Noun Interpretation
diff --git a/new-docs/zh-CN/admin-manual/maint-monitor/be-olap-error-code.md b/new-docs/zh-CN/admin-manual/maint-monitor/be-olap-error-code.md
index 5906f64931..8b98d8fe31 100644
--- a/new-docs/zh-CN/admin-manual/maint-monitor/be-olap-error-code.md
+++ b/new-docs/zh-CN/admin-manual/maint-monitor/be-olap-error-code.md
@@ -25,4 +25,236 @@ specific language governing permissions and limitations
under the License.
-->
-# BE端OLAP函数的返回值说明
\ No newline at end of file
+# BE端OLAP函数的返回值说明
+
+| 返回值名称 | 返回值 | 返回值说明 |
+| ------------------------------------------------ | ------ | ------------------------------------------------------------ |
+| OLAP_SUCCESS | 0 | 成功 |
+| OLAP_ERR_OTHER_ERROR | -1 | 其他错误 |
+| OLAP_REQUEST_FAILED | -2 | 请求失败 |
+| 系统错误代码，例如文件系统内存和其他系统调用失败 | | |
+| OLAP_ERR_OS_ERROR | -100 | 操作系统错误 |
+| OLAP_ERR_DIR_NOT_EXIST | -101 | 目录不存在错误 |
+| OLAP_ERR_FILE_NOT_EXIST | -102 | 文件不存在错误 |
+| OLAP_ERR_CREATE_FILE_ERROR | -103 | 创建文件错误 |
+| OLAP_ERR_MALLOC_ERROR | -104 | 内存分配错误 |
+| OLAP_ERR_STL_ERROR | -105 | 标准模板库错误 |
+| OLAP_ERR_IO_ERROR | -106 | IO错误 |
+| OLAP_ERR_MUTEX_ERROR | -107 | 互斥锁错误 |
+| OLAP_ERR_PTHREAD_ERROR | -108 | POSIX thread错误 |
+| OLAP_ERR_NETWORK_ERROR | -109 | 网络异常错误 |
+| OLAP_ERR_UB_FUNC_ERROR | -110 | |
+| OLAP_ERR_COMPRESS_ERROR | -111 | 数据压缩错误 |
+| OLAP_ERR_DECOMPRESS_ERROR | -112 | 数据解压缩错误 |
+| OLAP_ERR_UNKNOWN_COMPRESSION_TYPE | -113 | 未知的数据压缩类型 |
+| OLAP_ERR_MMAP_ERROR | -114 | 内存映射文件错误 |
+| OLAP_ERR_RWLOCK_ERROR | -115 | 读写锁错误 |
+| OLAP_ERR_READ_UNENOUGH | -116 | 读取内存不够异常 |
+| OLAP_ERR_CANNOT_CREATE_DIR | -117 | 不能创建目录异常 |
+| OLAP_ERR_UB_NETWORK_ERROR | -118 | 网络异常 |
+| OLAP_ERR_FILE_FORMAT_ERROR | -119 | 文件格式异常 |
+| OLAP_ERR_EVAL_CONJUNCTS_ERROR | -120 | |
+| OLAP_ERR_COPY_FILE_ERROR | -121 | 拷贝文件错误 |
+| OLAP_ERR_FILE_ALREADY_EXIST | -122 | 文件已经存在错误 |
+| 通用错误代码 | | |
+| OLAP_ERR_NOT_INITED | -200 | 不能初始化异常 |
+| OLAP_ERR_FUNC_NOT_IMPLEMENTED | -201 | 函数不能执行异常 |
+| OLAP_ERR_CALL_SEQUENCE_ERROR | -202 | 调用SEQUENCE异常 |
+| OLAP_ERR_INPUT_PARAMETER_ERROR | -203 | 输入参数错误 |
+| OLAP_ERR_BUFFER_OVERFLOW | -204 | 内存缓冲区溢出错误 |
+| OLAP_ERR_CONFIG_ERROR | -205 | 配置错误 |
+| OLAP_ERR_INIT_FAILED | -206 | 初始化失败 |
+| OLAP_ERR_INVALID_SCHEMA | -207 | 无效的Schema |
+| OLAP_ERR_CHECKSUM_ERROR | -208 | 检验值错误 |
+| OLAP_ERR_SIGNATURE_ERROR | -209 | 签名错误 |
+| OLAP_ERR_CATCH_EXCEPTION | -210 | 捕捉到异常 |
+| OLAP_ERR_PARSE_PROTOBUF_ERROR | -211 | 解析Protobuf出错 |
+| OLAP_ERR_SERIALIZE_PROTOBUF_ERROR | -212 | Protobuf序列化错误 |
+| OLAP_ERR_WRITE_PROTOBUF_ERROR | -213 | Protobuf写错误 |
+| OLAP_ERR_VERSION_NOT_EXIST | -214 | tablet版本不存在错误 |
+| OLAP_ERR_TABLE_NOT_FOUND | -215 | 未找到tablet错误 |
+| OLAP_ERR_TRY_LOCK_FAILED | -216 | 尝试锁失败 |
+| OLAP_ERR_OUT_OF_BOUND | -218 | 内存越界 |
+| OLAP_ERR_UNDERFLOW | -219 | underflow错误 |
+| OLAP_ERR_FILE_DATA_ERROR | -220 | 文件数据错误 |
+| OLAP_ERR_TEST_FILE_ERROR | -221 | 测试文件错误 |
+| OLAP_ERR_INVALID_ROOT_PATH | -222 | 无效的根目录 |
+| OLAP_ERR_NO_AVAILABLE_ROOT_PATH | -223 | 没有有效的根目录 |
+| OLAP_ERR_CHECK_LINES_ERROR | -224 | 检查行数错误 |
+| OLAP_ERR_INVALID_CLUSTER_INFO | -225 | 无效的Cluster信息 |
+| OLAP_ERR_TRANSACTION_NOT_EXIST | -226 | 事务不存在 |
+| OLAP_ERR_DISK_FAILURE | -227 | 磁盘错误 |
+| OLAP_ERR_TRANSACTION_ALREADY_COMMITTED | -228 | 交易已提交 |
+| OLAP_ERR_TRANSACTION_ALREADY_VISIBLE | -229 | 事务可见 |
+| OLAP_ERR_VERSION_ALREADY_MERGED | -230 | 版本已合并 |
+| OLAP_ERR_LZO_DISABLED | -231 | LZO已禁用 |
+| OLAP_ERR_DISK_REACH_CAPACITY_LIMIT | -232 | 磁盘到达容量限制 |
+| OLAP_ERR_TOO_MANY_TRANSACTIONS | -233 | 太多事务积压未完成 |
+| OLAP_ERR_INVALID_SNAPSHOT_VERSION | -234 | 无效的快照版本 |
+| OLAP_ERR_TOO_MANY_VERSION | -235 | tablet的数据版本超过了最大限制（默认500） |
+| OLAP_ERR_NOT_INITIALIZED | -236 | 不能初始化 |
+| OLAP_ERR_ALREADY_CANCELLED | -237 | 已经被取消 |
+| OLAP_ERR_TOO_MANY_SEGMENTS | -238 | 通常出现在同一批导入数据量过大的情况，从而导致某一个 tablet 的 Segment 文件过多 |
+| 命令执行异常代码 | | |
+| OLAP_ERR_CE_CMD_PARAMS_ERROR | -300 | 命令参数错误 |
+| OLAP_ERR_CE_BUFFER_TOO_SMALL | -301 | 缓冲区太多小文件 |
+| OLAP_ERR_CE_CMD_NOT_VALID | -302 | 无效的命令 |
+| OLAP_ERR_CE_LOAD_TABLE_ERROR | -303 | 加载数据表错误 |
+| OLAP_ERR_CE_NOT_FINISHED | -304 | 命令没有执行成功 |
+| OLAP_ERR_CE_TABLET_ID_EXIST | -305 | tablet Id不存在错误 |
+| OLAP_ERR_CE_TRY_CE_LOCK_ERROR | -306 | 尝试获取执行命令锁错误 |
+| Tablet错误异常代码 | | |
+| OLAP_ERR_TABLE_VERSION_DUPLICATE_ERROR | -400 | tablet副本版本错误 |
+| OLAP_ERR_TABLE_VERSION_INDEX_MISMATCH_ERROR | -401 | teblet版本索引不匹配异常 |
+| OLAP_ERR_TABLE_INDEX_VALIDATE_ERROR | -402 | 这里不检查tablet的初始版本，因为如果在一个tablet进行schema-change时重新启动 BE，我们可能会遇到空tablet异常 |
+| OLAP_ERR_TABLE_INDEX_FIND_ERROR | -403 | 无法获得第一个Block块位置 或者找到最后一行Block块失败会引发此异常 |
+| OLAP_ERR_TABLE_CREATE_FROM_HEADER_ERROR | -404 | 无法加载Tablet的时候会触发此异常 |
+| OLAP_ERR_TABLE_CREATE_META_ERROR | -405 | 无法创建Tablet（更改schema），Base tablet不存在 ，会触发此异常 |
+| OLAP_ERR_TABLE_ALREADY_DELETED_ERROR | -406 | tablet已经被删除 |
+| 存储引擎错误代码 | | |
+| OLAP_ERR_ENGINE_INSERT_EXISTS_TABLE | -500 | 添加相同的tablet两次，添加tablet到相同数据目录两次，新tablet为空，旧tablet存在。会触发此异常 |
+| OLAP_ERR_ENGINE_DROP_NOEXISTS_TABLE | -501 | 删除不存在的表 |
+| OLAP_ERR_ENGINE_LOAD_INDEX_TABLE_ERROR | -502 | 加载tablet_meta失败，cumulative rowset无效的segment group meta，会引发此异常 |
+| OLAP_ERR_TABLE_INSERT_DUPLICATION_ERROR | -503 | 表插入重复 |
+| OLAP_ERR_DELETE_VERSION_ERROR | -504 | 删除版本错误 |
+| OLAP_ERR_GC_SCAN_PATH_ERROR | -505 | GC扫描路径错误 |
+| OLAP_ERR_ENGINE_INSERT_OLD_TABLET | -506 | 当 BE 正在重新启动并且较旧的tablet已添加到垃圾收集队列但尚未删除时,在这种情况下,由于 data_dirs 是并行加载的，稍后加载的tablet可能比以前加载的tablet旧，这不应被确认为失败,所以此时返回改代码 |
+| Fetch Handler错误代码 | | |
+| OLAP_ERR_FETCH_OTHER_ERROR | -600 | FetchHandler其他错误 |
+| OLAP_ERR_FETCH_TABLE_NOT_EXIST | -601 | FetchHandler表不存在 |
+| OLAP_ERR_FETCH_VERSION_ERROR | -602 | FetchHandler版本错误 |
+| OLAP_ERR_FETCH_SCHEMA_ERROR | -603 | FetchHandler Schema错误 |
+| OLAP_ERR_FETCH_COMPRESSION_ERROR | -604 | FetchHandler压缩错误 |
+| OLAP_ERR_FETCH_CONTEXT_NOT_EXIST | -605 | FetchHandler上下文不存在 |
+| OLAP_ERR_FETCH_GET_READER_PARAMS_ERR | -606 | FetchHandler GET读参数错误 |
+| OLAP_ERR_FETCH_SAVE_SESSION_ERR | -607 | FetchHandler保存会话错误 |
+| OLAP_ERR_FETCH_MEMORY_EXCEEDED | -608 | FetchHandler内存超出异常 |
+| 读异常错误代码 | | |
+| OLAP_ERR_READER_IS_UNINITIALIZED | -700 | 读不能初始化 |
+| OLAP_ERR_READER_GET_ITERATOR_ERROR | -701 | 获取读迭代器错误 |
+| OLAP_ERR_CAPTURE_ROWSET_READER_ERROR | -702 | 当前Rowset读错误 |
+| OLAP_ERR_READER_READING_ERROR | -703 | 初始化列数据失败，cumulative rowset 的列数据无效 ，会返回该异常代码 |
+| OLAP_ERR_READER_INITIALIZE_ERROR | -704 | 读初始化失败 |
+| BaseCompaction异常代码信息 | | |
+| OLAP_ERR_BE_VERSION_NOT_MATCH | -800 | BE Compaction 版本不匹配错误 |
+| OLAP_ERR_BE_REPLACE_VERSIONS_ERROR | -801 | BE Compaction 替换版本错误 |
+| OLAP_ERR_BE_MERGE_ERROR | -802 | BE Compaction合并错误 |
+| OLAP_ERR_CAPTURE_ROWSET_ERROR | -804 | 找不到Rowset对应的版本 |
+| OLAP_ERR_BE_SAVE_HEADER_ERROR | -805 | BE Compaction保存Header错误 |
+| OLAP_ERR_BE_INIT_OLAP_DATA | -806 | BE Compaction 初始化OLAP数据错误 |
+| OLAP_ERR_BE_TRY_OBTAIN_VERSION_LOCKS | -807 | BE Compaction 尝试获得版本锁错误 |
+| OLAP_ERR_BE_NO_SUITABLE_VERSION | -808 | BE Compaction 没有合适的版本 |
+| OLAP_ERR_BE_TRY_BE_LOCK_ERROR | -809 | 其他base compaction正在运行，尝试获取锁失败 |
+| OLAP_ERR_BE_INVALID_NEED_MERGED_VERSIONS | -810 | 无效的Merge版本 |
+| OLAP_ERR_BE_ERROR_DELETE_ACTION | -811 | BE执行删除操作错误 |
+| OLAP_ERR_BE_SEGMENTS_OVERLAPPING | -812 | cumulative point有重叠的Rowset异常 |
+| OLAP_ERR_BE_CLONE_OCCURRED | -813 | 将压缩任务提交到线程池后可能会发生克隆任务，并且选择用于压缩的行集可能会发生变化。 在这种情况下，不应执行当前的压缩任务。 返回该代码 |
+| PUSH异常代码 | | |
+| OLAP_ERR_PUSH_INIT_ERROR | -900 | 无法初始化读取器，无法创建表描述符，无法初始化内存跟踪器，不支持的文件格式类型，无法打开扫描仪，无法获取元组描述符，为元组分配内存失败，都会返回该代码 |
+| OLAP_ERR_PUSH_DELTA_FILE_EOF | -901 | |
+| OLAP_ERR_PUSH_VERSION_INCORRECT | -902 | PUSH版本不正确 |
+| OLAP_ERR_PUSH_SCHEMA_MISMATCH | -903 | PUSH Schema不匹配 |
+| OLAP_ERR_PUSH_CHECKSUM_ERROR | -904 | PUSH校验值错误 |
+| OLAP_ERR_PUSH_ACQUIRE_DATASOURCE_ERROR | -905 | PUSH 获取数据源错误 |
+| OLAP_ERR_PUSH_CREAT_CUMULATIVE_ERROR | -906 | PUSH 创建CUMULATIVE错误代码 |
+| OLAP_ERR_PUSH_BUILD_DELTA_ERROR | -907 | 推送的增量文件有错误的校验码 |
+| OLAP_ERR_PUSH_VERSION_ALREADY_EXIST | -908 | PUSH的版本已经存在 |
+| OLAP_ERR_PUSH_TABLE_NOT_EXIST | -909 | PUSH的表不存在 |
+| OLAP_ERR_PUSH_INPUT_DATA_ERROR | -910 | PUSH的数据无效，可能是长度，数据类型等问题 |
+| OLAP_ERR_PUSH_TRANSACTION_ALREADY_EXIST | -911 | 将事务提交给引擎时，发现Rowset存在，但Rowset ID 不一样 |
+| OLAP_ERR_PUSH_BATCH_PROCESS_REMOVED | -912 | 删除了推送批处理过程 |
+| OLAP_ERR_PUSH_COMMIT_ROWSET | -913 | PUSH Commit Rowset |
+| OLAP_ERR_PUSH_ROWSET_NOT_FOUND | -914 | PUSH Rowset没有发现 |
+| SegmentGroup异常代码 | | |
+| OLAP_ERR_INDEX_LOAD_ERROR | -1000 | 加载索引错误 |
+| OLAP_ERR_INDEX_EOF | -1001 | |
+| OLAP_ERR_INDEX_CHECKSUM_ERROR | -1002 | 校验码验证错误，加载索引对应的Segment 错误。 |
+| OLAP_ERR_INDEX_DELTA_PRUNING | -1003 | 索引增量修剪 |
+| OLAPData异常代码信息 | | |
+| OLAP_ERR_DATA_ROW_BLOCK_ERROR | -1100 | 数据行Block块错误 |
+| OLAP_ERR_DATA_FILE_TYPE_ERROR | -1101 | 数据文件类型错误 |
+| OLAP_ERR_DATA_EOF | -1102 | |
+| OLAP数据写错误代码 | | |
+| OLAP_ERR_WRITER_INDEX_WRITE_ERROR | -1200 | 索引写错误 |
+| OLAP_ERR_WRITER_DATA_WRITE_ERROR | -1201 | 数据写错误 |
+| OLAP_ERR_WRITER_ROW_BLOCK_ERROR | -1202 | Row Block块写错误 |
+| OLAP_ERR_WRITER_SEGMENT_NOT_FINALIZED | -1203 | 在添加新Segment之前，上一Segment未完成 |
+| RowBlock错误代码 | | |
+| OLAP_ERR_ROWBLOCK_DECOMPRESS_ERROR | -1300 | Rowblock解压缩错误 |
+| OLAP_ERR_ROWBLOCK_FIND_ROW_EXCEPTION | -1301 | 获取Block Entry失败 |
+| OLAP_ERR_ROWBLOCK_READ_INFO_ERROR | -1302 | 读取Rowblock信息错误 |
+| Tablet元数据错误 | | |
+| OLAP_ERR_HEADER_ADD_VERSION | -1400 | tablet元数据增加版本 |
+| OLAP_ERR_HEADER_DELETE_VERSION | -1401 | tablet元数据删除版本 |
+| OLAP_ERR_HEADER_ADD_PENDING_DELTA | -1402 | tablet元数据添加待处理增量 |
+| OLAP_ERR_HEADER_ADD_INCREMENTAL_VERSION | -1403 | tablet元数据添加自增版本 |
+| OLAP_ERR_HEADER_INVALID_FLAG | -1404 | tablet元数据无效的标记 |
+| OLAP_ERR_HEADER_PUT | -1405 | tablet元数据PUT操作 |
+| OLAP_ERR_HEADER_DELETE | -1406 | tablet元数据DELETE操作 |
+| OLAP_ERR_HEADER_GET | -1407 | tablet元数据GET操作 |
+| OLAP_ERR_HEADER_LOAD_INVALID_KEY | -1408 | tablet元数据加载无效Key |
+| OLAP_ERR_HEADER_FLAG_PUT | -1409 | |
+| OLAP_ERR_HEADER_LOAD_JSON_HEADER | -1410 | tablet元数据加载JSON Header |
+| OLAP_ERR_HEADER_INIT_FAILED | -1411 | tablet元数据Header初始化失败 |
+| OLAP_ERR_HEADER_PB_PARSE_FAILED | -1412 | tablet元数据 Protobuf解析失败 |
+| OLAP_ERR_HEADER_HAS_PENDING_DATA | -1413 | tablet元数据有待处理的数据 |
+| TabletSchema异常代码信息 | | |
+| OLAP_ERR_SCHEMA_SCHEMA_INVALID | -1500 | Tablet Schema无效 |
+| OLAP_ERR_SCHEMA_SCHEMA_FIELD_INVALID | -1501 | Tablet Schema 字段无效 |
+| SchemaHandler异常代码信息 | | |
+| OLAP_ERR_ALTER_MULTI_TABLE_ERR | -1600 | ALTER 多表错误 |
+| OLAP_ERR_ALTER_DELTA_DOES_NOT_EXISTS | -1601 | 获取所有数据源失败，Tablet无版本 |
+| OLAP_ERR_ALTER_STATUS_ERR | -1602 | 检查行号失败，内部排序失败，行块排序失败，这些都会返回该代码 |
+| OLAP_ERR_PREVIOUS_SCHEMA_CHANGE_NOT_FINISHED | -1603 | 先前的Schema更改未完成 |
+| OLAP_ERR_SCHEMA_CHANGE_INFO_INVALID | -1604 | Schema变更信息无效 |
+| OLAP_ERR_QUERY_SPLIT_KEY_ERR | -1605 | 查询 Split key 错误 |
+| OLAP_ERR_DATA_QUALITY_ERR | -1606 | 模式更改/物化视图期间数据质量问题导致的错误 |
+| Column File错误代码 | | |
+| OLAP_ERR_COLUMN_DATA_LOAD_BLOCK | -1700 | 加载列数据块错误 |
+| OLAP_ERR_COLUMN_DATA_RECORD_INDEX | -1701 | 加载数据记录索引错误 |
+| OLAP_ERR_COLUMN_DATA_MAKE_FILE_HEADER | -1702 | |
+| OLAP_ERR_COLUMN_DATA_READ_VAR_INT | -1703 | 无法从Stream中读取列数据 |
+| OLAP_ERR_COLUMN_DATA_PATCH_LIST_NUM | -1704 | |
+| OLAP_ERR_COLUMN_STREAM_EOF | -1705 | 如果数据流结束，返回该代码 |
+| OLAP_ERR_COLUMN_READ_STREAM | -1706 | 块大小大于缓冲区大小，压缩剩余大小小于Stream头大小，读取流失败 这些情况下会抛出该异常 |
+| OLAP_ERR_COLUMN_STREAM_NOT_EXIST | -1707 | Stream为空，不存在，未找到数据流 等情况下返回该异常代码 |
+| OLAP_ERR_COLUMN_VALUE_NULL | -1708 | 列值为空异常 |
+| OLAP_ERR_COLUMN_SEEK_ERROR | -1709 | 如果通过schema变更添加列，由于schema变更可能导致列索引存在，返回这个异常代码 |
+| DeleteHandler错误代码 | | |
+| OLAP_ERR_DELETE_INVALID_CONDITION | -1900 | 删除条件无效 |
+| OLAP_ERR_DELETE_UPDATE_HEADER_FAILED | -1901 | 删除更新Header错误 |
+| OLAP_ERR_DELETE_SAVE_HEADER_FAILED | -1902 | 删除保存header错误 |
+| OLAP_ERR_DELETE_INVALID_PARAMETERS | -1903 | 删除参数无效 |
+| OLAP_ERR_DELETE_INVALID_VERSION | -1904 | 删除版本无效 |
+| Cumulative Handler错误代码 | | |
+| OLAP_ERR_CUMULATIVE_NO_SUITABLE_VERSIONS | -2000 | Cumulative没有合适的版本 |
+| OLAP_ERR_CUMULATIVE_REPEAT_INIT | -2001 | Cumulative Repeat 初始化错误 |
+| OLAP_ERR_CUMULATIVE_INVALID_PARAMETERS | -2002 | Cumulative参数无效 |
+| OLAP_ERR_CUMULATIVE_FAILED_ACQUIRE_DATA_SOURCE | -2003 | Cumulative获取数据源失败 |
+| OLAP_ERR_CUMULATIVE_INVALID_NEED_MERGED_VERSIONS | -2004 | Cumulative无有效需要合并版本 |
+| OLAP_ERR_CUMULATIVE_ERROR_DELETE_ACTION | -2005 | Cumulative删除操作错误 |
+| OLAP_ERR_CUMULATIVE_MISS_VERSION | -2006 | rowsets缺少版本 |
+| OLAP_ERR_CUMULATIVE_CLONE_OCCURRED | -2007 | 将压缩任务提交到线程池后可能会发生克隆任务，并且选择用于压缩的行集可能会发生变化。 在这种情况下，不应执行当前的压缩任务。否则会触发改异常 |
+| OLAPMeta异常代码 | | |
+| OLAP_ERR_META_INVALID_ARGUMENT | -3000 | 元数据参数无效 |
+| OLAP_ERR_META_OPEN_DB | -3001 | 打开DB元数据错误 |
+| OLAP_ERR_META_KEY_NOT_FOUND | -3002 | 元数据key没发现 |
+| OLAP_ERR_META_GET | -3003 | GET元数据错误 |
+| OLAP_ERR_META_PUT | -3004 | PUT元数据错误 |
+| OLAP_ERR_META_ITERATOR | -3005 | 元数据迭代器错误 |
+| OLAP_ERR_META_DELETE | -3006 | 删除元数据错误 |
+| OLAP_ERR_META_ALREADY_EXIST | -3007 | 元数据已经存在错误 |
+| Rowset错误代码 | | |
+| OLAP_ERR_ROWSET_WRITER_INIT | -3100 | Rowset写初始化错误 |
+| OLAP_ERR_ROWSET_SAVE_FAILED | -3101 | Rowset保存失败 |
+| OLAP_ERR_ROWSET_GENERATE_ID_FAILED | -3102 | Rowset生成ID失败 |
+| OLAP_ERR_ROWSET_DELETE_FILE_FAILED | -3103 | Rowset删除文件失败 |
+| OLAP_ERR_ROWSET_BUILDER_INIT | -3104 | Rowset初始化构建失败 |
+| OLAP_ERR_ROWSET_TYPE_NOT_FOUND | -3105 | Rowset类型没有发现 |
+| OLAP_ERR_ROWSET_ALREADY_EXIST | -3106 | Rowset已经存在 |
+| OLAP_ERR_ROWSET_CREATE_READER | -3107 | Rowset创建读对象失败 |
+| OLAP_ERR_ROWSET_INVALID | -3108 | Rowset无效 |
+| OLAP_ERR_ROWSET_LOAD_FAILED | -3109 | Rowset加载失败 |
+| OLAP_ERR_ROWSET_READER_INIT | -3110 | Rowset读对象初始化失败 |
+| OLAP_ERR_ROWSET_READ_FAILED | -3111 | Rowset读失败 |
+| OLAP_ERR_ROWSET_INVALID_STATE_TRANSITION | -3112 | Rowset无效的事务状态 |
\ No newline at end of file
diff --git a/new-docs/zh-CN/admin-manual/maint-monitor/disk-capacity.md b/new-docs/zh-CN/admin-manual/maint-monitor/disk-capacity.md
index b4aee02962..d487335ac3 100644
--- a/new-docs/zh-CN/admin-manual/maint-monitor/disk-capacity.md
+++ b/new-docs/zh-CN/admin-manual/maint-monitor/disk-capacity.md
@@ -24,4 +24,138 @@ specific language governing permissions and limitations
under the License.
-->
-# 磁盘空间管理
\ No newline at end of file
+# 磁盘空间管理
+
+本文档主要介绍和磁盘存储空间有关的系统参数和处理策略。
+
+Doris 的数据磁盘空间如果不加以控制，会因磁盘写满而导致进程挂掉。因此我们监测磁盘的使用率和剩余空间，通过设置不同的警戒水位，来控制 Doris 系统中的各项操作，尽量避免发生磁盘被写满的情况。
+
+## 名词解释
+
+- Data Dir：数据目录，在 BE 配置文件 `be.conf` 的 `storage_root_path` 中指定的各个数据目录。通常一个数据目录对应一个磁盘、因此下文中 **磁盘** 也指代一个数据目录。
+
+## 基本原理
+
+BE 定期（每隔一分钟）会向 FE 汇报一次磁盘使用情况。FE 记录这些统计值，并根据这些统计值，限制不同的操作请求。
+
+在 FE 中分别设置了 **高水位（High Watermark）** 和 **危险水位（Flood Stage）** 两级阈值。危险水位高于高水位。当磁盘使用率高于高水位时，Doris 会限制某些操作的执行（如副本均衡等）。而如果高于危险水位，则会禁止某些操作的执行（如导入）。
+
+同时，在 BE 上也设置了 **危险水位（Flood Stage）**。考虑到 FE 并不能完全及时的检测到 BE 上的磁盘使用情况，以及无法控制某些 BE 自身运行的操作（如 Compaction）。因此 BE 上的危险水位用于 BE 主动拒绝和停止某些操作，达到自我保护的目的。
+
+## FE 参数
+
+**高水位：**
+
+```text
+storage_high_watermark_usage_percent 默认 85 (85%)。
+storage_min_left_capacity_bytes 默认 2GB。
+```
+
+当磁盘空间使用率**大于** `storage_high_watermark_usage_percent`，**或者** 磁盘空间剩余大小**小于** `storage_min_left_capacity_bytes` 时，该磁盘不会再被作为以下操作的目的路径：
+
+- Tablet 均衡操作（Balance）
+- Colocation 表数据分片的重分布（Relocation）
+- Decommission
+
+**危险水位：**
+
+```text
+storage_flood_stage_usage_percent 默认 95 (95%)。
+storage_flood_stage_left_capacity_bytes 默认 1GB。
+```
+
+当磁盘空间使用率**大于** `storage_flood_stage_usage_percent`，**并且** 磁盘空间剩余大小**小于** `storage_flood_stage_left_capacity_bytes` 时，该磁盘不会再被作为以下操作的目的路径，并禁止某些操作：
+
+- Tablet 均衡操作（Balance）
+- Colocation 表数据分片的重分布（Relocation）
+- 副本补齐
+- 恢复操作（Restore）
+- 数据导入（Load/Insert）
+
+## BE 参数
+
+**危险水位：**
+
+```text
+capacity_used_percent_flood_stage 默认 95 (95%)。
+capacity_min_left_bytes_flood_stage 默认 1GB。
+```
+
+当磁盘空间使用率**大于** `storage_flood_stage_usage_percent`，**并且** 磁盘空间剩余大小**小于** `storage_flood_stage_left_capacity_bytes` 时，该磁盘上的以下操作会被禁止：
+
+- Base/Cumulative Compaction。
+- 数据写入。包括各种导入操作。
+- Clone Task。通常发生于副本修复或均衡时。
+- Push Task。发生在 Hadoop 导入的 Loading 阶段，下载文件。
+- Alter Task。Schema Change 或 Rollup 任务。
+- Download Task。恢复操作的 Downloading 阶段。
+
+## 磁盘空间释放
+
+当磁盘空间高于高水位甚至危险水位后，很多操作都会被禁止。此时可以尝试通过以下方式减少磁盘使用率，恢复系统。
+
+- 删除表或分区
+
+ 通过删除表或分区的方式，能够快速降低磁盘空间使用率，恢复集群。**注意：只有 `DROP` 操作可以达到快速降低磁盘空间使用率的目的，`DELETE` 操作不可以。**
+
+ ```text
+ DROP TABLE tbl;
+ ALTER TABLE tbl DROP PARTITION p1;
+ ```
+
+- 扩容 BE
+
+ 扩容后，数据分片会自动均衡到磁盘使用率较低的 BE 节点上。扩容操作会根据数据量及节点数量不同，在数小时或数天后使集群到达均衡状态。
+
+- 修改表或分区的副本
+
+ 可以将表或分区的副本数降低。比如默认3副本可以降低为2副本。该方法虽然降低了数据的可靠性，但是能够快速的降低磁盘使用率，使集群恢复正常。该方法通常用于紧急恢复系统。请在恢复后，通过扩容或删除数据等方式，降低磁盘使用率后，将副本数恢复为 3。
+
+ 修改副本操作为瞬间生效，后台会自动异步的删除多余的副本。
+
+ ```text
+ ALTER TABLE tbl MODIFY PARTITION p1 SET("replication_num" = "2");
+ ```
+
+- 删除多余文件
+
+ 当 BE 进程已经因为磁盘写满而挂掉并无法启动时（此现象可能因 FE 或 BE 检测不及时而发生）。需要通过删除数据目录下的一些临时文件，保证 BE 进程能够启动。以下目录中的文件可以直接删除：
+
+ - log/：日志目录下的日志文件。
+ - snapshot/: 快照目录下的快照文件。
+ - trash/：回收站中的文件。
+
+ **这种操作会对 [从 BE 回收站中恢复数据](./tablet-restore-tool.html) 产生影响。**
+
+ 如果BE还能够启动，则可以使用`ADMIN CLEAN TRASH ON(BackendHost:BackendHeartBeatPort);`来主动清理临时文件，会清理 **所有** trash文件和过期snapshot文件，**这将影响从回收站恢复数据的操作** 。
+
+ 如果不手动执行`ADMIN CLEAN TRASH`，系统仍将会在几分钟至几十分钟内自动执行清理，这里分为两种情况：
+
+ - 如果磁盘占用未达到 **危险水位(Flood Stage)** 的90%，则会清理过期trash文件和过期snapshot文件，此时会保留一些近期文件而不影响恢复数据。
+ - 如果磁盘占用已达到 **危险水位(Flood Stage)** 的90%，则会清理 **所有** trash文件和过期snapshot文件， **此时会影响从回收站恢复数据的操作** 。 自动执行的时间间隔可以通过配置项中的`max_garbage_sweep_interval`和`max_garbage_sweep_interval`更改。
+
+ 出现由于缺少trash文件而导致恢复失败的情况时，可能返回如下结果：
+
+ ```text
+ {"status": "Fail","msg": "can find tablet path in trash"}
+ ```
+
+- 删除数据文件（危险！！！）
+
+ 当以上操作都无法释放空间时，需要通过删除数据文件来释放空间。数据文件在指定数据目录的 `data/` 目录下。删除数据分片（Tablet）必须先确保该 Tablet 至少有一个副本是正常的，否则**删除唯一副本会导致数据丢失**。假设我们要删除 id 为 12345 的 Tablet：
+
+ - 找到 Tablet 对应的目录，通常位于 `data/shard_id/tablet_id/` 下。如：
+
+ `data/0/12345/`
+
+ - 记录 tablet id 和 schema hash。其中 schema hash 为上一步目录的下一级目录名。如下为 352781111：
+
+ `data/0/12345/352781111`
+
+ - 删除数据目录：
+
+ `rm -rf data/0/12345/`
+
+ - 删除 Tablet 元数据（具体参考 [Tablet 元数据管理工具](./tablet-meta-tool.html)）
+
+ `./lib/meta_tool --operation=delete_header --root_path=/path/to/root_path --tablet_id=12345 --schema_hash= 352781111`
\ No newline at end of file
diff --git a/new-docs/zh-CN/admin-manual/maint-monitor/doris-error-code.md b/new-docs/zh-CN/admin-manual/maint-monitor/doris-error-code.md
index ce1a3d69ba..4f9e57deb3 100644
--- a/new-docs/zh-CN/admin-manual/maint-monitor/doris-error-code.md
+++ b/new-docs/zh-CN/admin-manual/maint-monitor/doris-error-code.md
@@ -25,4 +25,154 @@ specific language governing permissions and limitations
under the License.
-->
-# Doris错误代码表
\ No newline at end of file
+# Doris错误代码表
+
+| 错误码 | 错误信息 |
+| :----- | :----------------------------------------------------------- |
+| 1005 | 创建表格失败，在返回错误信息中给出具体原因 |
+| 1007 | 数据库已经存在，不能创建同名的数据库 |
+| 1008 | 数据库不存在，无法删除 |
+| 1044 | 数据库对用户未授权，不能访问 |
+| 1045 | 用户名及密码不匹配，不能访问系统 |
+| 1046 | 没有指定要查询的目标数据库 |
+| 1047 | 用户输入了无效的操作指令 |
+| 1049 | 用户指定了无效的数据库 |
+| 1050 | 数据表已经存在 |
+| 1051 | 无效的数据表 |
+| 1052 | 指定的列名有歧义，不能唯一确定对应列 |
+| 1053 | 为Semi-Join/Anti-Join查询指定了非法的数据列 |
+| 1054 | 指定的列在表中不存在 |
+| 1058 | 查询语句中选择的列数目与查询结果的列数目不一致 |
+| 1060 | 列名重复 |
+| 1064 | 没有存活的Backend节点 |
+| 1066 | 查询语句中出现了重复的表别名 |
+| 1094 | 线程ID无效 |
+| 1095 | 非线程的拥有者不能终止线程的运行 |
+| 1096 | 查询语句没有指定要查询或操作的数据表 |
+| 1102 | 数据库名不正确 |
+| 1104 | 数据表名不正确 |
+| 1105 | 其它错误 |
+| 1110 | 子查询中指定了重复的列 |
+| 1111 | 在Where从句中非法使用聚合函数 |
+| 1113 | 新建表的列集合不能为空 |
+| 1115 | 使用了不支持的字符集 |
+| 1130 | 客户端使用了未被授权的IP地址来访问系统 |
+| 1132 | 无权限修改用户密码 |
+| 1141 | 撤销用户权限时指定了用户不具备的权限 |
+| 1142 | 用户执行了未被授权的操作 |
+| 1166 | 列名不正确 |
+| 1193 | 使用了无效的系统变量名 |
+| 1203 | 用户使用的活跃连接数超过了限制 |
+| 1211 | 不允许创建新用户 |
+| 1227 | 拒绝访问，用户执行了无权限的操作 |
+| 1228 | 会话变量不能通过SET GLOBAL指令来修改 |
+| 1229 | 全局变量应通过SET GLOBAL指令来修改 |
+| 1230 | 相关的系统变量没有缺省值 |
+| 1231 | 给某系统变量设置了无效值 |
+| 1232 | 给某系统变量设置了错误数据类型的值 |
+| 1248 | 没有给内联视图设置别名 |
+| 1251 | 客户端不支持服务器请求的身份验证协议；请升级MySQL客户端 |
+| 1286 | 配置的存储引擎不正确 |
+| 1298 | 配置的时区不正确 |
+| 1347 | 对象与期望的类型不匹配 |
+| 1353 | SELECT和视图的字段列表具有不同的列数 |
+| 1364 | 字段不允许NULL值，但是没有设置缺省值 |
+| 1372 | 密码长度不够 |
+| 1396 | 用户执行的操作运行失败 |
+| 1471 | 指定表不允许插入数据 |
+| 1507 | 删除不存在的分区，且没有指定如果存在才删除的条件 |
+| 1508 | 无法删除所有分区，请改用DROP TABLE |
+| 1517 | 出现了重复的分区名字 |
+| 1567 | 分区的名字不正确 |
+| 1621 | 指定的系统变量是只读的 |
+| 1735 | 表中不存在指定的分区名 |
+| 1748 | 不能将数据插入具有空分区的表中。使用“ SHOW PARTITIONS FROM tbl”来查看此表的当前分区 |
+| 1749 | 表分区不存在 |
+| 5000 | 指定的表不是OLAP表 |
+| 5001 | 指定的PROC路径无效 |
+| 5002 | 必须在列置换中明确指定列名 |
+| 5003 | Key列应排在Value列之前 |
+| 5004 | 表至少应包含1个Key列 |
+| 5005 | 集群ID无效 |
+| 5006 | 无效的查询规划 |
+| 5007 | 冲突的查询规划 |
+| 5008 | 数据插入提示：仅适用于有分区的数据表 |
+| 5009 | PARTITION子句对于INSERT到未分区表中无效 |
+| 5010 | 列数不等于SELECT语句的选择列表数 |
+| 5011 | 无法解析表引用 |
+| 5012 | 指定的值不是一个有效数字 |
+| 5013 | 不支持的时间单位 |
+| 5014 | 表状态不正常 |
+| 5015 | 分区状态不正常 |
+| 5016 | 分区上存在数据导入任务 |
+| 5017 | 指定列不是Key列 |
+| 5018 | 值的格式无效 |
+| 5019 | 数据副本与版本不匹配 |
+| 5021 | BE节点已离线 |
+| 5022 | 非分区表中的分区数不是1 |
+| 5023 | alter语句中无任何操作 |
+| 5024 | 任务执行超时 |
+| 5025 | 数据插入操作失败 |
+| 5026 | 通过SELECT语句创建表时使用了不支持的数据类型 |
+| 5027 | 没有设置指定的参数 |
+| 5028 | 没有找到指定的集群 |
+| 5030 | 某用户没有访问集群的权限 |
+| 5031 | 没有指定参数或参数无效 |
+| 5032 | 没有指定集群实例数目 |
+| 5034 | 集群名已经存在 |
+| 5035 | 集群已经存在 |
+| 5036 | 集群中BE节点不足 |
+| 5037 | 删除集群之前，必须删除集群中的所有数据库 |
+| 5037 | 集群中不存在这个ID的BE节点 |
+| 5038 | 没有指定集群名字 |
+| 5040 | 未知的集群 |
+| 5041 | 没有集群名字 |
+| 5042 | 没有权限 |
+| 5043 | 实例数目应大于0 |
+| 5046 | 源集群不存在 |
+| 5047 | 目标集群不存在 |
+| 5048 | 源数据库不存在 |
+| 5049 | 目标数据库不存在 |
+| 5050 | 没有选择集群，请输入集群 |
+| 5051 | 应先将源数据库连接到目标数据库 |
+| 5052 | 集群内部错误：BE节点错误信息 |
+| 5053 | 没有从源数据库到目标数据库的迁移任务 |
+| 5054 | 指定数据库已经连接到目标数据库，或正在迁移数据 |
+| 5055 | 数据连接或者数据迁移不能在同一集群内执行 |
+| 5056 | 不能删除数据库：它被关联至其它数据库或正在迁移数据 |
+| 5056 | 不能重命名数据库：它被关联至其它数据库或正在迁移数据 |
+| 5056 | 集群中BE节点不足 |
+| 5056 | 集群内已存在指定数目的BE节点 |
+| 5059 | 集群中存在处于下线状态的BE节点 |
+| 5062 | 不正确的群集名称（名称'default_cluster'是保留名称） |
+| 5063 | 类型名不正确 |
+| 5064 | 通用错误提示 |
+| 5063 | Colocate功能已被管理员禁用 |
+| 5063 | colocate数据表不存在 |
+| 5063 | Colocate表必须是OLAP表 |
+| 5063 | Colocate表应该具有同样的副本数目 |
+| 5063 | Colocate表应该具有同样的分桶数目 |
+| 5063 | Colocate表的分区列数目必须一致 |
+| 5063 | Colocate表的分区列的数据类型必须一致 |
+| 5064 | 指定表不是colocate表 |
+| 5065 | 指定的操作是无效的 |
+| 5065 | 指定的时间单位是非法的，正确的单位包括：HOUR / DAY / WEEK / MONTH |
+| 5066 | 动态分区起始值应该小于0 |
+| 5066 | 动态分区起始值不是有效的数字 |
+| 5066 | 动态分区结束值应该大于0 |
+| 5066 | 动态分区结束值不是有效的数字 |
+| 5066 | 动态分区结束值为空 |
+| 5067 | 动态分区分桶数应该大于0 |
+| 5067 | 动态分区分桶值不是有效的数字 |
+| 5066 | 动态分区分桶值为空 |
+| 5068 | 是否允许动态分区的值不是有效的布尔值：true或者false |
+| 5069 | 指定的动态分区名前缀是非法的 |
+| 5070 | 指定的操作被禁止了 |
+| 5071 | 动态分区副本数应该大于0 |
+| 5072 | 动态分区副本值不是有效的数字 |
+| 5073 | 原始创建表stmt为空 |
+| 5074 | 创建历史动态分区参数：create_history_partition无效，期望的是：true或者false |
+| 5076 | 指定的保留历史分区时间段为空 |
+| 5077 | 指定的保留历史分区时间段无效 |
+| 5078 | 指定的保留历史分区时间段必须是成对的时间 |
+| 5079 | 指定的保留历史分区时间段对应位置的第一个时间比第二个时间大（起始时间大于结束时间） |
\ No newline at end of file
diff --git a/new-docs/zh-CN/admin-manual/maint-monitor/metadata-operation.md b/new-docs/zh-CN/admin-manual/maint-monitor/metadata-operation.md
index 640f6ddc5e..82f642325b 100644
--- a/new-docs/zh-CN/admin-manual/maint-monitor/metadata-operation.md
+++ b/new-docs/zh-CN/admin-manual/maint-monitor/metadata-operation.md
@@ -24,4 +24,372 @@ specific language governing permissions and limitations
under the License.
-->
-# 元数据运维
\ No newline at end of file
+# 元数据运维
+
+本文档主要介绍在实际生产环境中，如何对 Doris 的元数据进行管理。包括 FE 节点建议的部署方式、一些常用的操作方法、以及常见错误的解决方法。
+
+在阅读本文当前，请先阅读 [Doris 元数据设计文档](../../internal/metadata-design.md) 了解 Doris 元数据的工作原理。
+
+## 重要提示
+
+* 当前元数据的设计是无法向后兼容的。即如果新版本有新增的元数据结构变动（可以查看 FE 代码中的 `FeMetaVersion.java` 文件中是否有新增的 VERSION），那么在升级到新版本后，通常是无法再回滚到旧版本的。所以，在升级 FE 之前，请务必按照 [升级文档](../upgrade.md) 中的操作，测试元数据兼容性。
+
+## 元数据目录结构
+
+我们假设在 fe.conf 中指定的 `meta_dir` 的路径为 `/path/to/palo-meta`。那么一个正常运行中的 Doris 集群，元数据的目录结构应该如下：
+
+```
+/path/to/palo-meta/
+ |-- bdb/
+ | |-- 00000000.jdb
+ | |-- je.config.csv
+ | |-- je.info.0
+ | |-- je.info.0.lck
+ | |-- je.lck
+ | `-- je.stat.csv
+ `-- image/
+ |-- ROLE
+ |-- VERSION
+ `-- image.xxxx
+```
+
+1. bdb 目录
+
+ 我们将 [bdbje](https://www.oracle.com/technetwork/database/berkeleydb/overview/index-093405.html) 作为一个分布式的 kv 系统，存放元数据的 journal。这个 bdb 目录相当于 bdbje 的 “数据目录”。
+
+ 其中 `.jdb` 后缀的是 bdbje 的数据文件。这些数据文件会随着元数据 journal 的不断增多而越来越多。当 Doris 定期做完 image 后，旧的日志就会被删除。所以正常情况下，这些数据文件的总大小从几 MB 到几 GB 不等（取决于使用 Doris 的方式，如导入频率等）。当数据文件的总大小大于 10GB，则可能需要怀疑是否是因为 image 没有成功，或者分发 image 失败导致的历史 journal 一直无法删除。
+
+ `je.info.0` 是 bdbje 的运行日志。这个日志中的时间是 UTC+0 时区的。我们可能在后面的某个版本中修复这个问题。通过这个日志，也可以查看一些 bdbje 的运行情况。
+
+2. image 目录
+
+ image 目录用于存放 Doris 定期生成的元数据镜像文件。通常情况下，你会看到有一个 `image.xxxxx` 的镜像文件。其中 `xxxxx` 是一个数字。这个数字表示该镜像包含 `xxxxx` 号之前的所有元数据 journal。而这个文件的生成时间（通过 `ls -al` 查看即可）通常就是镜像的生成时间。
+
+ 你也可能会看到一个 `image.ckpt` 文件。这是一个正在生成的元数据镜像。通过 `du -sh` 命令应该可以看到这个文件大小在不断变大，说明镜像内容正在写入这个文件。当镜像写完后，会自动重名为一个新的 `image.xxxxx` 并替换旧的 image 文件。
+
+ 只有角色为 Master 的 FE 才会主动定期生成 image 文件。每次生成完后，都会推送给其他非 Master 角色的 FE。当确认其他所有 FE 都收到这个 image 后，Master FE 会删除 bdbje 中旧的元数据 journal。所以，如果 image 生成失败，或者 image 推送给其他 FE 失败时，都会导致 bdbje 中的数据不断累积。
+
+ `ROLE` 文件记录了 FE 的类型（FOLLOWER 或 OBSERVER），是一个文本文件。
+
+ `VERSION` 文件记录了这个 Doris 集群的 cluster id，以及用于各个节点之间访问认证的 token，也是一个文本文件。
+
+ `ROLE` 文件和 `VERSION` 文件只可能同时存在，或同时不存在（如第一次启动时）。
+
+## 基本操作
+
+### 启动单节点 FE
+
+单节点 FE 是最基本的一种部署方式。一个完整的 Doris 集群，至少需要一个 FE 节点。当只有一个 FE 节点时，这个节点的类型为 Follower，角色为 Master。
+
+1. 第一次启动
+
+ 1. 假设在 fe.conf 中指定的 `meta_dir` 的路径为 `/path/to/palo-meta`。
+ 2. 确保 `/path/to/palo-meta` 已存在，权限正确，且目录为空。
+ 3. 直接通过 `sh bin/start_fe.sh` 即可启动。
+ 4. 启动后，你应该可以在 fe.log 中看到如下日志：
+
+ * Palo FE starting...
+ * image does not exist: /path/to/palo-meta/image/image.0
+ * transfer from INIT to UNKNOWN
+ * transfer from UNKNOWN to MASTER
+ * the very first time to open bdb, dbname is 1
+ * start fencing, epoch number is 1
+ * finish replay in xxx msec
+ * QE service start
+ * thrift server started
+
+ 以上日志不一定严格按照这个顺序，但基本类似。
+
+ 5. 单节点 FE 的第一次启动通常不会遇到问题。如果你没有看到以上日志，一般来说是没有仔细按照文档步骤操作，请仔细阅读相关 wiki。
+
+2. 重启
+
+ 1. 直接使用 `sh bin/start_fe.sh` 可以重新启动已经停止的 FE 节点。
+ 2. 重启后，你应该可以在 fe.log 中看到如下日志：
+
+ * Palo FE starting...
+ * finished to get cluster id: xxxx, role: FOLLOWER and node name: xxxx
+ * 如果重启前还没有 image 产生，则会看到：
+ * image does not exist: /path/to/palo-meta/image/image.0
+
+ * 如果重启前有 image 产生，则会看到：
+ * start load image from /path/to/palo-meta/image/image.xxx. is ckpt: false
+ * finished load image in xxx ms
+
+ * transfer from INIT to UNKNOWN
+ * replayed journal id is xxxx, replay to journal id is yyyy
+ * transfer from UNKNOWN to MASTER
+ * finish replay in xxx msec
+ * master finish replay journal, can write now.
+ * begin to generate new image: image.xxxx
+ * start save image to /path/to/palo-meta/image/image.ckpt. is ckpt: true
+ * finished save image /path/to/palo-meta/image/image.ckpt in xxx ms. checksum is xxxx
+ * push image.xxx to other nodes. totally xx nodes, push successed xx nodes
+ * QE service start
+ * thrift server started
+
+ 以上日志不一定严格按照这个顺序，但基本类似。
+
+3. 常见问题
+
+ 对于单节点 FE 的部署，启停通常不会遇到什么问题。如果有问题，请先参照相关 wiki，仔细核对你的操作步骤。
+
+### 添加 FE
+
+添加 FE 流程在 [弹性扩缩容](../elastic-expansion.html) 有详细介绍，不再赘述。这里主要说明一些注意事项，以及常见问题。
+
+1. 注意事项
+
+ * 在添加新的 FE 之前，一定先确保当前的 Master FE 运行正常（连接是否正常，JVM 是否正常，image 生成是否正常，bdbje 数据目录是否过大等等）
+ * 第一次启动新的 FE，一定确保添加了 `--helper` 参数指向 Master FE。再次启动时可不用添加 `--helper`。（如果指定了 `--helper`，FE 会直接询问 helper 节点自己的角色，如果没有指定，FE会尝试从 `palo-meta/image/` 目录下的 `ROLE` 和 `VERSION` 文件中获取信息）。
+ * 第一次启动新的 FE，一定确保这个 FE 的 `meta_dir` 已经创建、权限正确且为空。
+ * 启动新的 FE，和执行 `ALTER SYSTEM ADD FOLLOWER/OBSERVER` 语句在元数据添加 FE，这两个操作的顺序没有先后要求。如果先启动了新的 FE，而没有执行语句，则新的 FE 日志中会一直滚动 `current node is not added to the group. please add it first.` 字样。当执行语句后，则会进入正常流程。
+ * 请确保前一个 FE 添加成功后，再添加下一个 FE。
+ * 建议直接连接到 MASTER FE 执行 `ALTER SYSTEM ADD FOLLOWER/OBSERVER` 语句。
+
+2. 常见问题
+
+ 1. this node is DETACHED
+
+ 当第一次启动一个待添加的 FE 时，如果 Master FE 上的 palo-meta/bdb 中的数据很大，则可能在待添加的 FE 日志中看到 `this node is DETACHED.` 字样。这时，bdbje 正在复制数据，你可以看到待添加的 FE 的 `bdb/` 目录正在变大。这个过程通常会在数分钟不等（取决于 bdbje 中的数据量）。之后，fe.log 中可能会有一些 bdbje 相关的错误堆栈信息。如果最终日志中显示 `QE service start` 和 `thrift server started`，则通常表示启动成功。可以通过 mysql-client 连接这个 FE 尝试操作。如果没有出现这些字样，则可能是 bdbje 复制日志超时等问题。这时，直接再次重启这个 FE，通常即可解决问题。
+
+ 2. 各种原因导致添加失败
+
+ * 如果添加的是 OBSERVER，因为 OBSERVER 类型的 FE 不参与元数据的多数写，理论上可以随意启停。因此，对于添加 OBSERVER 失败的情况。可以直接杀死 OBSERVER FE 的进程，清空 OBSERVER 的元数据目录后，重新进行一遍添加流程。
+
+ * 如果添加的是 FOLLOWER，因为 FOLLOWER 是参与元数据多数写的。所以有可能FOLLOWER 已经加入 bdbje 选举组内。如果这时只有两个 FOLLOWER 节点（包括 MASTER），那么停掉一个 FE，可能导致另一个 FE 也因无法进行多数写而退出。此时，我们应该先通过 `ALTER SYSTEM DROP FOLLOWER` 命令，从元数据中删除新添加的 FOLLOWER 节点，然后再杀死 FOLLOWER 进程，清空元数据，重新进行一遍添加流程。
+
+
+### 删除 FE
+
+通过 `ALTER SYSTEM DROP FOLLOWER/OBSERVER` 命令即可删除对应类型的 FE。以下有几点注意事项：
+
+* 对于 OBSERVER 类型的 FE，直接 DROP 即可，无风险。
+
+* 对于 FOLLOWER 类型的 FE。首先，应保证在有奇数个 FOLLOWER 的情况下（3个或以上），开始删除操作。
+
+ 1. 如果删除非 MASTER 角色的 FE，建议连接到 MASTER FE，执行 DROP 命令，再杀死进程即可。
+ 2. 如果要删除 MASTER FE，先确认有奇数个 FOLLOWER FE 并且运行正常。然后先杀死 MASTER FE 的进程。这时会有某一个 FE 被选举为 MASTER。在确认剩下的 FE 运行正常后，连接到新的 MASTER FE，执行 DROP 命令删除之前老的 MASTER FE 即可。
+
+## 高级操作
+
+### 故障恢复
+
+FE 有可能因为某些原因出现无法启动 bdbje、FE 之间无法同步等问题。现象包括无法进行元数据写操作、没有 MASTER 等等。这时，我们需要手动操作来恢复 FE。手动恢复 FE 的大致原理，是先通过当前 `meta_dir` 中的元数据，启动一个新的 MASTER，然后再逐台添加其他 FE。请严格按照如下步骤操作：
+
+1. 首先，停止所有 FE 进程，同时停止一切业务访问。保证在元数据恢复期间，不会因为外部访问导致其他不可预期的问题。
+
+2. 确认哪个 FE 节点的元数据是最新：
+
+ * 首先，**务必先备份所有 FE 的 `meta_dir` 目录。**
+ * 通常情况下，Master FE 的元数据是最新的。可以查看 `meta_dir/image` 目录下，image.xxxx 文件的后缀，数字越大，则表示元数据越新。
+ * 通常，通过比较所有 FOLLOWER FE 的 image 文件，找出最新的元数据即可。
+ * 之后，我们要使用这个拥有最新元数据的 FE 节点，进行恢复。
+ * 如果使用 OBSERVER 节点的元数据进行恢复会比较麻烦，建议尽量选择 FOLLOWER 节点。
+
+3. 以下操作都在由第2步中选择出来的 FE 节点上进行。
+
+ 1. 如果该节点是一个 OBSERVER，先将 `meta_dir/image/ROLE` 文件中的 `role=OBSERVER` 改为 `role=FOLLOWER`。（从 OBSERVER 节点恢复会比较麻烦，先按这里的步骤操作，后面会有单独说明）
+ 2. 在 fe.conf 中添加配置：`metadata_failure_recovery=true`。
+ 3. 执行 `sh bin/start_fe.sh` 启动这个 FE。
+ 4. 如果正常，这个 FE 会以 MASTER 的角色启动，类似于前面 `启动单节点 FE` 一节中的描述。在 fe.log 应该会看到 `transfer from XXXX to MASTER` 等字样。
+ 5. 启动完成后，先连接到这个 FE，执行一些查询导入，检查是否能够正常访问。如果不正常，有可能是操作有误，建议仔细阅读以上步骤，用之前备份的元数据再试一次。如果还是不行，问题可能就比较严重了。
+ 6. 如果成功，通过 `show frontends;` 命令，应该可以看到之前所添加的所有 FE，并且当前 FE 是 master。
+ 7. 将 fe.conf 中的 `metadata_failure_recovery=true` 配置项删除，或者设置为 `false`，然后重启这个 FE（**重要**）。
+
+
+ > 如果你是从一个 OBSERVER 节点的元数据进行恢复的，那么完成如上步骤后，通过 `show frontends;` 语句你会发现，当前这个 FE 的角色为 OBSERVER，但是 `IsMaster` 显示为 `true`。这是因为，这里看到的 “OBSERVER” 是记录在 Doris 的元数据中的，而是否是 master，是记录在 bdbje 的元数据中的。因为我们是从一个 OBSERVER 节点恢复的，所以这里出现了不一致。请按如下步骤修复这个问题（这个问题我们会在之后的某个版本修复）：
+
+ > 1. 先把除了这个 “OBSERVER” 以外的所有 FE 节点 DROP 掉。
+ > 2. 通过 `ADD FOLLOWER` 命令，添加一个新的 FOLLOWER FE，假设在 hostA 上。
+ > 3. 在 hostA 上启动一个全新的 FE，通过 `--helper` 的方式加入集群。
+ > 4. 启动成功后，通过 `show frontends;` 语句，你应该能看到两个 FE，一个是之前的 OBSERVER，一个是新添加的 FOLLOWER，并且 OBSERVER 是 master。
+ > 5. 确认这个新的 FOLLOWER 是可以正常工作之后，用这个新的 FOLLOWER 的元数据，重新执行一遍故障恢复操作。
+ > 6. 以上这些步骤的目的，其实就是人为的制造出一个 FOLLOWER 节点的元数据，然后用这个元数据，重新开始故障恢复。这样就避免了从 OBSERVER 恢复元数据所遇到的不一致的问题。
+
+ > `metadata_failure_recovery=true` 的含义是，清空 "bdbje" 的元数据。这样 bdbje 就不会再联系之前的其他 FE 了，而作为一个独立的 FE 启动。这个参数只有在恢复启动时才需要设置为 true。恢复完成后，一定要设置为 false，否则一旦重启，bdbje 的元数据又会被清空，导致其他 FE 无法正常工作。
+
+4. 第3步执行成功后，我们再通过 `ALTER SYSTEM DROP FOLLOWER/OBSERVER` 命令，将之前的其他的 FE 从元数据删除后，按加入新 FE 的方式，重新把这些 FE 添加一遍。
+
+5. 如果以上操作正常，则恢复完毕。
+
+### FE 类型变更
+
+如果你需要将当前已有的 FOLLOWER/OBSERVER 类型的 FE，变更为 OBSERVER/FOLLOWER 类型，请先按照前面所述的方式删除 FE，再添加对应类型的 FE 即可
+
+### FE 迁移
+
+如果你需要将一个 FE 从当前节点迁移到另一个节点，分以下几种情况。
+
+1. 非 MASTER 节点的 FOLLOWER，或者 OBSERVER 迁移
+
+ 直接添加新的 FOLLOWER/OBSERVER 成功后，删除旧的 FOLLOWER/OBSERVER 即可。
+
+2. 单节点 MASTER 迁移
+
+ 当只有一个 FE 时，参考 `故障恢复` 一节。将 FE 的 palo-meta 目录拷贝到新节点上，按照 `故障恢复` 一节中，步骤3的方式启动新的 MASTER
+
+3. 一组 FOLLOWER 从一组节点迁移到另一组新的节点
+
+ 在新的节点上部署 FE，通过添加 FOLLOWER 的方式先加入新节点。再逐台 DROP 掉旧节点即可。在逐台 DROP 的过程中，MASTER 会自动选择在新的 FOLLOWER 节点上。
+
+### 更换 FE 端口
+
+FE 目前有以下几个端口
+
+* edit_log_port：bdbje 的通信端口
+* http_port：http 端口，也用于推送 image
+* rpc_port：FE 的 thrift server port
+* query_port：Mysql 连接端口
+
+1. edit_log_port
+
+ 如果需要更换这个端口，则需要参照 `故障恢复` 一节中的操作，进行恢复。因为该端口已经被持久化到 bdbje 自己的元数据中（同时也记录在 Doris 自己的元数据中），需要通过设置 `metadata_failure_recovery=true` 来清空 bdbje 的元数据。
+
+2. http_port
+
+ 所有 FE 的 http_port 必须保持一致。所以如果要修改这个端口，则所有 FE 都需要修改并重启。修改这个端口，在多 FOLLOWER 部署的情况下会比较复杂（涉及到鸡生蛋蛋生鸡的问题...），所以不建议有这种操作。如果必须，直接按照 `故障恢复` 一节中的操作吧。
+
+3. rpc_port
+
+ 修改配置后，直接重启 FE 即可。Master FE 会通过心跳将新的端口告知 BE。只有 Master FE 的这个端口会被使用。但仍然建议所有 FE 的端口保持一致。
+
+4. query_port
+
+ 修改配置后，直接重启 FE 即可。这个只影响到 mysql 的连接目标。
+
+
+### 从 FE 内存中恢复元数据
+
+在某些极端情况下，磁盘上 image 文件可能会损坏，但是内存中的元数据是完好的，此时我们可以先从内存中 dump 出元数据，再替换掉磁盘上的 image 文件，来恢复元数据，整个**不停查询服务**的操作步骤如下：
+1. 集群停止所有 Load,Create,Alter 操作
+2. 执行以下命令，从 Master FE 内存中 dump 出元数据：(下面称为 image_mem)
+```
+curl -u $root_user:$password http://$master_hostname:8030/dump
+```
+3. 用 image_mem 文件替换掉 OBSERVER FE 节点上`meta_dir/image`目录下的 image 文件，重启 OBSERVER FE 节点，
+验证 image_mem 文件的完整性和正确性（可以在 FE Web 页面查看 DB 和 Table 的元数据是否正常，查看fe.log 是否有异常，是否在正常 replayed journal）
+4. 依次用 image_mem 文件替换掉 FOLLOWER FE 节点上`meta_dir/image`目录下的 image 文件，重启 FOLLOWER FE 节点，
+确认元数据和查询服务都正常
+5. 用 image_mem 文件替换掉 Master FE 节点上`meta_dir/image`目录下的 image 文件，重启 Master FE 节点，
+确认 FE Master 切换正常， Master FE 节点可以通过 checkpoint 正常生成新的 image 文件
+6. 集群恢复所有 Load,Create,Alter 操作
+
+**注意：如果 Image 文件很大，整个操作过程耗时可能会很长，所以在此期间，要确保 Master FE 不会通过 checkpoint 生成新的 image 文件。
+当观察到 Master FE 节点上 `meta_dir/image`目录下的 `image.ckpt` 文件快和 `image.xxx` 文件一样大时，可以直接删除掉`image.ckpt` 文件。**
+
+### 查看 BDBJE 中的数据
+
+FE 的元数据日志以 Key-Value 的方式存储在 BDBJE 中。某些异常情况下，可能因为元数据错误而无法启动 FE。在这种情况下，Doris 提供一种方式可以帮助用户查询 BDBJE 中存储的数据，以方便进行问题排查。
+
+首先需在 fe.conf 中增加配置：`enable_bdbje_debug_mode=true`，之后通过 `sh start_fe.sh --daemon` 启动 FE。
+
+此时，FE 将进入 debug 模式，仅会启动 http server 和 MySQL server，并打开 BDBJE 实例，但不会进行任何元数据的加载及后续其他启动流程。
+
+这是，我们可以通过访问 FE 的 web 页面，或通过 MySQL 客户端连接到 Doris 后，通过 `show proc /bdbje;` 来查看 BDBJE 中存储的数据。
+
+```
+mysql> show proc "/bdbje";
++----------+---------------+---------+
+| DbNames | JournalNumber | Comment |
++----------+---------------+---------+
+| 110589 | 4273 | |
+| epochDB | 4 | |
+| metricDB | 430694 | |
++----------+---------------+---------+
+```
+
+第一级目录会展示 BDBJE 中所有的 database 名称，以及每个 database 中的 entry 数量。
+
+```
+mysql> show proc "/bdbje/110589";
++-----------+
+| JournalId |
++-----------+
+| 1 |
+| 2 |
+
+...
+| 114858 |
+| 114859 |
+| 114860 |
+| 114861 |
++-----------+
+4273 rows in set (0.06 sec)
+```
+
+进入第二级，则会罗列指定 database 下的所有 entry 的 key。
+
+```
+mysql> show proc "/bdbje/110589/114861";
++-----------+--------------+---------------------------------------------+
+| JournalId | OpType | Data |
++-----------+--------------+---------------------------------------------+
+| 114861 | OP_HEARTBEAT | org.apache.doris.persist.HbPackage@6583d5fb |
++-----------+--------------+---------------------------------------------+
+1 row in set (0.05 sec)
+```
+
+第三级则可以展示指定 key 的 value 信息。
+
+## 最佳实践
+
+FE 的部署推荐，在 [安装与部署文档](../../install/install-deploy.md) 中有介绍，这里再做一些补充。
+
+* **如果你并不十分了解 FE 元数据的运行逻辑，或者没有足够 FE 元数据的运维经验，我们强烈建议在实际使用中，只部署一个 FOLLOWER 类型的 FE 作为 MASTER，其余 FE 都是 OBSERVER，这样可以减少很多复杂的运维问题！** 不用过于担心 MASTER 单点故障导致无法进行元数据写操作。首先，如果你配置合理，FE 作为 java 进程很难挂掉。其次，如果 MASTER 磁盘损坏（概率非常低），我们也可以用 OBSERVER 上的元数据，通过 `故障恢复` 的方式手动恢复。
+
+* FE 进程的 JVM 一定要保证足够的内存。我们**强烈建议** FE 的 JVM 内存至少在 10GB 以上，推荐 32GB 至 64GB。并且部署监控来监控 JVM 的内存使用情况。因为如果FE出现OOM，可能导致元数据写入失败，造成一些**无法恢复**的故障！
+
+* FE 所在节点要有足够的磁盘空间，以防止元数据过大导致磁盘空间不足。同时 FE 日志也会占用十几G 的磁盘空间。
+
+## 其他常见问题
+
+1. fe.log 中一直滚动 `meta out of date. current time: xxx, synchronized time: xxx, has log: xxx, fe type: xxx`
+
+ 这个通常是因为 FE 无法选举出 Master。比如配置了 3 个 FOLLOWER，但是只启动了一个 FOLLOWER，则这个 FOLLOWER 会出现这个问题。通常，只要把剩余的 FOLLOWER 启动起来就可以了。如果启动起来后，仍然没有解决问题，那么可能需要按照 `故障恢复` 一节中的方式，手动进行恢复。
+
+2. `Clock delta: xxxx ms. between Feeder: xxxx and this Replica exceeds max permissible delta: xxxx ms.`
+
+ bdbje 要求各个节点之间的时钟误差不能超过一定阈值。如果超过，节点会异常退出。我们默认设置的阈值为 5000 ms，由 FE 的参数 `max_bdbje_clock_delta_ms` 控制，可以酌情修改。但我们建议使用 ntp 等时钟同步方式保证 Doris 集群各主机的时钟同步。
+
+3. `image/` 目录下的镜像文件很久没有更新
+
+ Master FE 会默认每 50000 条元数据 journal，生成一个镜像文件。在一个频繁使用的集群中，通常每隔半天到几天的时间，就会生成一个新的 image 文件。如果你发现 image 文件已经很久没有更新了（比如超过一个星期），则可以顺序的按照如下方法，查看具体原因：
+
+ 1. 在 Master FE 的 fe.log 中搜索 `memory is not enough to do checkpoint. Committed memroy xxxx Bytes, used memory xxxx Bytes.` 字样。如果找到，则说明当前 FE 的 JVM 内存不足以用于生成镜像（通常我们需要预留一半的 FE 内存用于 image 的生成）。那么需要增加 JVM 的内存并重启 FE 后，再观察。每次 Master FE 重启后，都会直接生成一个新的 image。也可用这种重启方式，主动地生成新的 image。注意，如果是多 FOLLOWER 部署，那么当你重启当前 Master FE 后，另一个 FOLLOWER FE 会变成 MASTER，则后续的 image 生成会由新的 Master 负责。因此，你可能需要修改所有 FOLLOWER FE 的 JVM 内存配置。
+
+ 2. 在 Master FE 的 fe.log 中搜索 `begin to generate new image: image.xxxx`。如果找到，则说明开始生成 image 了。检查这个线程的后续日志，如果出现 `checkpoint finished save image.xxxx`，则说明 image 写入成功。如果出现 `Exception when generate new image file`，则生成失败，需要查看具体的错误信息。
+
+
+4. `bdb/` 目录的大小非常大，达到几个G或更多
+
+ 如果在排除无法生成新的 image 的错误后，bdb 目录在一段时间内依然很大。则可能是因为 Master FE 推送 image 不成功。可以在 Master FE 的 fe.log 中搜索 `push image.xxxx to other nodes. totally xx nodes, push successed yy nodes`。如果 yy 比 xx 小，则说明有的 FE 没有被推送成功。可以在 fe.log 中查看到具体的错误 `Exception when pushing image file. url = xxx`。
+
+ 同时，你也可以在 FE 的配置文件中添加配置：`edit_log_roll_num=xxxx`。该参数设定了每多少条元数据 journal，做一次 image。默认是 50000。可以适当改小这个数字，使得 image 更加频繁，从而加速删除旧的 journal。
+
+5. FOLLOWER FE 接连挂掉
+
+ 因为 Doris 的元数据采用多数写策略，即一条元数据 journal 必须至少写入多数个 FOLLOWER FE 后（比如 3 个 FOLLOWER，必须写成功 2 个），才算成功。而如果写入失败，FE 进程会主动退出。那么假设有 A、B、C 三个 FOLLOWER，C 先挂掉，然后 B 再挂掉，那么 A 也会跟着挂掉。所以如 `最佳实践` 一节中所述，如果你没有丰富的元数据运维经验，不建议部署多 FOLLOWER。
+
+6. fe.log 中出现 `get exception when try to close previously opened bdb database. ignore it`
+
+ 如果后面有 `ignore it` 字样，通常无需处理。如果你有兴趣，可以在 `BDBEnvironment.java` 搜索这个错误，查看相关注释说明。
+
+7. 从 `show frontends;` 看，某个 FE 的 `Join` 列为 `true`，但是实际该 FE 不正常
+
+ 通过 `show frontends;` 查看到的 `Join` 信息。该列如果为 `true`，仅表示这个 FE **曾经加入过** 集群。并不能表示当前仍然正常的存在于集群中。如果为 `false`，则表示这个 FE **从未加入过** 集群。
+
+8. 关于 FE 的配置 `master_sync_policy`, `replica_sync_policy` 和 `txn_rollback_limit`
+
+ `master_sync_policy` 用于指定当 Leader FE 写元数据日志时，是否调用 fsync(), `replica_sync_policy` 用于指定当 FE HA 部署时，其他 Follower FE 在同步元数据时，是否调用 fsync()。在早期的 Doris 版本中，这两个参数默认是 `WRITE_NO_SYNC`，即都不调用 fsync()。在最新版本的 Doris 中，默认已修改为 `SYNC`，即都调用 fsync()。调用 fsync() 会显著降低元数据写盘的效率。在某些环境下，IOPS 可能降至几百，延迟增加到2-3ms（但对于 Doris 元数据操作依然够用）。因此我们建议以下配置：
+
+ 1. 对于单 Follower FE 部署，`master_sync_policy` 设置为 `SYNC`，防止 FE 系统宕机导致元数据丢失。
+ 2. 对于多 Follower FE 部署，可以将 `master_sync_policy` 和 `replica_sync_policy` 设为 `WRITE_NO_SYNC`，因为我们认为多个系统同时宕机的概率非常低。
+
+ 如果在单 Follower FE 部署中，`master_sync_policy` 设置为 `WRITE_NO_SYNC`，则可能出现 FE 系统宕机导致元数据丢失。这时如果有其他 Observer FE 尝试重启时，可能会报错：
+
+ ```
+ Node xxx must rollback xx total commits(numPassedDurableCommits of which were durable) to the earliest point indicated by transaction xxxx in order to rejoin the replication group, but the transaction rollback limit of xxx prohibits this.
+ ```
+
+ 意思有部分已经持久化的事务需要回滚，但条数超过上限。这里我们的默认上限是 100，可以通过设置 `txn_rollback_limit` 改变。该操作仅用于尝试正常启动 FE，但已丢失的元数据无法恢复。
diff --git a/new-docs/zh-CN/admin-manual/maint-monitor/monitor-alert.md b/new-docs/zh-CN/admin-manual/maint-monitor/monitor-alert.md
index 4d9c83cfe8..3f1ad9dcf9 100644
--- a/new-docs/zh-CN/admin-manual/maint-monitor/monitor-alert.md
+++ b/new-docs/zh-CN/admin-manual/maint-monitor/monitor-alert.md
@@ -24,4 +24,286 @@ specific language governing permissions and limitations
under the License.
-->
-# 监控和报警
\ No newline at end of file
+# 监控和报警
+
+本文档主要介绍 Doris 的监控项及如何采集、展示监控项。以及如何配置报警（TODO）
+
+[Dashboard 模板点击下载](https://grafana.com/dashboards/9734/revisions)
+
+> 注：0.9.0（不含）之前的版本请使用 revision 1。0.9.x 版本请使用 revision 2。0.10.x 版本请使用 revision 3。
+
+Dashboard 模板会不定期更新。更新模板的方式见最后一小节。
+
+欢迎提供更优的 dashboard。
+
+## 组件
+
+Doris 使用 [Prometheus](https://prometheus.io/) 和 [Grafana](https://grafana.com/) 进项监控项的采集和展示。
+
+
+
+1. Prometheus
+
+ Prometheus 是一款开源的系统监控和报警套件。它可以通过 Pull 或 Push 采集被监控系统的监控项，存入自身的时序数据库中。并且通过丰富的多维数据查询语言，满足用户的不同数据展示需求。
+
+2. Grafana
+
+ Grafana 是一款开源的数据分析和展示平台。支持包括 Prometheus 在内的多个主流时序数据库源。通过对应的数据库查询语句，从数据源中获取展现数据。通过灵活可配置的 Dashboard，快速的将这些数据以图表的形式展示给用户。
+
+> 注: 本文档仅提供一种使用 Prometheus 和 Grafana 进行 Doris 监控数据采集和展示的方式。原则上不开发、维护这些组件。更多关于这些组件的详细介绍，请移步对应官方文档进行查阅。
+
+## 监控数据
+
+Doris 的监控数据通过 Frontend 和 Backend 的 http 接口向外暴露。监控数据以 Key-Value 的文本形式对外展现。每个 Key 还可能有不同的 Label 加以区分。当用户搭建好 Doris 后，可以在浏览器，通过以下接口访问到节点的监控数据：
+
+* Frontend: `fe_host:fe_http_port/metrics`
+* Backend: `be_host:be_web_server_port/metrics`
+* Broker: 暂不提供
+
+用户将看到如下监控项结果（示例为 FE 部分监控项）：
+
+ ```
+ # HELP jvm_heap_size_bytes jvm heap stat
+ # TYPE jvm_heap_size_bytes gauge
+ jvm_heap_size_bytes{type="max"} 41661235200
+ jvm_heap_size_bytes{type="committed"} 19785285632
+ jvm_heap_size_bytes{type="used"} 10113221064
+ # HELP jvm_non_heap_size_bytes jvm non heap stat
+ # TYPE jvm_non_heap_size_bytes gauge
+ jvm_non_heap_size_bytes{type="committed"} 105295872
+ jvm_non_heap_size_bytes{type="used"} 103184784
+ # HELP jvm_young_size_bytes jvm young mem pool stat
+ # TYPE jvm_young_size_bytes gauge
+ jvm_young_size_bytes{type="used"} 6505306808
+ jvm_young_size_bytes{type="peak_used"} 10308026368
+ jvm_young_size_bytes{type="max"} 10308026368
+ # HELP jvm_old_size_bytes jvm old mem pool stat
+ # TYPE jvm_old_size_bytes gauge
+ jvm_old_size_bytes{type="used"} 3522435544
+ jvm_old_size_bytes{type="peak_used"} 6561017832
+ jvm_old_size_bytes{type="max"} 30064771072
+ # HELP jvm_direct_buffer_pool_size_bytes jvm direct buffer pool stat
+ # TYPE jvm_direct_buffer_pool_size_bytes gauge
+ jvm_direct_buffer_pool_size_bytes{type="count"} 91
+ jvm_direct_buffer_pool_size_bytes{type="used"} 226135222
+ jvm_direct_buffer_pool_size_bytes{type="capacity"} 226135221
+ # HELP jvm_young_gc jvm young gc stat
+ # TYPE jvm_young_gc gauge
+ jvm_young_gc{type="count"} 2186
+ jvm_young_gc{type="time"} 93650
+ # HELP jvm_old_gc jvm old gc stat
+ # TYPE jvm_old_gc gauge
+ jvm_old_gc{type="count"} 21
+ jvm_old_gc{type="time"} 58268
+ # HELP jvm_thread jvm thread stat
+ # TYPE jvm_thread gauge
+ jvm_thread{type="count"} 767
+ jvm_thread{type="peak_count"} 831
+ ...
+ ```
+
+这是一个以 [Prometheus 格式](https://prometheus.io/docs/practices/naming/) 呈现的监控数据。我们以其中一个监控项为例进行说明：
+
+```
+# HELP jvm_heap_size_bytes jvm heap stat
+# TYPE jvm_heap_size_bytes gauge
+jvm_heap_size_bytes{type="max"} 41661235200
+jvm_heap_size_bytes{type="committed"} 19785285632
+jvm_heap_size_bytes{type="used"} 10113221064
+```
+
+1. "#" 开头的行为注释行。其中 HELP 为该监控项的描述说明；TYPE 表示该监控项的数据类型，示例中为 Gauge，即标量数据。还有 Counter、Histogram 等数据类型。具体可见 [Prometheus 官方文档](https://prometheus.io/docs/practices/instrumentation/#counter-vs.-gauge,-summary-vs.-histogram) 。
+2. `jvm_heap_size_bytes` 即监控项的名称（Key）；`type="max"` 即为一个名为 `type` 的 Label，值为 `max`。一个监控项可以有多个 Label。
+3. 最后的数字，如 `41661235200`，即为监控数值。
+
+## 监控架构
+
+整个监控架构如下图所示：
+
+
+
+1. 黄色部分为 Prometheus 相关组件。Prometheus Server 为 Prometheus 的主进程，目前 Prometheus 通过 Pull 的方式访问 Doris 节点的监控接口，然后将时序数据存入时序数据库 TSDB 中（TSDB 包含在 Prometheus 进程中，无需单独部署）。Prometheus 也支持通过搭建 [Push Gateway](https://github.com/prometheus/pushgateway) 的方式，允许被监控系统将监控数据通过 Push 的方式推到 Push Gateway, 再由 Prometheus Server 通过 Pull 的方式从 Push Gateway 中获取数据。
+2. [Alert Manager](https://github.com/prometheus/alertmanager) 为 Prometheus 报警组件，需单独部署（暂不提供方案，可参照官方文档自行搭建）。通过 Alert Manager，用户可以配置报警策略，接收邮件、短信等报警。
+3. 绿色部分为 Grafana 相关组件。Grafana Server 为 Grafana 的主进程。启动后，用户可以通过 Web 页面对 Grafana 进行配置，包括数据源的设置、用户设置、Dashboard 绘制等。这里也是最终用户查看监控数据的地方。
+
+
+## 开始搭建
+
+请在完成 Doris 的部署后，开始搭建监控系统。
+
+### Prometheus
+
+1. 在 [Prometheus 官网](https://prometheus.io/download/) 下载最新版本的 Prometheus。这里我们以 2.3.2-linux-amd64 版本为例。
+2. 在准备运行监控服务的机器上，解压下载后的 tar 文件。
+3. 打开配置文件 prometheus.yml。这里我们提供一个示例配置并加以说明（配置文件为 yml 格式，一定注意统一的缩进和空格）：
+
+ 这里我们使用最简单的静态文件的方式进行监控配置。Prometheus 支持多种 [服务发现](https://prometheus.io/docs/prometheus/latest/configuration/configuration/) 方式，可以动态的感知节点的加入和删除。
+
+ ```
+ # my global config
+ global:
+ scrape_interval: 15s # 全局的采集间隔，默认是 1m，这里设置为 15s
+ evaluation_interval: 15s # 全局的规则触发间隔，默认是 1m，这里设置 15s
+
+ # Alertmanager configuration
+ alerting:
+ alertmanagers:
+ - static_configs:
+ - targets:
+ # - alertmanager:9093
+
+ # A scrape configuration containing exactly one endpoint to scrape:
+ # Here it's Prometheus itself.
+ scrape_configs:
+ # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
+ - job_name: 'PALO_CLUSTER' # 每一个 Doris 集群，我们称为一个 job。这里可以给 job 取一个名字，作为 Doris 集群在监控系统中的名字。
+ metrics_path: '/metrics' # 这里指定获取监控项的 restful api。配合下面的 targets 中的 host:port，Prometheus 最终会通过 host:port/metrics_path 来采集监控项。
+ static_configs: # 这里开始分别配置 FE 和 BE 的目标地址。所有的 FE 和 BE 都分别写入各自的 group 中。
+ - targets: ['fe_host1:8030', 'fe_host2:8030', 'fe_host3:8030']
+ labels:
+ group: fe # 这里配置了 fe 的 group，该 group 中包含了 3 个 Frontends
+
+ - targets: ['be_host1:8040', 'be_host2:8040', 'be_host3:8040']
+ labels:
+ group: be # 这里配置了 be 的 group，该 group 中包含了 3 个 Backends
+
+ - job_name: 'PALO_CLUSTER_2' # 我们可以在一个 Prometheus 中监控多个 Doris 集群，这里开始另一个 Doris 集群的配置。配置同上，以下略。
+ metrics_path: '/metrics'
+ static_configs:
+ - targets: ['fe_host1:8030', 'fe_host2:8030', 'fe_host3:8030']
+ labels:
+ group: fe
+
+ - targets: ['be_host1:8040', 'be_host2:8040', 'be_host3:8040']
+ labels:
+ group: be
+
+ ```
+
+4. 启动 Prometheus
+
+ 通过以下命令启动 Prometheus：
+
+ `nohup ./prometheus --web.listen-address="0.0.0.0:8181" &`
+
+ 该命令将后台运行 Prometheus，并指定其 web 端口为 8181。启动后，即开始采集数据，并将数据存放在 data 目录中。
+
+5. 停止 Prometheus
+
+ 目前没有发现正式的进程停止方式，直接 kill -9 即可。当然也可以将 Prometheus 设为一种 service，以 service 的方式启停。
+
+6. 访问 Prometheus
+
+ Prometheus 可以通过 web 页面进行简单的访问。通过浏览器打开 8181 端口，即可访问 Prometheus 的页面。点击导航栏中，`Status` -> `Targets`，可以看到所有分组 Job 的监控主机节点。正常情况下，所有节点都应为 `UP`，表示数据采集正常。点击某一个 `Endpoint`，即可看到当前的监控数值。如果节点状态不为 UP，可以先访问 Doris 的 metrics 接口（见前文）检查是否可以访问，或查询 Prometheus 相关文档尝试解决。
+
+7. 至此，一个简单的 Prometheus 已经搭建、配置完毕。更多高级使用方式，请参阅 [官方文档](https://prometheus.io/docs/introduction/overview/)
+
+### Grafana
+
+1. 在 [Grafana 官网](https://grafana.com/grafana/download) 下载最新版本的 Grafana。这里我们以 5.2.1.linux-amd64 版本为例。
+
+2. 在准备运行监控服务的机器上，解压下载后的 tar 文件。
+
+3. 打开配置文件 conf/defaults.ini。这里我们仅列举需要改动的配置项，其余配置可使用默认。
+
+ ```
+ # Path to where grafana can store temp files, sessions, and the sqlite3 db (if that is used)
+ data = data
+
+ # Directory where grafana can store logs
+ logs = data/log
+
+ # Protocol (http, https, socket)
+ protocal = http
+
+ # The ip address to bind to, empty will bind to all interfaces
+ http_addr =
+
+ # The http port to use
+ http_port = 8182
+ ```
+
+4. 启动 Grafana
+
+ 通过以下命令启动 Grafana
+
+ `nohup ./bin/grafana-server &`
+
+ 该命令将后台运行 Grafana，访问端口为上面配置的 8182
+
+5. 停止 Grafana
+
+ 目前没有发现正式的进程停止方式，直接 kill -9 即可。当然也可以将 Grafana 设为一种 service，以 service 的方式启停。
+
+6. 访问 Grafana
+
+ 通过浏览器，打开 8182 端口，可以开始访问 Grafana 页面。默认用户名密码为 admin。
+
+7. 配置 Grafana
+
+ 初次登陆，需要根据提示设置数据源（data source）。我们这里的数据源，即上一步配置的 Prometheus。
+
+ 数据源配置的 Setting 页面说明如下：
+
+ 1. Name: 数据源的名称，自定义，比如 doris_monitor_data_source
+ 2. Type: 选择 Prometheus
+ 3. URL: 填写 Prometheus 的 web 地址，如 http://host:8181
+ 4. Access: 这里我们选择 Server 方式，即通过 Grafana 进程所在服务器，访问 Prometheus。
+ 5. 其余选项默认即可。
+ 6. 点击最下方 `Save & Test`，如果显示 `Data source is working`，即表示数据源可用。
+ 7. 确认数据源可用后，点击左边导航栏的 + 号，开始添加 Dashboard。这里我们已经准备好了 Doris 的 Dashboard 模板（本文档开头）。下载完成后，点击上方的 `New dashboard`->`Import dashboard`->`Upload .json File`，将下载的 json 文件导入。
+ 8. 导入后，可以命名 Dashboard，默认是 `Doris Overview`。同时，需要选择数据源，这里选择之前创建的 `doris_monitor_data_source`
+ 9. 点击 `Import`，即完成导入。之后，可以看到 Doris 的 Dashboard 展示。
+
+8. 至此，一个简单的 Grafana 已经搭建、配置完毕。更多高级使用方式，请参阅 [官方文档](http://docs.grafana.org/)
+
+
+## Dashboard 说明
+
+这里我们简要介绍 Doris Dashboard。Dashboard 的内容可能会随版本升级，不断变化，本文档不保证是最新的 Dashboard 说明。
+
+1. 顶栏
+
+ 
+
+ * 左上角为 Dashboard 名称。
+ * 右上角显示当前监控时间范围，可以下拉选择不同的时间范围，还可以指定定时刷新页面间隔。
+ * cluster\_name: 即 Prometheus 配置文件中的各个 job\_name，代表一个 Doris 集群。选择不同的 cluster，下方的图表将展示对应集群的监控信息。
+ * fe_master: 对应集群的 Master Frontend 节点。
+ * fe_instance: 对应集群的所有 Frontend 节点。选择不同的 Frontend，下方的图表将展示对应 Frontend 的监控信息。
+ * be_instance: 对应集群的所有 Backend 节点。选择不同的 Backend，下方的图表将展示对应 Backend 的监控信息。
+ * interval: 有些图表展示了速率相关的监控项，这里可选择以多大间隔进行采样计算速率（注：15s 间隔可能导致一些图表无法显示）。
+
+2. Row
+
+ 
+
+ Grafana 中，Row 的概念，即一组图表的集合。如上图中的 Overview、Cluster Overview 即两个不同的 Row。可以通过点击 Row，对 Row 进行折叠。当前 Dashboard 有如下 Rows（持续更新中）：
+
+ 1. Overview: 所有 Doris 集群的汇总展示。
+ 2. Cluster Overview: 选定集群的汇总展示。
+ 3. Query Statistic: 选定集群的查询相关监控。
+ 4. FE JVM: 选定 Frontend 的 JVM 监控。
+ 5. BE: 选定集群的 Backends 的汇总展示。
+ 6. BE Task: 选定集群的 Backends 任务信息的展示。
+
+3. 图表
+
+ 
+
+ 一个典型的图标分为以下几部分：
+
+ 1. 鼠标悬停左上角的 i 图标，可以查看该图表的说明。
+ 2. 点击下方的图例，可以单独查看某一监控项。再次点击，则显示所有。
+ 3. 在图表中拖拽可以选定时间范围。
+ 4. 标题的 [] 中显示选定的集群名称。
+ 5. 一些数值对应左边的Y轴，一些对应右边的，可以通过图例末尾的 `-right` 区分。
+ 6. 点击图表名称->`Edit`，可以对图表进行编辑。
+
+## Dashboard 更新
+
+1. 点击 Grafana 左边栏的 `+`，点击 `Dashboard`。
+2. 点击左上角的 `New dashboard`，在点击右侧出现的 `Import dashboard`。
+3. 点击 `Upload .json File`，选择最新的模板文件。
+4. 选择数据源
+5. 点击 `Import(Overwrite)`，完成模板更新。
diff --git a/new-docs/zh-CN/admin-manual/maint-monitor/monitor-metrics/be-metrics.md b/new-docs/zh-CN/admin-manual/maint-monitor/monitor-metrics/be-metrics.md
index 1f4fa9a384..db555efbe7 100644
--- a/new-docs/zh-CN/admin-manual/maint-monitor/monitor-metrics/be-metrics.md
+++ b/new-docs/zh-CN/admin-manual/maint-monitor/monitor-metrics/be-metrics.md
@@ -24,5 +24,61 @@ specific language governing permissions and limitations
under the License.
-->
+<!-- Please sort the metrics alphabetically -->
+
# BE 监控项
+该文档主要介绍 BE 的相关监控项。
+
+## 查看监控项
+
+BE 的监控项可以通过以下方式访问：
+
+`http://be_host:be_webserver_port/metrics`
+
+默认显示为 [Prometheus](https://prometheus.io/) 格式。
+
+通过以下接口可以获取 Json 格式的监控项：
+
+`http://be_host:be_webserver_port/metrics?type=json`
+
+## 监控项列表
+
+### `doris_be_snmp{name="tcp_in_errs"}`
+
+该监控项为 `/proc/net/snmp` 中的 `Tcp: InErrs` 字段值。表示当前接收到的错误的 TCP 包的数量。
+
+结合采样周期可以计算发生率。
+
+通常用于排查网络问题。
+
+### `doris_be_snmp{name="tcp_retrans_segs"}`
+
+该监控项为 `/proc/net/snmp` 中的 `Tcp: RetransSegs` 字段值。表示当前重传的 TCP 包的数量。
+
+结合采样周期可以计算发生率。
+
+通常用于排查网络问题。
+
+### `doris_be_snmp{name="tcp_in_segs"}`
+
+该监控项为 `/proc/net/snmp` 中的 `Tcp: InSegs` 字段值。表示当前接收到的所有 TCP 包的数量。
+
+通过 `(NEW_tcp_in_errs - OLD_tcp_in_errs) / (NEW_tcp_in_segs - OLD_tcp_in_segs)` 可以计算接收到的 TCP 错误包率。
+
+通常用于排查网络问题。
+
+### `doris_be_snmp{name="tcp_out_segs"}`
+
+该监控项为 `/proc/net/snmp` 中的 `Tcp: OutSegs` 字段值。表示当前发送的所有带 RST 标记的 TCP 包的数量。
+
+通过 `(NEW_tcp_tcp_retrans_segs - OLD_tcp_retrans_segs) / (NEW_tcp_out_segs - OLD_tcp_out_segs)` 可以计算 TCP 重传率。
+
+通常用于排查网络问题。
+
+### `doris_be_compaction_mem_current_consumption`
+
+该监控项为Compaction使用的MemPool总和（所有Compaction线程）。通过该值，可以迅速判断Compaction是否占用过多内存，引起高内存占用
+甚至OOM等问题。
+
+通常用于排查内存使用问题。
\ No newline at end of file
diff --git a/new-docs/zh-CN/admin-manual/maint-monitor/monitor-metrics/fe-metrics.md b/new-docs/zh-CN/admin-manual/maint-monitor/monitor-metrics/fe-metrics.md
index 019353f081..2277296438 100644
--- a/new-docs/zh-CN/admin-manual/maint-monitor/monitor-metrics/fe-metrics.md
+++ b/new-docs/zh-CN/admin-manual/maint-monitor/monitor-metrics/fe-metrics.md
@@ -24,5 +24,132 @@ specific language governing permissions and limitations
under the License.
-->
+<!-- Please sort the metrics alphabetically -->
+
# FE 监控项
+该文档主要介绍 FE 的相关监控项。
+
+## 查看监控项
+
+FE 的监控项可以通过以下方式访问：
+
+`http://fe_host:fe_http_port/metrics`
+
+默认显示为 [Prometheus](https://prometheus.io/) 格式。
+
+通过以下接口可以获取 Json 格式的监控项：
+
+`http://fe_host:fe_http_port/metrics?type=json`
+
+## 监控项列表
+
+### `doris_fe_snmp{name="tcp_in_errs"}`
+
+该监控项为 `/proc/net/snmp` 中的 `Tcp: InErrs` 字段值。表示当前接收到的错误的 TCP 包的数量。
+
+结合采样周期可以计算发生率。
+
+通常用于排查网络问题。
+
+### `doris_fe_snmp{name="tcp_retrans_segs"}`
+
+该监控项为 `/proc/net/snmp` 中的 `Tcp: RetransSegs` 字段值。表示当前重传的 TCP 包的数量。
+
+结合采样周期可以计算发生率。
+
+通常用于排查网络问题。
+
+### `doris_fe_snmp{name="tcp_in_segs"}`
+
+该监控项为 `/proc/net/snmp` 中的 `Tcp: InSegs` 字段值。表示当前接收到的所有 TCP 包的数量。
+
+通过 `(NEW_tcp_in_errs - OLD_tcp_in_errs) / (NEW_tcp_in_segs - OLD_tcp_in_segs)` 可以计算接收到的 TCP 错误包率。
+
+通常用于排查网络问题。
+
+### `doris_fe_snmp{name="tcp_out_segs"}`
+
+该监控项为 `/proc/net/snmp` 中的 `Tcp: OutSegs` 字段值。表示当前发送的所有带 RST 标记的 TCP 包的数量。
+
+通过 `(NEW_tcp_tcp_retrans_segs - OLD_tcp_retrans_segs) / (NEW_tcp_out_segs - OLD_tcp_out_segs)` 可以计算 TCP 重传率。
+
+通常用于排查网络问题。
+
+### `doris_fe_meminfo{name="memory_total"}`
+
+该监控项为 `/proc/meminfo` 中的 `MemTotal` 字段值。表示所有可用的内存大小，总的物理内存减去预留空间和内核大小。
+
+通常用于排查内存问题。
+
+### `doris_fe_meminfo{name="memory_free"}`
+
+该监控项为 `/proc/meminfo` 中的 `MemFree` 字段值。表示系统尚未使用的内存。。
+
+通常用于排查内存问题。
+
+### `doris_fe_meminfo{name="memory_available"}`
+
+该监控项为 `/proc/meminfo` 中的 `MemAvailable` 字段值。真正的系统可用内存，系统中有些内存虽然已被使用但是可以回收的，所以这部分可回收的内存加上MemFree才是系统可用的内存
+
+通常用于排查内存问题。
+
+### `doris_fe_meminfo{name="buffers"}`
+
+该监控项为 `/proc/meminfo` 中的 `Buffers` 字段值。表示用来给块设备做缓存的内存(文件系统的metadata、pages)。
+
+通常用于排查内存问题。
+
+### `doris_fe_meminfo{name="cached"}`
+
+该监控项为 `/proc/meminfo` 中的 `Cached` 字段值。表示分配给文件缓冲区的内存。
+
+通常用于排查内存问题。
+
+### `jvm_thread{type="count"}`
+
+该监控项表示FE节点当前JVM总的线程数量，包含daemon线程和非daemon线程。
+
+通常用于排查FE节点的JVM线程运行问题。
+
+### `jvm_thread{type="peak_count"}`
+
+该监控项表示FE节点从JVM启动以来的最大峰值线程数量。
+
+通常用于排查FE节点的JVM线程运行问题。
+
+### `jvm_thread{type="new_count"}`
+
+该监控项表示FE节点JVM中处于NEW状态的线程数量。
+
+通常用于排查FE节点的JVM线程运行问题。
+
+### `jvm_thread{type="runnable_count"}`
+
+该监控项表示FE节点JVM中处于RUNNABLE状态的线程数量。
+
+通常用于排查FE节点的JVM线程运行问题。
+
+### `jvm_thread{type="blocked_count"}`
+
+该监控项表示FE节点JVM中处于BLOCKED状态的线程数量。
+
+通常用于排查FE节点的JVM线程运行问题。
+
+### `jvm_thread{type="waiting_count"}`
+
+该监控项表示FE节点JVM中处于WAITING状态的线程数量。
+
+通常用于排查FE节点的JVM线程运行问题。
+
+### `jvm_thread{type="timed_waiting_count"}`
+
+该监控项表示FE节点JVM中处于TIMED_WAITING状态的线程数量。
+
+通常用于排查FE节点的JVM线程运行问题。
+
+### `jvm_thread{type="terminated_count"}`
+
+该监控项表示FE节点JVM中处于TERMINATED状态的线程数量。
+
+通常用于排查FE节点的JVM线程运行问题。
\ No newline at end of file
diff --git a/new-docs/zh-CN/admin-manual/maint-monitor/tablet-meta-tool.md b/new-docs/zh-CN/admin-manual/maint-monitor/tablet-meta-tool.md
index 889d83326c..9ebbf2de62 100644
--- a/new-docs/zh-CN/admin-manual/maint-monitor/tablet-meta-tool.md
+++ b/new-docs/zh-CN/admin-manual/maint-monitor/tablet-meta-tool.md
@@ -24,4 +24,123 @@ specific language governing permissions and limitations
under the License.
-->
-# Tablet 元数据管理工具
\ No newline at end of file
+# Tablet 元数据管理工具
+
+## 背景
+
+在最新版本的代码中，我们在 BE 端引入了 RocksDB，用于存储 tablet 的元信息，以解决之前通过 header 文件的方式存储元信息，带来的各种功能和性能方面的问题。当前每一个数据目录（root\_path），都会有一个对应的 RocksDB 实例，其中以 key-value 的方式，存放对应 root\_path 上的所有 tablet 的元数据。
+
+为了方便进行这些元数据的维护，我们提供了在线的 http 接口方式和离线的 meta\_tool 工具以完成相关的管理操作。
+
+其中 http 接口仅用于在线的查看 tablet 的元数据，可以在 BE 进程运行的状态下使用。
+
+而 meta\_tool 工具则仅用于离线的各类元数据管理操作，必须先停止BE进程后，才可使用。
+
+meta\_tool 工具存放在 BE 的 lib/ 目录下。
+
+## 操作
+
+### 查看 Tablet Meta
+
+查看 Tablet Meta 信息可以分为在线方法和离线方法
+
+#### 在线
+
+访问 BE 的 http 接口，获取对应的 Tablet Meta 信息：
+
+api：
+
+`http://{host}:{port}/api/meta/header/{tablet_id}`
+
+
+> host: BE 的 hostname
+>
+> port: BE 的 http 端口
+>
+> tablet_id: tablet id
+
+举例：
+
+`http://be_host:8040/api/meta/header/14156`
+
+最终查询成功的话，会将 Tablet Meta 以 json 形式返回。
+
+#### 离线
+
+基于 meta\_tool 工具获取某个盘上的 Tablet Meta。
+
+命令：
+
+```
+./lib/meta_tool --root_path=/path/to/root_path --operation=get_meta --tablet_id=xxx --schema_hash=xxx
+```
+
+> root_path: 在 be.conf 中配置的对应的 root_path 路径。
+
+结果也是按照 json 的格式展现 Tablet Meta。
+
+### 加载 header
+
+加载 header 的功能是为了完成实现 tablet 人工迁移而提供的。该功能是基于 json 格式的 Tablet Meta 实现的，所以如果涉及 shard 字段、version 信息的更改，可以直接在 Tablet Meta 的 json 内容中更改。然后使用以下的命令进行加载。
+
+命令：
+
+```
+./lib/meta_tool --operation=load_meta --root_path=/path/to/root_path --json_header_path=path
+```
+
+### 删除 header
+
+为了实现从某个 be 的某个盘中删除某个 tablet 元数据的功能。可以单独删除一个 tablet 的元数据，或者批量删除一组 tablet 的元数据。
+
+删除单个tablet元数据：
+
+```
+./lib/meta_tool --operation=delete_meta --root_path=/path/to/root_path --tablet_id=xxx --schema_hash=xxx
+```
+
+删除一组tablet元数据：
+
+```
+./lib/meta_tool --operation=batch_delete_meta --tablet_file=/path/to/tablet_file.txt
+```
+
+其中 `tablet_file.txt` 中的每一行表示一个 tablet 的信息。格式为：
+
+`root_path,tablet_id,schema_hash`
+
+每一行各个列用逗号分隔。
+
+`tablet_file` 文件示例：
+
+```
+/output/be/data/,14217,352781111
+/output/be/data/,14219,352781111
+/output/be/data/,14223,352781111
+/output/be/data/,14227,352781111
+/output/be/data/,14233,352781111
+/output/be/data/,14239,352781111
+```
+
+批量删除会跳过 `tablet_file` 中 tablet 信息格式不正确的行。并在执行完成后，显示成功删除的数量和错误数量。
+
+### 展示 pb 格式的 TabletMeta
+
+这个命令是为了查看旧的基于文件的管理的PB格式的 Tablet Meta，以 json 的格式展示 Tablet Meta。
+
+命令：
+
+```
+./lib/meta_tool --operation=show_meta --root_path=/path/to/root_path --pb_header_path=path
+```
+
+### 展示 pb 格式的 Segment meta
+
+这个命令是为了查看SegmentV2 的segment meta信息，以json 形式展示出来
+
+命令：
+
+```
+./meta_tool --operation=show_segment_footer --file=/path/to/segment/file
+
+
diff --git a/new-docs/zh-CN/admin-manual/maint-monitor/tablet-repair-and-balance.md b/new-docs/zh-CN/admin-manual/maint-monitor/tablet-repair-and-balance.md
index 11f8276bf8..340ed39b28 100644
--- a/new-docs/zh-CN/admin-manual/maint-monitor/tablet-repair-and-balance.md
+++ b/new-docs/zh-CN/admin-manual/maint-monitor/tablet-repair-and-balance.md
@@ -24,4 +24,752 @@ specific language governing permissions and limitations
under the License.
-->
-# 数据副本管理
\ No newline at end of file
+# 数据副本管理
+
+从 0.9.0 版本开始，Doris 引入了优化后的副本管理策略，同时支持了更为丰富的副本状态查看工具。本文档主要介绍 Doris 数据副本均衡、修复方面的调度策略，以及副本管理的运维方法。帮助用户更方便的掌握和管理集群中的副本状态。
+
+> Colocation 属性的表的副本修复和均衡可以参阅[这里](../../advanced/colocation-join.html)
+
+## 名词解释
+
+1. Tablet：Doris 表的逻辑分片，一个表有多个分片。
+2. Replica：分片的副本，默认一个分片有3个副本。
+3. Healthy Replica：健康副本，副本所在 Backend 存活，且副本的版本完整。
+4. TabletChecker（TC）：是一个常驻的后台线程，用于定期扫描所有的 Tablet，检查这些 Tablet 的状态，并根据检查结果，决定是否将 tablet 发送给 TabletScheduler。
+5. TabletScheduler（TS）：是一个常驻的后台线程，用于处理由 TabletChecker 发来的需要修复的 Tablet。同时也会进行集群副本均衡的工作。
+6. TabletSchedCtx（TSC）：是一个 tablet 的封装。当 TC 选择一个 tablet 后，会将其封装为一个 TSC，发送给 TS。
+7. Storage Medium：存储介质。Doris 支持对分区粒度指定不同的存储介质，包括 SSD 和 HDD。副本调度策略也是针对不同的存储介质分别调度的。
+
+```
+
+ +--------+ +-----------+
+ | Meta | | Backends |
+ +---^----+ +------^----+
+ | | | 3. Send clone tasks
+ 1. Check tablets | | |
+ +--------v------+ +-----------------+
+ | TabletChecker +--------> TabletScheduler |
+ +---------------+ +-----------------+
+ 2. Waiting to be scheduled
+
+
+```
+
+上图是一个简化的工作流程。
+
+
+## 副本状态
+
+一个 Tablet 的多个副本，可能因为某些情况导致状态不一致。Doris 会尝试自动修复这些状态不一致的副本，让集群尽快从错误状态中恢复。
+
+**一个 Replica 的健康状态有以下几种：**
+
+1. BAD
+
+ 即副本损坏。包括但不限于磁盘故障、BUG等引起的副本不可恢复的损毁状态。
+
+2. VERSION\_MISSING
+
+ 版本缺失。Doris 中每一批次导入都对应一个数据版本。而一个副本的数据由多个连续的版本组成。而由于导入错误、延迟等原因，可能导致某些副本的数据版本不完整。
+
+3. HEALTHY
+
+ 健康副本。即数据正常的副本，并且副本所在的 BE 节点状态正常（心跳正常且不处于下线过程中）
+
+
+**一个 Tablet 的健康状态由其所有副本的状态决定，有以下几种：**
+
+1. REPLICA\_MISSING
+
+ 副本缺失。即存活副本数小于期望副本数。
+
+2. VERSION\_INCOMPLETE
+
+ 存活副本数大于等于期望副本数，但其中健康副本数小于期望副本数。
+
+3. REPLICA\_RELOCATING
+
+ 拥有等于 replication num 的版本完整的存活副本数，但是部分副本所在的 BE 节点处于 unavailable 状态（比如 decommission 中）
+
+4. REPLICA\_MISSING\_IN\_CLUSTER
+
+ 当使用多 cluster 方式时，健康副本数大于等于期望副本数，但在对应 cluster 内的副本数小于期望副本数。
+
+5. REDUNDANT
+
+ 副本冗余。健康副本都在对应 cluster 内，但数量大于期望副本数。或者有多余的 unavailable 副本。
+
+6. FORCE\_REDUNDANT
+
+ 这是一个特殊状态。只会出现在当期望副本数大于等于可用节点数时，并且 Tablet 处于副本缺失状态时出现。这种情况下，需要先删除一个副本，以保证有可用节点用于创建新副本。
+
+7. COLOCATE\_MISMATCH
+
+ 针对 Colocation 属性的表的分片状态。表示分片副本与 Colocation Group 的指定的分布不一致。
+
+8. COLOCATE\_REDUNDANT
+
+ 针对 Colocation 属性的表的分片状态。表示 Colocation 表的分片副本冗余。
+
+9. HEALTHY
+
+ 健康分片，即条件[1-8]都不满足。
+
+## 副本修复
+
+TabletChecker 作为常驻的后台进程，会定期检查所有分片的状态。对于非健康状态的分片，将会交给 TabletScheduler 进行调度和修复。修复的实际操作，都由 BE 上的 clone 任务完成。FE 只负责生成这些 clone 任务。
+
+> 注1：副本修复的主要思想是先通过创建或补齐使得分片的副本数达到期望值，然后再删除多余的副本。
+>
+> 注2：一个 clone 任务就是完成从一个指定远端 BE 拷贝指定数据到指定目的端 BE 的过程。
+
+针对不同的状态，我们采用不同的修复方式：
+
+1. REPLICA\_MISSING/REPLICA\_RELOCATING
+
+ 选择一个低负载的，可用的 BE 节点作为目的端。选择一个健康副本作为源端。clone 任务会从源端拷贝一个完整的副本到目的端。对于副本补齐，我们会直接选择一个可用的 BE 节点，而不考虑存储介质。
+
+2. VERSION\_INCOMPLETE
+
+ 选择一个相对完整的副本作为目的端。选择一个健康副本作为源端。clone 任务会从源端尝试拷贝缺失的版本到目的端的副本。
+
+3. REPLICA\_MISSING\_IN\_CLUSTER
+
+ 这种状态处理方式和 REPLICA\_MISSING 相同。
+
+4. REDUNDANT
+
+ 通常经过副本修复后，分片会有冗余的副本。我们选择一个冗余副本将其删除。冗余副本的选择遵从以下优先级：
+ 1. 副本所在 BE 已经下线
+ 2. 副本已损坏
+ 3. 副本所在 BE 失联或在下线中
+ 4. 副本处于 CLONE 状态（该状态是 clone 任务执行过程中的一个中间状态）
+ 5. 副本有版本缺失
+ 6. 副本所在 cluster 不正确
+ 7. 副本所在 BE 节点负载高
+
+5. FORCE\_REDUNDANT
+
+ 不同于 REDUNDANT，因为此时虽然 Tablet 有副本缺失，但是因为已经没有额外的可用节点用于创建新的副本了。所以此时必须先删除一个副本，以腾出一个可用节点用于创建新的副本。
+ 删除副本的顺序同 REDUNDANT。
+
+6. COLOCATE\_MISMATCH
+
+ 从 Colocation Group 中指定的副本分布 BE 节点中选择一个作为目的节点进行副本补齐。
+
+7. COLOCATE\_REDUNDANT
+
+ 删除一个非 Colocation Group 中指定的副本分布 BE 节点上的副本。
+
+Doris 在选择副本节点时，不会将同一个 Tablet 的副本部署在同一个 host 的不同 BE 上。保证了即使同一个 host 上的所有 BE 都挂掉，也不会造成全部副本丢失。
+
+### 调度优先级
+
+TabletScheduler 里等待被调度的分片会根据状态不同，赋予不同的优先级。优先级高的分片将会被优先调度。目前有以下几种优先级。
+
+1. VERY\_HIGH
+
+ * REDUNDANT。对于有副本冗余的分片，我们优先处理。虽然逻辑上来讲，副本冗余的紧急程度最低，但是因为这种情况处理起来最快且可以快速释放资源（比如磁盘空间等），所以我们优先处理。
+ * FORCE\_REDUNDANT。同上。
+
+2. HIGH
+
+ * REPLICA\_MISSING 且多数副本缺失（比如3副本丢失了2个）
+ * VERSION\_INCOMPLETE 且多数副本的版本缺失
+ * COLOCATE\_MISMATCH 我们希望 Colocation 表相关的分片能够尽快修复完成。
+ * COLOCATE\_REDUNDANT
+
+3. NORMAL
+
+ * REPLICA\_MISSING 但多数存活（比如3副本丢失了1个）
+ * VERSION\_INCOMPLETE 但多数副本的版本完整
+ * REPLICA\_RELOCATING 且多数副本需要 relocate（比如3副本有2个）
+
+4. LOW
+
+ * REPLICA\_MISSING\_IN\_CLUSTER
+ * REPLICA\_RELOCATING 但多数副本 stable
+
+### 手动优先级
+
+系统会自动判断调度优先级。但是有些时候，用户希望某些表或分区的分片能够更快的被修复。因此我们提供一个命令，用户可以指定某个表或分区的分片被优先修复：
+
+`ADMIN REPAIR TABLE tbl [PARTITION (p1, p2, ...)];`
+
+这个命令，告诉 TC，在扫描 Tablet 时，对需要优先修复的表或分区中的有问题的 Tablet，给予 VERY\_HIGH 的优先级。
+
+> 注：这个命令只是一个 hint，并不能保证一定能修复成功，并且优先级也会随 TS 的调度而发生变化。并且当 Master FE 切换或重启后，这些信息都会丢失。
+
+可以通过以下命令取消优先级：
+
+`ADMIN CANCEL REPAIR TABLE tbl [PARTITION (p1, p2, ...)];`
+
+### 优先级调度
+
+优先级保证了损坏严重的分片能够优先被修复，提高系统可用性。但是如果高优先级的修复任务一直失败，则会导致低优先级的任务一直得不到调度。因此，我们会根据任务的运行状态，动态的调整任务的优先级，保证所有任务都有机会被调度到。
+
+* 连续5次调度失败（如无法获取资源，无法找到合适的源端或目的端等），则优先级会被下调。
+* 持续 30 分钟未被调度，则上调优先级。
+* 同一 tablet 任务的优先级至少间隔 5 分钟才会被调整一次。
+
+同时为了保证初始优先级的权重，我们规定，初始优先级为 VERY\_HIGH 的，最低被下调到 NORMAL。而初始优先级为 LOW 的，最多被上调为 HIGH。这里的优先级调整，也会调整用户手动设置的优先级。
+
+## 副本均衡
+
+Doris 会自动进行集群内的副本均衡。目前支持两种均衡策略，负载/分区。负载均衡适合需要兼顾节点磁盘使用率和节点副本数量的场景；而分区均衡会使每个分区的副本都均匀分布在各个节点，避免热点，适合对分区读写要求比较高的场景。但是，分区均衡不考虑磁盘使用率，使用分区均衡时需要注意磁盘的使用情况。 策略只能在fe启动前配置[tablet_rebalancer_type](../config/fe-config.html#配置项列表 ) ，不支持运行时切换。
+
+### 负载均衡
+
+负载均衡的主要思想是，对某些分片，先在低负载的节点上创建一个副本，然后再删除这些分片在高负载节点上的副本。同时，因为不同存储介质的存在，在同一个集群内的不同 BE 节点上，可能存在一种或两种存储介质。我们要求存储介质为 A 的分片在均衡后，尽量依然存储在存储介质 A 中。所以我们根据存储介质，对集群的 BE 节点进行划分。然后针对不同的存储介质的 BE 节点集合，进行负载均衡调度。
+
+同样，副本均衡会保证不会将同一个 Tablet 的副本部署在同一个 host 的 BE 上。
+
+#### BE 节点负载
+
+我们用 ClusterLoadStatistics（CLS）表示一个 cluster 中各个 Backend 的负载均衡情况。TabletScheduler 根据这个统计值，来触发集群均衡。我们当前通过 **磁盘使用率** 和 **副本数量** 两个指标，为每个BE计算一个 loadScore，作为 BE 的负载分数。分数越高，表示该 BE 的负载越重。
+
+磁盘使用率和副本数量各有一个权重系数，分别为 **capacityCoefficient** 和 **replicaNumCoefficient**，其 **和衡为1**。其中 capacityCoefficient 会根据实际磁盘使用率动态调整。当一个 BE 的总体磁盘使用率在 50% 以下，则 capacityCoefficient 值为 0.5，如果磁盘使用率在 75%（可通过 FE 配置项 `capacity_used_percent_high_water` 配置）以上，则值为 1。如果使用率介于 50% ~ 75% 之间，则该权重系数平滑增加，公式为：
+
+`capacityCoefficient= 2 * 磁盘使用率 - 0.5`
+
+该权重系数保证当磁盘使用率过高时，该 Backend 的负载分数会更高，以保证尽快降低这个 BE 的负载。
+
+TabletScheduler 会每隔 20s 更新一次 CLS。
+
+### 分区均衡
+
+分区均衡的主要思想是，将每个分区的在各个 Backend 上的 replica 数量差（即 partition skew），减少到最小。因此只考虑副本个数，不考虑磁盘使用率。
+为了尽量少的迁移次数，分区均衡使用二维贪心的策略，优先均衡partition skew最大的分区，均衡分区时会尽量选择，可以使整个 cluster 的在各个 Backend 上的 replica 数量差（即 cluster skew/total skew）减少的方向。
+
+#### skew 统计
+
+skew 统计信息由`ClusterBalanceInfo`表示，其中，`partitionInfoBySkew`以 partition skew 为key排序，便于找到max partition skew；`beByTotalReplicaCount`则是以 Backend 上的所有 replica 个数为key排序。`ClusterBalanceInfo`同样保持在CLS中, 同样 20s 更新一次。
+
+max partition skew 的分区可能有多个，采用随机的方式选择一个分区计算。
+
+### 均衡策略
+
+TabletScheduler 在每轮调度时，都会通过 LoadBalancer 来选择一定数目的健康分片作为 balance 的候选分片。在下一次调度时，会尝试根据这些候选分片，进行均衡调度。
+
+## 资源控制
+
+无论是副本修复还是均衡，都是通过副本在各个 BE 之间拷贝完成的。如果同一台 BE 同一时间执行过多的任务，则会带来不小的 IO 压力。因此，Doris 在调度时控制了每个节点上能够执行的任务数目。最小的资源控制单位是磁盘（即在 be.conf 中指定的一个数据路径）。我们默认为每块磁盘配置两个 slot 用于副本修复。一个 clone 任务会占用源端和目的端各一个 slot。如果 slot 数目为零，则不会再对这块磁盘分配任务。该 slot 个数可以通过 FE 的 `schedule_slot_num_per_path` 参数配置。
+
+另外，我们默认为每块磁盘提供 2 个单独的 slot 用于均衡任务。目的是防止高负载的节点因为 slot 被修复任务占用，而无法通过均衡释放空间。
+
+## 副本状态查看
+
+副本状态查看主要是查看副本的状态，以及副本修复和均衡任务的运行状态。这些状态大部分都**仅存在于** Master FE 节点中。因此，以下命令需直连到 Master FE 执行。
+
+### 副本状态
+
+1. 全局状态检查
+
+ 通过 `SHOW PROC '/statistic';` 命令可以查看整个集群的副本状态。
+
+ ```
+ +----------+-----------------------------+----------+--------------+----------+-----------+------------+--------------------+-----------------------+
+ | DbId | DbName | TableNum | PartitionNum | IndexNum | TabletNum | ReplicaNum | UnhealthyTabletNum | InconsistentTabletNum |
+ +----------+-----------------------------+----------+--------------+----------+-----------+------------+--------------------+-----------------------+
+ | 35153636 | default_cluster:DF_Newrisk | 3 | 3 | 3 | 96 | 288 | 0 | 0 |
+ | 48297972 | default_cluster:PaperData | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+ | 5909381 | default_cluster:UM_TEST | 7 | 7 | 10 | 320 | 960 | 1 | 0 |
+ | Total | 240 | 10 | 10 | 13 | 416 | 1248 | 1 | 0 |
+ +----------+-----------------------------+----------+--------------+----------+-----------+------------+--------------------+-----------------------+
+ ```
+
+ 其中 `UnhealthyTabletNum` 列显示了对应的 Database 中，有多少 Tablet 处于非健康状态。`InconsistentTabletNum` 列显示了对应的 Database 中，有多少 Tablet 处于副本不一致的状态。最后一行 `Total` 行对整个集群进行了统计。正常情况下 `UnhealthyTabletNum` 和 `InconsistentTabletNum` 应为0。如果不为零，可以进一步查看具体有哪些 Tablet。如上图中，UM_TEST 数据库有 1 个 Tablet 状态不健康，则可以使用以下命令查看具体是哪一个 Tablet。
+
+ `SHOW PROC '/statistic/5909381';`
+
+ 其中 `5909381` 为对应的 DbId。
+
+ ```
+ +------------------+---------------------+
+ | UnhealthyTablets | InconsistentTablets |
+ +------------------+---------------------+
+ | [40467980] | [] |
+ +------------------+---------------------+
+ ```
+
+ 上图会显示具体的不健康的 Tablet ID（40467980）。后面我们会介绍如何查看一个具体的 Tablet 的各个副本的状态。
+
+2. 表（分区）级别状态检查
+
+ 用户可以通过以下命令查看指定表或分区的副本状态，并可以通过 WHERE 语句对状态进行过滤。如查看表 tbl1 中，分区 p1 和 p2 上状态为 OK 的副本：
+
+ `ADMIN SHOW REPLICA STATUS FROM tbl1 PARTITION (p1, p2) WHERE STATUS = "OK";`
+
+ ```
+ +----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
+ | TabletId | ReplicaId | BackendId | Version | LastFailedVersion | LastSuccessVersion | CommittedVersion | SchemaHash | VersionNum | IsBad | State | Status |
+ +----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
+ | 29502429 | 29502432 | 10006 | 2 | -1 | 2 | 1 | -1 | 2 | false | NORMAL | OK |
+ | 29502429 | 36885996 | 10002 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
+ | 29502429 | 48100551 | 10007 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
+ | 29502433 | 29502434 | 10001 | 2 | -1 | 2 | 1 | -1 | 2 | false | NORMAL | OK |
+ | 29502433 | 44900737 | 10004 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
+ | 29502433 | 48369135 | 10006 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
+ +----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
+ ```
+
+ 这里会展示所有副本的状态。其中 `IsBad` 列为 `true` 则表示副本已经损坏。而 `Status` 列则会显示另外的其他状态。具体的状态说明，可以通过 `HELP ADMIN SHOW REPLICA STATUS;` 查看帮助。
+
+ `ADMIN SHOW REPLICA STATUS` 命令主要用于查看副本的健康状态。用户还可以通过以下命令查看指定表中副本的一些额外信息：
+
+ `SHOW TABLETS FROM tbl1;`
+
+ ```
+ +----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
+ | TabletId | ReplicaId | BackendId | SchemaHash | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | DataSize | RowCount | State | LstConsistencyCheckTime | CheckVersion | CheckVersionHash | VersionCount | PathHash | MetaUrl | CompactionStatus |
+ +----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
+ | 29502429 | 29502432 | 10006 | 1421156361 | 2 | 0 | 2 | 0 | -1 | 0 | N/A | 784 | 0 | NORMAL | N/A | -1 | -1 | 2 | -5822326203532286804 | url | url |
+ | 29502429 | 36885996 | 10002 | 1421156361 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | 784 | 0 | NORMAL | N/A | -1 | -1 | 2 | -1441285706148429853 | url | url |
+ | 29502429 | 48100551 | 10007 | 1421156361 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | 784 | 0 | NORMAL | N/A | -1 | -1 | 2 | -4784691547051455525 | url | url |
+ +----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
+ ```
+
+ 上图展示了包括副本大小、行数、版本数量、所在数据路径等一些额外的信息。
+
+ > 注：这里显示的 `State` 列的内容不代表副本的健康状态，而是副本处于某种任务下的状态，比如 CLONE、SCHEMA\_CHANGE、ROLLUP 等。
+
+ 此外，用户也可以通过以下命令，查看指定表或分区的副本分布情况，来检查副本分布是否均匀。
+
+ `ADMIN SHOW REPLICA DISTRIBUTION FROM tbl1;`
+
+ ```
+ +-----------+------------+-------+---------+
+ | BackendId | ReplicaNum | Graph | Percent |
+ +-----------+------------+-------+---------+
+ | 10000 | 7 | | 7.29 % |
+ | 10001 | 9 | | 9.38 % |
+ | 10002 | 7 | | 7.29 % |
+ | 10003 | 7 | | 7.29 % |
+ | 10004 | 9 | | 9.38 % |
+ | 10005 | 11 | > | 11.46 % |
+ | 10006 | 18 | > | 18.75 % |
+ | 10007 | 15 | > | 15.62 % |
+ | 10008 | 13 | > | 13.54 % |
+ +-----------+------------+-------+---------+
+ ```
+
+ 这里分别展示了表 tbl1 的副本在各个 BE 节点上的个数、百分比，以及一个简单的图形化显示。
+
+4. Tablet 级别状态检查
+
+ 当我们要定位到某个具体的 Tablet 时，可以使用如下命令来查看一个具体的 Tablet 的状态。如查看 ID 为 29502553 的 tablet：
+
+ `SHOW TABLET 29502553;`
+
+ ```
+ +------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
+ | DbName | TableName | PartitionName | IndexName | DbId | TableId | PartitionId | IndexId | IsSync | DetailCmd |
+ +------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
+ | default_cluster:test | test | test | test | 29502391 | 29502428 | 29502427 | 29502428 | true | SHOW PROC '/dbs/29502391/29502428/partitions/29502427/29502428/29502553'; |
+ +------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
+ ```
+
+ 上图显示了这个 tablet 所对应的数据库、表、分区、上卷表等信息。用户可以复制 `DetailCmd` 命令中的命令继续执行：
+
+ `SHOW PROC '/dbs/29502391/29502428/partitions/29502427/29502428/29502553';`
+
+ ```
+ +-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
+ | ReplicaId | BackendId | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | SchemaHash | DataSize | RowCount | State | IsBad | VersionCount | PathHash | MetaUrl | CompactionStatus |
+ +-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
+ | 43734060 | 10004 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | -8566523878520798656 | url | url |
+ | 29502555 | 10002 | 2 | 0 | 2 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | 1885826196444191611 | url | url |
+ | 39279319 | 10007 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | 1656508631294397870 | url | url |
+ +-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
+ ```
+
+ 上图显示了对应 Tablet 的所有副本情况。这里显示的内容和 `SHOW TABLET FROM tbl1;` 的内容相同。但这里可以清楚的知道，一个具体的 Tablet 的所有副本的状态。
+
+### 副本调度任务
+
+1. 查看等待被调度的任务
+
+ `SHOW PROC '/cluster_balance/pending_tablets';`
+
+ ```
+ +----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
+ | TabletId | Type | Status | State | OrigPrio | DynmPrio | SrcBe | SrcPath | DestBe | DestPath | Timeout | Create | LstSched | LstVisit | Finished | Rate | FailedSched | FailedRunning | LstAdjPrio | VisibleVer | VisibleVerHash | CmtVer | CmtVerHash | ErrMsg |
+ +----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
+ | 4203036 | REPAIR | REPLICA_MISSING | PENDING | HIGH | LOW | -1 | -1 | -1 | -1 | 0 | 2019-02-21 15:00:20 | 2019-02-24 11:18:41 | 2019-02-24 11:18:41 | N/A | N/A | 2 | 0 | 2019-02-21 15:00:43 | 1 | 0 | 2 | 0 | unable to find source replica |
+ +----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
+ ```
+
+ 各列的具体含义如下：
+
+ * TabletId：等待调度的 Tablet 的 ID。一个调度任务只针对一个 Tablet
+ * Type：任务类型，可以是 REPAIR（修复） 或 BALANCE（均衡）
+ * Status：该 Tablet 当前的状态，如 REPLICA\_MISSING（副本缺失）
+ * State：该调度任务的状态，可能为 PENDING/RUNNING/FINISHED/CANCELLED/TIMEOUT/UNEXPECTED
+ * OrigPrio：初始的优先级
+ * DynmPrio：当前动态调整后的优先级
+ * SrcBe：源端 BE 节点的 ID
+ * SrcPath：源端 BE 节点的路径的 hash 值
+ * DestBe：目的端 BE 节点的 ID
+ * DestPath：目的端 BE 节点的路径的 hash 值
+ * Timeout：当任务被调度成功后，这里会显示任务的超时时间，单位秒
+ * Create：任务被创建的时间
+ * LstSched：上一次任务被调度的时间
+ * LstVisit：上一次任务被访问的时间。这里“被访问”指包括被调度，任务执行汇报等和这个任务相关的被处理的时间点
+ * Finished：任务结束时间
+ * Rate：clone 任务的数据拷贝速率
+ * FailedSched：任务调度失败的次数
+ * FailedRunning：任务执行失败的次数
+ * LstAdjPrio：上一次优先级调整的时间
+ * CmtVer/CmtVerHash/VisibleVer/VisibleVerHash：用于执行 clone 任务的 version 信息
+ * ErrMsg：任务被调度和运行过程中，出现的错误信息
+
+2. 查看正在运行的任务
+
+ `SHOW PROC '/cluster_balance/running_tablets';`
+
+ 其结果中各列的含义和 `pending_tablets` 相同。
+
+3. 查看已结束任务
+
+ `SHOW PROC '/cluster_balance/history_tablets';`
+
+ 我们默认只保留最近 1000 个完成的任务。其结果中各列的含义和 `pending_tablets` 相同。如果 `State` 列为 `FINISHED`，则说明任务正常完成。如果为其他，则可以根据 `ErrMsg` 列的错误信息查看具体原因。
+
+## 集群负载及调度资源查看
+
+1. 集群负载
+
+ 通过以下命令可以查看集群当前的负载情况：
+
+ `SHOW PROC '/cluster_balance/cluster_load_stat';`
+
+ 首先看到的是对不同存储介质的划分：
+
+ ```
+ +---------------+
+ | StorageMedium |
+ +---------------+
+ | HDD |
+ | SSD |
+ +---------------+
+ ```
+
+ 点击某一种存储介质，可以看到包含该存储介质的 BE 节点的均衡状态：
+
+ `SHOW PROC '/cluster_balance/cluster_load_stat/HDD';`
+
+ ```
+ +----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
+ | BeId | Cluster | Available | UsedCapacity | Capacity | UsedPercent | ReplicaNum | CapCoeff | ReplCoeff | Score | Class |
+ +----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
+ | 10003 | default_cluster | true | 3477875259079 | 19377459077121 | 17.948 | 493477 | 0.5 | 0.5 | 0.9284678149967587 | MID |
+ | 10002 | default_cluster | true | 3607326225443 | 19377459077121 | 18.616 | 496928 | 0.5 | 0.5 | 0.948660871419998 | MID |
+ | 10005 | default_cluster | true | 3523518578241 | 19377459077121 | 18.184 | 545331 | 0.5 | 0.5 | 0.9843539990641831 | MID |
+ | 10001 | default_cluster | true | 3535547090016 | 19377459077121 | 18.246 | 558067 | 0.5 | 0.5 | 0.9981869446537612 | MID |
+ | 10006 | default_cluster | true | 3636050364835 | 19377459077121 | 18.764 | 547543 | 0.5 | 0.5 | 1.0011489897614072 | MID |
+ | 10004 | default_cluster | true | 3506558163744 | 15501967261697 | 22.620 | 468957 | 0.5 | 0.5 | 1.0228319835582569 | MID |
+ | 10007 | default_cluster | true | 4036460478905 | 19377459077121 | 20.831 | 551645 | 0.5 | 0.5 | 1.057279369420761 | MID |
+ | 10000 | default_cluster | true | 4369719923760 | 19377459077121 | 22.551 | 547175 | 0.5 | 0.5 | 1.0964036415787461 | MID |
+ +----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
+ ```
+
+ 其中一些列的含义如下：
+
+ * Available：为 true 表示 BE 心跳正常，且没有处于下线中
+ * UsedCapacity：字节，BE 上已使用的磁盘空间大小
+ * Capacity：字节，BE 上总的磁盘空间大小
+ * UsedPercent：百分比，BE 上的磁盘空间使用率
+ * ReplicaNum：BE 上副本数量
+ * CapCoeff/ReplCoeff：磁盘空间和副本数的权重系数
+ * Score：负载分数。分数越高，负载越重
+ * Class：根据负载情况分类，LOW/MID/HIGH。均衡调度会将高负载节点上的副本迁往低负载节点
+
+ 用户可以进一步查看某个 BE 上各个路径的使用率，比如 ID 为 10001 这个 BE：
+
+ `SHOW PROC '/cluster_balance/cluster_load_stat/HDD/10001';`
+
+ ```
+ +------------------+------------------+---------------+---------------+---------+--------+----------------------+
+ | RootPath | DataUsedCapacity | AvailCapacity | TotalCapacity | UsedPct | State | PathHash |
+ +------------------+------------------+---------------+---------------+---------+--------+----------------------+
+ | /home/disk4/palo | 498.757 GB | 3.033 TB | 3.525 TB | 13.94 % | ONLINE | 4883406271918338267 |
+ | /home/disk3/palo | 704.200 GB | 2.832 TB | 3.525 TB | 19.65 % | ONLINE | -5467083960906519443 |
+ | /home/disk1/palo | 512.833 GB | 3.007 TB | 3.525 TB | 14.69 % | ONLINE | -7733211489989964053 |
+ | /home/disk2/palo | 881.955 GB | 2.656 TB | 3.525 TB | 24.65 % | ONLINE | 4870995507205544622 |
+ | /home/disk5/palo | 694.992 GB | 2.842 TB | 3.525 TB | 19.36 % | ONLINE | 1916696897889786739 |
+ +------------------+------------------+---------------+---------------+---------+--------+----------------------+
+ ```
+
+ 这里显示了指定 BE 上，各个数据路径的磁盘使用率情况。
+
+2. 调度资源
+
+ 用户可以通过以下命令，查看当前各个节点的 slot 使用情况：
+
+ `SHOW PROC '/cluster_balance/working_slots';`
+
+ ```
+ +----------+----------------------+------------+------------+-------------+----------------------+
+ | BeId | PathHash | AvailSlots | TotalSlots | BalanceSlot | AvgRate |
+ +----------+----------------------+------------+------------+-------------+----------------------+
+ | 10000 | 8110346074333016794 | 2 | 2 | 2 | 2.459007474009069E7 |
+ | 10000 | -5617618290584731137 | 2 | 2 | 2 | 2.4730105014001578E7 |
+ | 10001 | 4883406271918338267 | 2 | 2 | 2 | 1.6711402709780257E7 |
+ | 10001 | -5467083960906519443 | 2 | 2 | 2 | 2.7540126380326536E7 |
+ | 10002 | 9137404661108133814 | 2 | 2 | 2 | 2.417217089806745E7 |
+ | 10002 | 1885826196444191611 | 2 | 2 | 2 | 1.6327378456676323E7 |
+ +----------+----------------------+------------+------------+-------------+----------------------+
+ ```
+
+ 这里以数据路径为粒度，展示了当前 slot 的使用情况。其中 `AvgRate` 为历史统计的该路径上 clone 任务的拷贝速率，单位是字节/秒。
+
+3. 优先修复查看
+
+ 以下命令，可以查看通过 `ADMIN REPAIR TABLE` 命令设置的优先修复的表或分区。
+
+ `SHOW PROC '/cluster_balance/priority_repair';`
+
+ 其中 `RemainingTimeMs` 表示，这些优先修复的内容，将在这个时间后，被自动移出优先修复队列。以防止优先修复一直失败导致资源被占用。
+
+### 调度器统计状态查看
+
+我们收集了 TabletChecker 和 TabletScheduler 在运行过程中的一些统计信息，可以通过以下命令查看：
+
+`SHOW PROC '/cluster_balance/sched_stat';`
+
+```
++---------------------------------------------------+-------------+
+| Item | Value |
++---------------------------------------------------+-------------+
+| num of tablet check round | 12041 |
+| cost of tablet check(ms) | 7162342 |
+| num of tablet checked in tablet checker | 18793506362 |
+| num of unhealthy tablet checked in tablet checker | 7043900 |
+| num of tablet being added to tablet scheduler | 1153 |
+| num of tablet schedule round | 49538 |
+| cost of tablet schedule(ms) | 49822 |
+| num of tablet being scheduled | 4356200 |
+| num of tablet being scheduled succeeded | 320 |
+| num of tablet being scheduled failed | 4355594 |
+| num of tablet being scheduled discard | 286 |
+| num of tablet priority upgraded | 0 |
+| num of tablet priority downgraded | 1096 |
+| num of clone task | 230 |
+| num of clone task succeeded | 228 |
+| num of clone task failed | 2 |
+| num of clone task timeout | 2 |
+| num of replica missing error | 4354857 |
+| num of replica version missing error | 967 |
+| num of replica relocating | 0 |
+| num of replica redundant error | 90 |
+| num of replica missing in cluster error | 0 |
+| num of balance scheduled | 0 |
++---------------------------------------------------+-------------+
+```
+
+各行含义如下：
+
+* num of tablet check round：Tablet Checker 检查次数
+* cost of tablet check(ms)：Tablet Checker 检查总耗时
+* num of tablet checked in tablet checker：Tablet Checker 检查过的 tablet 数量
+* num of unhealthy tablet checked in tablet checker：Tablet Checker 检查过的不健康的 tablet 数量
+* num of tablet being added to tablet scheduler：被提交到 Tablet Scheduler 中的 tablet 数量
+* num of tablet schedule round：Tablet Scheduler 运行次数
+* cost of tablet schedule(ms)：Tablet Scheduler 运行总耗时
+* num of tablet being scheduled：被调度的 Tablet 总数量
+* num of tablet being scheduled succeeded：被成功调度的 Tablet 总数量
+* num of tablet being scheduled failed：调度失败的 Tablet 总数量
+* num of tablet being scheduled discard：调度失败且被抛弃的 Tablet 总数量
+* num of tablet priority upgraded：优先级上调次数
+* num of tablet priority downgraded：优先级下调次数
+* num of clone task：生成的 clone 任务数量
+* num of clone task succeeded：clone 任务成功的数量
+* num of clone task failed：clone 任务失败的数量
+* num of clone task timeout：clone 任务超时的数量
+* num of replica missing error：检查的状态为副本缺失的 tablet 的数量
+* num of replica version missing error：检查的状态为版本缺失的 tablet 的数量（该统计值包括了 num of replica relocating 和 num of replica missing in cluster error）
+* num of replica relocating：检查的状态为 replica relocating 的 tablet 的数量
+* num of replica redundant error：检查的状态为副本冗余的 tablet 的数量
+* num of replica missing in cluster error：检查的状态为不在对应 cluster 的 tablet 的数量
+* num of balance scheduled：均衡调度的次数
+
+> 注：以上状态都只是历史累加值。我们也在 FE 的日志中，定期打印了这些统计信息，其中括号内的数值表示自上次统计信息打印依赖，各个统计值的变化数量。
+
+## 相关配置说明
+
+### 可调整参数
+
+以下可调整参数均为 fe.conf 中可配置参数。
+
+* use\_new\_tablet\_scheduler
+
+ * 说明：是否启用新的副本调度方式。新的副本调度方式即本文档介绍的副本调度方式。
+ * 默认值：true
+ * 重要性：高
+
+* tablet\_repair\_delay\_factor\_second
+
+ * 说明：对于不同的调度优先级，我们会延迟不同的时间后开始修复。以防止因为例行重启、升级等过程中，产生大量不必要的副本修复任务。此参数为一个基准系数。对于 HIGH 优先级，延迟为 基准系数 * 1；对于 NORMAL 优先级，延迟为 基准系数 * 2；对于 LOW 优先级，延迟为 基准系数 * 3。即优先级越低，延迟等待时间越长。如果用户想尽快修复副本，可以适当降低该参数。
+ * 默认值：60秒
+ * 重要性：高
+
+* schedule\_slot\_num\_per\_path
+
+ * 说明：默认分配给每块磁盘用于副本修复的 slot 数目。该数目表示一块磁盘能同时运行的副本修复任务数。如果想以更快的速度修复副本，可以适当调高这个参数。单数值越高，可能对 IO 影响越大。
+ * 默认值：2
+ * 重要性：高
+
+* balance\_load\_score\_threshold
+
+ * 说明：集群均衡的阈值。默认为 0.1，即 10%。当一个 BE 节点的 load score，不高于或不低于平均 load score 的 10% 时，我们认为这个节点是均衡的。如果想让集群负载更加平均，可以适当调低这个参数。
+ * 默认值：0.1
+ * 重要性：中
+
+* storage\_high\_watermark\_usage\_percent 和 storage\_min\_left\_capacity\_bytes
+
+ * 说明：这两个参数，分别表示一个磁盘的最大空间使用率上限，以及最小的空间剩余下限。当一块磁盘的空间使用率大于上限，或者剩余空间小于下限时，该磁盘将不再作为均衡调度的目的地址。
+ * 默认值：0.85 和 1048576000 （1GB）
+ * 重要性：中
+
+* disable\_balance
+
+ * 说明：控制是否关闭均衡功能。当副本处于均衡过程中时，有些功能，如 ALTER TABLE 等将会被禁止。而均衡可能持续很长时间。因此，如果用户希望尽快进行被禁止的操作。可以将该参数设为 true，以关闭均衡调度。
+ * 默认值：false
+ * 重要性：中
+
+### 不可调整参数
+
+以下参数暂不支持修改，仅作说明。
+
+* TabletChecker 调度间隔
+
+ TabletChecker 每20秒进行一次检查调度。
+
+* TabletScheduler 调度间隔
+
+ TabletScheduler 每5秒进行一次调度
+
+* TabletScheduler 每批次调度个数
+
+ TabletScheduler 每次调度最多 50 个 tablet。
+
+* TabletScheduler 最大等待调度和运行中任务数
+
+ 最大等待调度任务数和运行中任务数为 2000。当超过 2000 后，TabletChecker 将不再产生新的调度任务给 TabletScheduler。
+
+* TabletScheduler 最大均衡任务数
+
+ 最大均衡任务数为 500。当超过 500 后，将不再产生新的均衡任务。
+
+* 每块磁盘用于均衡任务的 slot 数目
+
+ 每块磁盘用于均衡任务的 slot 数目为2。这个 slot 独立于用于副本修复的 slot。
+
+* 集群均衡情况更新间隔
+
+ TabletScheduler 每隔 20 秒会重新计算一次集群的 load score。
+
+* Clone 任务的最小和最大超时时间
+
+ 一个 clone 任务超时时间范围是 3min ~ 2hour。具体超时时间通过 tablet 的大小计算。计算公式为 (tablet size) / (5MB/s)。当一个 clone 任务运行失败 3 次后，该任务将终止。
+
+* 动态优先级调整策略
+
+ 优先级最小调整间隔为 5min。当一个 tablet 调度失败5次后，会调低优先级。当一个 tablet 30min 未被调度时，会调高优先级。
+
+## 相关问题
+
+* 在某些情况下，默认的副本修复和均衡策略可能会导致网络被打满（多发生在千兆网卡，且每台 BE 的磁盘数量较多的情况下）。此时需要调整一些参数来减少同时进行的均衡和修复任务数。
+
+* 目前针对 Colocate Table 的副本的均衡策略无法保证同一个 Tablet 的副本不会分布在同一个 host 的 BE 上。但 Colocate Table 的副本的修复策略会检测到这种分布错误并校正。但可能会出现，校正后，均衡策略再次认为副本不均衡而重新均衡。从而导致在两种状态间不停交替，无法使 Colocate Group 达成稳定。针对这种情况，我们建议在使用 Colocate 属性时，尽量保证集群是同构的，以减小副本分布在同一个 host 上的概率。
+
+## 最佳实践
+
+### 控制并管理集群的副本修复和均衡进度
+
+在大多数情况下，通过默认的参数配置，Doris 都可以自动的进行副本修复和集群均衡。但是某些情况下，我们需要通过人工介入调整参数，来达到一些特殊的目的。如优先修复某个表或分区、禁止集群均衡以降低集群负载、优先修复非 colocation 的表数据等等。
+
+本小节主要介绍如何通过修改参数，来控制并管理集群的副本修复和均衡进度。
+
+1. 删除损坏副本
+
+ 某些情况下，Doris 可能无法自动检测某些损坏的副本，从而导致查询或导入在损坏的副本上频繁报错。此时我们需要手动删除已损坏的副本。该方法可以适用于：删除版本数过高导致 -235 错误的副本、删除文件已损坏的副本等等。
+
+ 首先，找到副本对应的 tablet id，假设为 10001。通过 `show tablet 10001;` 并执行其中的 `show proc` 语句可以查看对应的 tablet 的各个副本详情。
+
+ 假设需要删除的副本的 backend id 是 20001。则执行以下语句将副本标记为 `bad`：
+
+ ```
+ ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "10001", "backend_id" = "20001", "status" = "bad");
+ ```
+
+ 此时，再次通过 `show proc` 语句可以看到对应的副本的 `IsBad` 列值为 `true`。
+
+ 被标记为 `bad` 的副本不会再参与导入和查询。同时副本修复逻辑会自动补充一个新的副本。
+
+2. 优先修复某个表或分区
+
+ `help admin repair table;` 查看帮助。该命令会尝试优先修复指定表或分区的tablet。
+
+3. 停止均衡任务
+
+ 均衡任务会占用一定的网络带宽和IO资源。如果希望停止新的均衡任务的产生，可以通过以下命令：
+
+ ```
+ ADMIN SET FRONTEND CONFIG ("disable_balance" = "true");
+ ```
+
+4. 停止所有副本调度任务
+
+ 副本调度任务包括均衡和修复任务。这些任务都会占用一定的网络带宽和IO资源。可以通过以下命令停止所有副本调度任务（不包括已经在运行的，包括 colocation 表和普通表）：
+
+ ```
+ ADMIN SET FRONTEND CONFIG ("disable_tablet_scheduler" = "true");
+ ```
+
+5. 停止所有 colocation 表的副本调度任务。
+
+ colocation 表的副本调度和普通表是分开独立运行的。某些情况下，用户可能希望先停止对 colocation 表的均衡和修复工作，而将集群资源用于普通表的修复，则可以通过以下命令：
+
+ ```
+ ADMIN SET FRONTEND CONFIG ("disable_colocate_balance" = "true");
+ ```
+
+6. 使用更保守的策略修复副本
+
+ Doris 在检测到副本缺失、BE宕机等情况下，会自动修复副本。但为了减少一些抖动导致的错误（如BE短暂宕机），Doris 会延迟触发这些任务。
+
+ * `tablet_repair_delay_factor_second` 参数。默认 60 秒。根据修复任务优先级的不同，会推迟 60秒、120秒、180秒后开始触发修复任务。可以通过以下命令延长这个时间，这样可以容忍更长的异常时间，以避免触发不必要的修复任务：
+
+ ```
+ ADMIN SET FRONTEND CONFIG ("tablet_repair_delay_factor_second" = "120");
+ ```
+
+7. 使用更保守的策略触发 colocation group 的重分布
+
+ colocation group 的重分布可能伴随着大量的 tablet 迁移。`colocate_group_relocate_delay_second` 用于控制重分布的触发延迟。默认 1800秒。如果某台 BE 节点可能长时间下线，可以尝试调大这个参数，以避免不必要的重分布：
+
+ ```
+ ADMIN SET FRONTEND CONFIG ("colocate_group_relocate_delay_second" = "3600");
+ ```
+
+8. 更快速的副本均衡
+
+ Doris 的副本均衡逻辑会先增加一个正常副本，然后在删除老的副本，已达到副本迁移的目的。而在删除老副本时，Doris会等待这个副本上已经开始执行的导入任务完成，以避免均衡任务影响导入任务。但这样会降低均衡逻辑的执行速度。此时可以通过修改以下参数，让 Doris 忽略这个等待，直接删除老副本：
+
+ ```
+ ADMIN SET FRONTEND CONFIG ("enable_force_drop_redundant_replica" = "true");
+ ```
+
+ 这种操作可能会导致均衡期间部分导入任务失败（需要重试），但会显著加速均衡速度。
+
+总体来讲，当我们需要将集群快速恢复到正常状态时，可以考虑按照以下思路处理：
+
+1. 找到导致高优任务报错的tablet，将有问题的副本置为 bad。
+2. 通过 `admin repair` 语句高优修复某些表。
+3. 停止副本均衡逻辑以避免占用集群资源，等集群恢复后，再开启即可。
+4. 使用更保守的策略触发修复任务，以应对 BE 频繁宕机导致的雪崩效应。
+5. 按需关闭 colocation 表的调度任务，集中集群资源修复其他高优数据。
+
+
+
diff --git a/new-docs/zh-CN/admin-manual/maint-monitor/tablet-restore-tool.md b/new-docs/zh-CN/admin-manual/maint-monitor/tablet-restore-tool.md
index daf19cf591..aba46d8f4f 100644
--- a/new-docs/zh-CN/admin-manual/maint-monitor/tablet-restore-tool.md
+++ b/new-docs/zh-CN/admin-manual/maint-monitor/tablet-restore-tool.md
@@ -24,4 +24,119 @@ specific language governing permissions and limitations
under the License.
-->
-# Tablet 恢复工具
\ No newline at end of file
+# Tablet 恢复工具
+
+## 从 BE 回收站中恢复数据
+
+用户在使用Doris的过程中，可能会发生因为一些误操作或者线上bug，导致一些有效的tablet被删除（包括元数据和数据）。为了防止在这些异常情况出现数据丢失，Doris提供了回收站机制，来保护用户数据。用户删除的tablet数据不会被直接删除，会被放在回收站中存储一段时间，在一段时间之后会有定时清理机制将过期的数据删除。回收站中的数据包括：tablet的data文件(.dat)，tablet的索引文件(.idx)和tablet的元数据文件(.hdr)。数据将会存放在如下格式的路径：
+
+```
+/root_path/trash/time_label/tablet_id/schema_hash/
+```
+
+* `root_path`：对应BE节点的某个数据根目录。
+* `trash`：回收站的目录。
+* `time_label`：时间标签，为了回收站中数据目录的唯一性，同时记录数据时间，使用时间标签作为子目录。
+
+当用户发现线上的数据被误删除，需要从回收站中恢复被删除的tablet，需要用到这个tablet数据恢复功能。
+
+BE提供http接口和 `restore_tablet_tool.sh` 脚本实现这个功能，支持单tablet操作（single mode）和批量操作模式（batch mode）。
+
+* 在single mode下，支持单个tablet的数据恢复。
+* 在batch mode下，支持批量tablet的数据恢复。
+
+### 操作
+
+#### single mode
+
+1. http请求方式
+
+ BE中提供单个tablet数据恢复的http接口，接口如下：
+
+ ```
+ curl -X POST "http://be_host:be_webserver_port/api/restore_tablet?tablet_id=11111\&schema_hash=12345"
+ ```
+
+ 成功的结果如下：
+
+ ```
+ {"status": "Success", "msg": "OK"}
+ ```
+
+ 失败的话，会返回相应的失败原因，一种可能的结果如下：
+
+ ```
+ {"status": "Failed", "msg": "create link path failed"}
+ ```
+
+2. 脚本方式
+
+ `restore_tablet_tool.sh` 可用来实现单tablet数据恢复的功能。
+
+ ```
+ sh tools/restore_tablet_tool.sh -b "http://127.0.0.1:8040" -t 12345 -s 11111
+ sh tools/restore_tablet_tool.sh --backend "http://127.0.0.1:8040" --tablet_id 12345 --schema_hash 11111
+ ```
+
+#### batch mode
+
+批量恢复模式用于实现恢复多个tablet数据的功能。
+
+使用的时候需要预先将恢复的tablet id和schema hash按照逗号分隔的格式放在一个文件中，一个tablet一行。
+
+格式如下：
+
+```
+12345,11111
+12346,11111
+12347,11111
+```
+
+然后如下的命令进行恢复(假设文件名为：`tablets.txt`)：
+
+```
+sh restore_tablet_tool.sh -b "http://127.0.0.1:8040" -f tablets.txt
+sh restore_tablet_tool.sh --backend "http://127.0.0.1:8040" --file tablets.txt
+```
+
+## 修复缺失或损坏的 Tablet
+
+在某些极特殊情况下，如代码BUG、或人为误操作等，可能导致部分分片的全部副本都丢失。这种情况下，数据已经实质性的丢失。但是在某些场景下，业务依然希望能够在即使有数据丢失的情况下，保证查询正常不报错，降低用户层的感知程度。此时，我们可以通过使用空白Tablet填充丢失副本的功能，来保证查询能够正常执行。
+
+**注：该操作仅用于规避查询因无法找到可查询副本导致报错的问题，无法恢复已经实质性丢失的数据**
+
+1. 查看 Master FE 日志 `fe.log`
+
+ 如果出现数据丢失的情况，则日志中会有类似如下日志：
+
+ ```
+ backend [10001] invalid situation. tablet[20000] has few replica[1], replica num setting is [3]
+ ```
+
+ 这个日志表示，Tablet 20000 的所有副本已损坏或丢失。
+
+2. 使用空白副本填补缺失副本
+
+ 当确认数据已经无法恢复后，可以通过执行以下命令，生成空白副本。
+
+ ```
+ ADMIN SET FRONTEND CONFIG ("recover_with_empty_tablet" = "true");
+ ```
+
+ * 注：可以先通过 `ADMIN SHOW FRONTEND CONFIG;` 命令查看当前版本是否支持该参数。
+
+3. 设置完成几分钟后，应该会在 Master FE 日志 `fe.log` 中看到如下日志：
+
+ ```
+ tablet 20000 has only one replica 20001 on backend 10001 and it is lost. create an empty replica to recover it.
+ ```
+
+ 该日志表示系统已经创建了一个空白 Tablet 用于填补缺失副本。
+
+4. 通过查询来判断是否已经修复成功。
+
+5. 全部修复成功后，通过以下命令关闭 `recover_with_empty_tablet` 参数：
+
+ ```
+ ADMIN SET FRONTEND CONFIG ("recover_with_empty_tablet" = "false");
+ ```
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@doris.apache.org
For additional commands, e-mail: commits-help@doris.apache.org