This is an automated email from the ASF dual-hosted git repository.
luzhijing pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new 6bc18505ba14 Modify the observer recovery step description (#526)
6bc18505ba14 is described below
commit 6bc18505ba14a3f00e607e7c4858364ae25c6bce
Author: echo-dundun <[email protected]>
AuthorDate: Tue Apr 9 18:51:02 2024 +0800
Modify the observer recovery step description (#526)
---
.../maint-monitor/metadata-operation.md | 25 +++++++++------
.../maint-monitor/metadata-operation.md | 36 ++++++++++++++--------
.../maint-monitor/metadata-operation.md | 2 +-
.../maint-monitor/metadata-operation.md | 6 ++--
.../maint-monitor/metadata-operation.md | 36 ++++++++++++++--------
.../maint-monitor/metadata-operation.md | 2 +-
.../maint-monitor/metadata-operation.md | 25 +++++++++------
.../maint-monitor/metadata-operation.md | 25 +++++++++------
8 files changed, 101 insertions(+), 56 deletions(-)
diff --git a/docs/admin-manual/maint-monitor/metadata-operation.md
b/docs/admin-manual/maint-monitor/metadata-operation.md
index 7042914e3c9f..f98e5c9bd56c 100644
--- a/docs/admin-manual/maint-monitor/metadata-operation.md
+++ b/docs/admin-manual/maint-monitor/metadata-operation.md
@@ -192,22 +192,29 @@ FE may fail to start bdbje and synchronize between FEs
for some reasons. Phenome
1. Modify fe.conf
- If the node is an OBSERVER, first change the `role=OBSERVER` in the
`meta_dir/image/ROLE` file to `role=FOLLOWER`. (Recovery from the OBSERVER node
will be more cumbersome, first follow the steps here, followed by a separate
description)
- If fe.version < 2.0.2, add configuration in fe.conf:
`metadata_failure_recovery=true`.
- 2. Run `sh bin/start_fe.sh --metadata_failure_recovery --daemon` to
start the FE
+ 2. Run `sh bin/start_fe.sh --metadata_failure_recovery --daemon` to
start the FE. (If you are recovering from an OBSERVER node, jump to the
subsequent OBSERVER document after this step.)
3. If normal, the FE will start in the role of MASTER, similar to the
description in the previous section `Start a single node FE`. You should see
the words `transfer from XXXX to MASTER` in fe.log.
4. After the start-up is completed, connect to the FE first, and
execute some query imports to check whether normal access is possible. If the
operation is not normal, it may be wrong. It is recommended to read the above
steps carefully and try again with the metadata previously backed up. If not,
the problem may be more serious.
5. If successful, through the `show frontends;` command, you should see
all the FEs you added before, and the current FE is master.
6. **If FE version < 2.0.2**, delete the `metadata_failure_recovery=true`
configuration item in fe.conf, or set it to `false`, and restart the FE
(**Important**).
- > If you are recovering metadata from an OBSERVER node, after
completing the above steps, you will find that the current FE role is OBSERVER,
but `IsMaster` appears as `true`. This is because the "OBSERVER" seen here is
recorded in Doris's metadata, but whether it is master or not, is recorded in
bdbje's metadata. Because we recovered from an OBSERVER node, there was
inconsistency. Please take the following steps to fix this problem (we will fix
it in a later version):
+ :::tip
+ If you are recovering metadata from an OBSERVER node, after completing
the above steps, you will find that the current FE role is OBSERVER, but
`IsMaster` appears as `true`. This is because the "OBSERVER" seen here is
recorded in Doris's metadata, but whether it is master or not, is recorded in
bdbje's metadata. Because we recovered from an OBSERVER node, there was
inconsistency. Please take the following steps to fix this problem (we will fix
it in a later version):
- > 1. First, all FE nodes except this "OBSERVER" are DROPed out.
- > 2. A new FOLLOWER FE is added through the `ADD FOLLOWER` command,
assuming that it is on hostA.
- > 3. Start a new FE on hostA and join the cluster by `helper`.
- > 4. After successful startup, you should see two FEs through the `show
frontends;` statement, one is the previous OBSERVER, the other is the newly
added FOLLOWER, and the OBSERVER is the master.
- > 5. After confirming that the new FOLLOWER is working properly, the
new FOLLOWER metadata is used to perform a failure recovery operation again.
- > 6. The purpose of the above steps is to manufacture a metadata of
FOLLOWER node artificially, and then use this metadata to restart fault
recovery. This avoids inconsistencies in recovering metadata from OBSERVER.
+ 1. First, all FE nodes except this "OBSERVER" are DROPed out.
- >The meaning of `metadata_failure_recovery` is to empty the metadata of
`bdbje`. In this way, bdbje will not contact other FEs before, but start as a
separate FE. This parameter needs to be set to true only when restoring
startup. After recovery, it must be set to false. Otherwise, once restarted,
the metadata of bdbje will be emptied again, which will make other FEs unable
to work properly.
+ 2. A new FOLLOWER FE is added through the `ADD FOLLOWER` command,
assuming that it is on hostA.
+
+ 3. Start a new FE on hostA and join the cluster by `helper`.
+
+ 4. After successful startup, you should see two FEs through the `show
frontends;` statement, one is the previous OBSERVER, the other is the newly
added FOLLOWER, and the OBSERVER is the master.
+
+ 5. After confirming that the new FOLLOWER is working properly, the new
FOLLOWER metadata is used to perform a failure recovery operation again.
+
+ 6. The purpose of the above steps is to manufacture a metadata of
FOLLOWER node artificially, and then use this metadata to restart fault
recovery. This avoids inconsistencies in recovering metadata from OBSERVER.
+
+ The meaning of `metadata_failure_recovery` is to empty the metadata of
`bdbje`. In this way, bdbje will not contact other FEs before, but start as a
separate FE. This parameter needs to be set to true only when restoring
startup. After recovery, it must be set to false. Otherwise, once restarted,
the metadata of bdbje will be emptied again, which will make other FEs unable
to work properly.
+ :::
4. After the successful execution of step 3, we delete the previous FEs from
the metadata by using the `ALTER SYSTEM DROP FOLLOWER/OBSERVER` command and add
them again by adding new FEs.
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/maint-monitor/metadata-operation.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/maint-monitor/metadata-operation.md
index f72fd6962350..9c1bbd2e4440 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/maint-monitor/metadata-operation.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/maint-monitor/metadata-operation.md
@@ -187,29 +187,41 @@ FE 有可能因为某些原因出现无法启动 bdbje、FE 之间无法同步
* 之后，我们要使用这个拥有最新元数据的 FE 节点，进行恢复。
* 如果使用 OBSERVER 节点的元数据进行恢复会比较麻烦，建议尽量选择 FOLLOWER 节点。
-3. 以下操作都在由第2步中选择出来的 FE 节点上进行。
+3. 以下操作都在由第 2 步中选择出来的 FE 节点上进行。
1. 修改 `fe.conf`
- - 如果该节点是一个 OBSERVER，先将 `meta_dir/image/ROLE` 文件中的 `role=OBSERVER` 改为
`role=FOLLOWER`。（从 OBSERVER 节点恢复会比较麻烦，先按这里的步骤操作，后面会有单独说明）)
+ - 如果该节点是一个 OBSERVER，先将 `meta_dir/image/ROLE` 文件中的 `role=OBSERVER` 改为
`role=FOLLOWER`。
- 如果 FE 版本< 2.0.2, 则还需要在 fe.conf 中添加配置：`metadata_failure_recovery=true`。
- 2. 执行 `sh bin/start_fe.sh --metadata_failure_recovery --daemon` 启动这个 FE。
+
+ 2. 执行 `sh bin/start_fe.sh --metadata_failure_recovery --daemon` 启动这个
FE。（如果是从 OBSERVER 节点恢复，执行完这一步后跳转到后续的 OBSERVER 文档）
+
3. 如果正常，这个 FE 会以 MASTER 的角色启动，类似于前面 `启动单节点 FE` 一节中的描述。在 fe.log 应该会看到
`transfer from XXXX to MASTER` 等字样。
+
4. 启动完成后，先连接到这个
FE，执行一些查询导入，检查是否能够正常访问。如果不正常，有可能是操作有误，建议仔细阅读以上步骤，用之前备份的元数据再试一次。如果还是不行，问题可能就比较严重了。
+
5. 如果成功，通过 `show frontends;` 命令，应该可以看到之前所添加的所有 FE，并且当前 FE 是 master。
+
6. 后重启这个 FE（**重要**）。
+
7. **如果 FE 版本 < 2.0.2**，将 fe.conf 中的 `metadata_failure_recovery=true`
配置项删除，或者设置为 `false`，然后重启这个 FE（**重要**）。
-
- > 如果你是从一个 OBSERVER 节点的元数据进行恢复的，那么完成如上步骤后，通过 `show frontends;` 语句你会发现，当前这个
FE 的角色为 OBSERVER，但是 `IsMaster` 显示为 `true`。这是因为，这里看到的 “OBSERVER” 是记录在 Doris
的元数据中的，而是否是 master，是记录在 bdbje 的元数据中的。因为我们是从一个 OBSERVER
节点恢复的，所以这里出现了不一致。请按如下步骤修复这个问题（这个问题我们会在之后的某个版本修复）：
+ :::tip
+ 如果你是从一个 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 的元数据，重新执行一遍故障恢复操作。
- > 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 恢复元数据所遇到的不一致的问题。
+ 6. 以上这些步骤的目的，其实就是人为的制造出一个 FOLLOWER 节点的元数据，然后用这个元数据，重新开始故障恢复。这样就避免了从
OBSERVER 恢复元数据所遇到的不一致的问题。
- > `metadata_failure_recovery` 的含义是，清空 "bdbje" 的元数据。这样 bdbje 就不会再联系之前的其他 FE
了，而作为一个独立的 FE 启动。这个参数只有在恢复启动时才需要设置为 true。恢复完成后，一定要设置为 false，否则一旦重启，bdbje
的元数据又会被清空，导致其他 FE 无法正常工作。
+ `metadata_failure_recovery` 的含义是，清空 "bdbje" 的元数据。这样 bdbje 就不会再联系之前的其他 FE
了，而作为一个独立的 FE 启动。这个参数只有在恢复启动时才需要设置为 true。恢复完成后，一定要设置为 false，否则一旦重启，bdbje
的元数据又会被清空，导致其他 FE 无法正常工作。
+ :::
4. 第3步执行成功后，我们再通过 `ALTER SYSTEM DROP FOLLOWER/OBSERVER` 命令，将之前的其他的 FE
从元数据删除后，按加入新 FE 的方式，重新把这些 FE 添加一遍。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.2/admin-manual/maint-monitor/metadata-operation.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.2/admin-manual/maint-monitor/metadata-operation.md
index 63dd80b0e83d..d67f62d7c8fa 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.2/admin-manual/maint-monitor/metadata-operation.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.2/admin-manual/maint-monitor/metadata-operation.md
@@ -191,7 +191,7 @@ FE 有可能因为某些原因出现无法启动 bdbje、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。
+ 3. 执行 `sh bin/start_fe.sh --daemon` 启动这个 FE。
4. 如果正常，这个 FE 会以 MASTER 的角色启动，类似于前面 `启动单节点 FE` 一节中的描述。在 fe.log 应该会看到
`transfer from XXXX to MASTER` 等字样。
5. 启动完成后，先连接到这个
FE，执行一些查询导入，检查是否能够正常访问。如果不正常，有可能是操作有误，建议仔细阅读以上步骤，用之前备份的元数据再试一次。如果还是不行，问题可能就比较严重了。
6. 如果成功，通过 `show frontends;` 命令，应该可以看到之前所添加的所有 FE，并且当前 FE 是 master。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/admin-manual/maint-monitor/metadata-operation.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/admin-manual/maint-monitor/metadata-operation.md
index 00d01a0ac80d..378e1a9b2b91 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/admin-manual/maint-monitor/metadata-operation.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/admin-manual/maint-monitor/metadata-operation.md
@@ -221,10 +221,10 @@ FE 有可能因为某些原因出现无法启动 bdbje、FE 之间无法同步
3. 以下操作都在由第 2 步中选择出来的 FE 节点上进行。
1. 修改 `fe.conf`
- - 如果该节点是一个 OBSERVER，先将 `meta_dir/image/ROLE` 文件中的 `role=OBSERVER` 改为
`role=FOLLOWER`。（从 OBSERVER 节点恢复会比较麻烦，先按这里的步骤操作，后面会有单独说明）)
+ - 如果该节点是一个 OBSERVER，先将 `meta_dir/image/ROLE` 文件中的 `role=OBSERVER` 改为
`role=FOLLOWER`。
- 如果 FE 版本< 2.0.2, 则还需要在 fe.conf 中添加配置：`metadata_failure_recovery=true`。
- 2. 执行 `sh bin/start_fe.sh --metadata_failure_recovery --daemon` 启动这个 FE。
+ 2. 执行 `sh bin/start_fe.sh --metadata_failure_recovery --daemon` 启动这个
FE。（如果是从 OBSERVER 节点恢复，执行完这一步后跳转到后续的 OBSERVER 文档）
3. 如果正常，这个 FE 会以 MASTER 的角色启动，类似于前面 `启动单节点 FE` 一节中的描述。在 fe.log 应该会看到
`transfer from XXXX to MASTER` 等字样。
@@ -237,7 +237,7 @@ FE 有可能因为某些原因出现无法启动 bdbje、FE 之间无法同步
7. **如果 FE 版本 < 2.0.2**，将 fe.conf 中的 `metadata_failure_recovery=true`
配置项删除，或者设置为 `false`，然后重启这个 FE（**重要**）。
:::tip
- 如果你是从一个 OBSERVER 节点的元数据进行恢复的，那么完成如上步骤后，通过 `show frontends;` 语句你会发现，当前这个 FE
的角色为 OBSERVER，但是 `IsMaster` 显示为 `true`。这是因为，这里看到的“OBSERVER”是记录在 Doris
的元数据中的，而是否是 master，是记录在 bdbje 的元数据中的。因为我们是从一个 OBSERVER
节点恢复的，所以这里出现了不一致。请按如下步骤修复这个问题（这个问题我们会在之后的某个版本修复）：
+ 如果你是从一个 OBSERVER 节点的元数据进行恢复的，那么完成上述第二步后，通过 `show frontends;` 语句你会发现，当前这个
FE 的角色为 OBSERVER，但是 `IsMaster` 显示为 `true`。这是因为，这里看到的“OBSERVER”是记录在 Doris
的元数据中的，而是否是 master，是记录在 bdbje 的元数据中的。因为我们是从一个 OBSERVER
节点恢复的，所以这里出现了不一致。请按如下步骤修复这个问题（这个问题我们会在之后的某个版本修复）：
1. 先把除了这个“OBSERVER”以外的所有 FE 节点 DROP 掉。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/maint-monitor/metadata-operation.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/maint-monitor/metadata-operation.md
index f72fd6962350..9c1bbd2e4440 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/maint-monitor/metadata-operation.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/maint-monitor/metadata-operation.md
@@ -187,29 +187,41 @@ FE 有可能因为某些原因出现无法启动 bdbje、FE 之间无法同步
* 之后，我们要使用这个拥有最新元数据的 FE 节点，进行恢复。
* 如果使用 OBSERVER 节点的元数据进行恢复会比较麻烦，建议尽量选择 FOLLOWER 节点。
-3. 以下操作都在由第2步中选择出来的 FE 节点上进行。
+3. 以下操作都在由第 2 步中选择出来的 FE 节点上进行。
1. 修改 `fe.conf`
- - 如果该节点是一个 OBSERVER，先将 `meta_dir/image/ROLE` 文件中的 `role=OBSERVER` 改为
`role=FOLLOWER`。（从 OBSERVER 节点恢复会比较麻烦，先按这里的步骤操作，后面会有单独说明）)
+ - 如果该节点是一个 OBSERVER，先将 `meta_dir/image/ROLE` 文件中的 `role=OBSERVER` 改为
`role=FOLLOWER`。
- 如果 FE 版本< 2.0.2, 则还需要在 fe.conf 中添加配置：`metadata_failure_recovery=true`。
- 2. 执行 `sh bin/start_fe.sh --metadata_failure_recovery --daemon` 启动这个 FE。
+
+ 2. 执行 `sh bin/start_fe.sh --metadata_failure_recovery --daemon` 启动这个
FE。（如果是从 OBSERVER 节点恢复，执行完这一步后跳转到后续的 OBSERVER 文档）
+
3. 如果正常，这个 FE 会以 MASTER 的角色启动，类似于前面 `启动单节点 FE` 一节中的描述。在 fe.log 应该会看到
`transfer from XXXX to MASTER` 等字样。
+
4. 启动完成后，先连接到这个
FE，执行一些查询导入，检查是否能够正常访问。如果不正常，有可能是操作有误，建议仔细阅读以上步骤，用之前备份的元数据再试一次。如果还是不行，问题可能就比较严重了。
+
5. 如果成功，通过 `show frontends;` 命令，应该可以看到之前所添加的所有 FE，并且当前 FE 是 master。
+
6. 后重启这个 FE（**重要**）。
+
7. **如果 FE 版本 < 2.0.2**，将 fe.conf 中的 `metadata_failure_recovery=true`
配置项删除，或者设置为 `false`，然后重启这个 FE（**重要**）。
-
- > 如果你是从一个 OBSERVER 节点的元数据进行恢复的，那么完成如上步骤后，通过 `show frontends;` 语句你会发现，当前这个
FE 的角色为 OBSERVER，但是 `IsMaster` 显示为 `true`。这是因为，这里看到的 “OBSERVER” 是记录在 Doris
的元数据中的，而是否是 master，是记录在 bdbje 的元数据中的。因为我们是从一个 OBSERVER
节点恢复的，所以这里出现了不一致。请按如下步骤修复这个问题（这个问题我们会在之后的某个版本修复）：
+ :::tip
+ 如果你是从一个 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 的元数据，重新执行一遍故障恢复操作。
- > 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 恢复元数据所遇到的不一致的问题。
+ 6. 以上这些步骤的目的，其实就是人为的制造出一个 FOLLOWER 节点的元数据，然后用这个元数据，重新开始故障恢复。这样就避免了从
OBSERVER 恢复元数据所遇到的不一致的问题。
- > `metadata_failure_recovery` 的含义是，清空 "bdbje" 的元数据。这样 bdbje 就不会再联系之前的其他 FE
了，而作为一个独立的 FE 启动。这个参数只有在恢复启动时才需要设置为 true。恢复完成后，一定要设置为 false，否则一旦重启，bdbje
的元数据又会被清空，导致其他 FE 无法正常工作。
+ `metadata_failure_recovery` 的含义是，清空 "bdbje" 的元数据。这样 bdbje 就不会再联系之前的其他 FE
了，而作为一个独立的 FE 启动。这个参数只有在恢复启动时才需要设置为 true。恢复完成后，一定要设置为 false，否则一旦重启，bdbje
的元数据又会被清空，导致其他 FE 无法正常工作。
+ :::
4. 第3步执行成功后，我们再通过 `ALTER SYSTEM DROP FOLLOWER/OBSERVER` 命令，将之前的其他的 FE
从元数据删除后，按加入新 FE 的方式，重新把这些 FE 添加一遍。
diff --git
a/versioned_docs/version-1.2/admin-manual/maint-monitor/metadata-operation.md
b/versioned_docs/version-1.2/admin-manual/maint-monitor/metadata-operation.md
index e783985f83a9..303c54483ae1 100644
---
a/versioned_docs/version-1.2/admin-manual/maint-monitor/metadata-operation.md
+++
b/versioned_docs/version-1.2/admin-manual/maint-monitor/metadata-operation.md
@@ -191,7 +191,7 @@ FE may fail to start bdbje and synchronize between FEs for
some reasons. Phenome
1. If the node is an OBSERVER, first change the `role=OBSERVER` in the
`meta_dir/image/ROLE` file to `role=FOLLOWER`. (Recovery from the OBSERVER node
will be more cumbersome, first follow the steps here, followed by a separate
description)
2. Add configuration in fe.conf: `metadata_failure_recovery=true`.
- 3. Run `sh bin/start_fe.sh` to start the FE
+ 3. Run `sh bin/start_fe.sh --daemon` to start the FE
4. If normal, the FE will start in the role of MASTER, similar to the
description in the previous section `Start a single node FE`. You should see
the words `transfer from XXXX to MASTER` in fe.log.
5. After the start-up is completed, connect to the FE first, and
execute some query imports to check whether normal access is possible. If the
operation is not normal, it may be wrong. It is recommended to read the above
steps carefully and try again with the metadata previously backed up. If not,
the problem may be more serious.
6. If successful, through the `show frontends;` command, you should see
all the FEs you added before, and the current FE is master.
diff --git
a/versioned_docs/version-2.0/admin-manual/maint-monitor/metadata-operation.md
b/versioned_docs/version-2.0/admin-manual/maint-monitor/metadata-operation.md
index 44cde47f605b..30a9ca077232 100644
---
a/versioned_docs/version-2.0/admin-manual/maint-monitor/metadata-operation.md
+++
b/versioned_docs/version-2.0/admin-manual/maint-monitor/metadata-operation.md
@@ -192,22 +192,29 @@ FE may fail to start bdbje and synchronize between FEs
for some reasons. Phenome
1. Modify fe.conf
- If the node is an OBSERVER, first change the `role=OBSERVER` in the
`meta_dir/image/ROLE` file to `role=FOLLOWER`. (Recovery from the OBSERVER node
will be more cumbersome, first follow the steps here, followed by a separate
description)
- If fe.version < 2.0.2, add configuration in fe.conf:
`metadata_failure_recovery=true`.
- 2. Run `sh bin/start_fe.sh --metadata_failure_recovery --daemon` to
start the FE
+ 2. Run `sh bin/start_fe.sh --metadata_failure_recovery --daemon` to
start the FE. (If you are recovering from an OBSERVER node, jump to the
subsequent OBSERVER document after this step.)
3. If normal, the FE will start in the role of MASTER, similar to the
description in the previous section `Start a single node FE`. You should see
the words `transfer from XXXX to MASTER` in fe.log.
4. After the start-up is completed, connect to the FE first, and
execute some query imports to check whether normal access is possible. If the
operation is not normal, it may be wrong. It is recommended to read the above
steps carefully and try again with the metadata previously backed up. If not,
the problem may be more serious.
5. If successful, through the `show frontends;` command, you should see
all the FEs you added before, and the current FE is master.
6. **If FE version < 2.0.2**, delete the `metadata_failure_recovery=true`
configuration item in fe.conf, or set it to `false`, and restart the FE
(**Important**).
- > If you are recovering metadata from an OBSERVER node, after
completing the above steps, you will find that the current FE role is OBSERVER,
but `IsMaster` appears as `true`. This is because the "OBSERVER" seen here is
recorded in Doris's metadata, but whether it is master or not, is recorded in
bdbje's metadata. Because we recovered from an OBSERVER node, there was
inconsistency. Please take the following steps to fix this problem (we will fix
it in a later version):
+ :::tip
+ If you are recovering metadata from an OBSERVER node, after completing
the above steps, you will find that the current FE role is OBSERVER, but
`IsMaster` appears as `true`. This is because the "OBSERVER" seen here is
recorded in Doris's metadata, but whether it is master or not, is recorded in
bdbje's metadata. Because we recovered from an OBSERVER node, there was
inconsistency. Please take the following steps to fix this problem (we will fix
it in a later version):
- > 1. First, all FE nodes except this "OBSERVER" are DROPed out.
- > 2. A new FOLLOWER FE is added through the `ADD FOLLOWER` command,
assuming that it is on hostA.
- > 3. Start a new FE on hostA and join the cluster by `helper`.
- > 4. After successful startup, you should see two FEs through the `show
frontends;` statement, one is the previous OBSERVER, the other is the newly
added FOLLOWER, and the OBSERVER is the master.
- > 5. After confirming that the new FOLLOWER is working properly, the
new FOLLOWER metadata is used to perform a failure recovery operation again.
- > 6. The purpose of the above steps is to manufacture a metadata of
FOLLOWER node artificially, and then use this metadata to restart fault
recovery. This avoids inconsistencies in recovering metadata from OBSERVER.
+ 1. First, all FE nodes except this "OBSERVER" are DROPed out.
- >The meaning of `metadata_failure_recovery` is to empty the metadata of
`bdbje`. In this way, bdbje will not contact other FEs before, but start as a
separate FE. This parameter needs to be set to true only when restoring
startup. After recovery, it must be set to false. Otherwise, once restarted,
the metadata of bdbje will be emptied again, which will make other FEs unable
to work properly.
+ 2. A new FOLLOWER FE is added through the `ADD FOLLOWER` command,
assuming that it is on hostA.
+
+ 3. Start a new FE on hostA and join the cluster by `helper`.
+
+ 4. After successful startup, you should see two FEs through the `show
frontends;` statement, one is the previous OBSERVER, the other is the newly
added FOLLOWER, and the OBSERVER is the master.
+
+ 5. After confirming that the new FOLLOWER is working properly, the new
FOLLOWER metadata is used to perform a failure recovery operation again.
+
+ 6. The purpose of the above steps is to manufacture a metadata of
FOLLOWER node artificially, and then use this metadata to restart fault
recovery. This avoids inconsistencies in recovering metadata from OBSERVER.
+
+ The meaning of `metadata_failure_recovery` is to empty the metadata of
`bdbje`. In this way, bdbje will not contact other FEs before, but start as a
separate FE. This parameter needs to be set to true only when restoring
startup. After recovery, it must be set to false. Otherwise, once restarted,
the metadata of bdbje will be emptied again, which will make other FEs unable
to work properly.
+ :::
4. After the successful execution of step 3, we delete the previous FEs from
the metadata by using the `ALTER SYSTEM DROP FOLLOWER/OBSERVER` command and add
them again by adding new FEs.
diff --git
a/versioned_docs/version-2.1/admin-manual/maint-monitor/metadata-operation.md
b/versioned_docs/version-2.1/admin-manual/maint-monitor/metadata-operation.md
index 7042914e3c9f..f98e5c9bd56c 100644
---
a/versioned_docs/version-2.1/admin-manual/maint-monitor/metadata-operation.md
+++
b/versioned_docs/version-2.1/admin-manual/maint-monitor/metadata-operation.md
@@ -192,22 +192,29 @@ FE may fail to start bdbje and synchronize between FEs
for some reasons. Phenome
1. Modify fe.conf
- If the node is an OBSERVER, first change the `role=OBSERVER` in the
`meta_dir/image/ROLE` file to `role=FOLLOWER`. (Recovery from the OBSERVER node
will be more cumbersome, first follow the steps here, followed by a separate
description)
- If fe.version < 2.0.2, add configuration in fe.conf:
`metadata_failure_recovery=true`.
- 2. Run `sh bin/start_fe.sh --metadata_failure_recovery --daemon` to
start the FE
+ 2. Run `sh bin/start_fe.sh --metadata_failure_recovery --daemon` to
start the FE. (If you are recovering from an OBSERVER node, jump to the
subsequent OBSERVER document after this step.)
3. If normal, the FE will start in the role of MASTER, similar to the
description in the previous section `Start a single node FE`. You should see
the words `transfer from XXXX to MASTER` in fe.log.
4. After the start-up is completed, connect to the FE first, and
execute some query imports to check whether normal access is possible. If the
operation is not normal, it may be wrong. It is recommended to read the above
steps carefully and try again with the metadata previously backed up. If not,
the problem may be more serious.
5. If successful, through the `show frontends;` command, you should see
all the FEs you added before, and the current FE is master.
6. **If FE version < 2.0.2**, delete the `metadata_failure_recovery=true`
configuration item in fe.conf, or set it to `false`, and restart the FE
(**Important**).
- > If you are recovering metadata from an OBSERVER node, after
completing the above steps, you will find that the current FE role is OBSERVER,
but `IsMaster` appears as `true`. This is because the "OBSERVER" seen here is
recorded in Doris's metadata, but whether it is master or not, is recorded in
bdbje's metadata. Because we recovered from an OBSERVER node, there was
inconsistency. Please take the following steps to fix this problem (we will fix
it in a later version):
+ :::tip
+ If you are recovering metadata from an OBSERVER node, after completing
the above steps, you will find that the current FE role is OBSERVER, but
`IsMaster` appears as `true`. This is because the "OBSERVER" seen here is
recorded in Doris's metadata, but whether it is master or not, is recorded in
bdbje's metadata. Because we recovered from an OBSERVER node, there was
inconsistency. Please take the following steps to fix this problem (we will fix
it in a later version):
- > 1. First, all FE nodes except this "OBSERVER" are DROPed out.
- > 2. A new FOLLOWER FE is added through the `ADD FOLLOWER` command,
assuming that it is on hostA.
- > 3. Start a new FE on hostA and join the cluster by `helper`.
- > 4. After successful startup, you should see two FEs through the `show
frontends;` statement, one is the previous OBSERVER, the other is the newly
added FOLLOWER, and the OBSERVER is the master.
- > 5. After confirming that the new FOLLOWER is working properly, the
new FOLLOWER metadata is used to perform a failure recovery operation again.
- > 6. The purpose of the above steps is to manufacture a metadata of
FOLLOWER node artificially, and then use this metadata to restart fault
recovery. This avoids inconsistencies in recovering metadata from OBSERVER.
+ 1. First, all FE nodes except this "OBSERVER" are DROPed out.
- >The meaning of `metadata_failure_recovery` is to empty the metadata of
`bdbje`. In this way, bdbje will not contact other FEs before, but start as a
separate FE. This parameter needs to be set to true only when restoring
startup. After recovery, it must be set to false. Otherwise, once restarted,
the metadata of bdbje will be emptied again, which will make other FEs unable
to work properly.
+ 2. A new FOLLOWER FE is added through the `ADD FOLLOWER` command,
assuming that it is on hostA.
+
+ 3. Start a new FE on hostA and join the cluster by `helper`.
+
+ 4. After successful startup, you should see two FEs through the `show
frontends;` statement, one is the previous OBSERVER, the other is the newly
added FOLLOWER, and the OBSERVER is the master.
+
+ 5. After confirming that the new FOLLOWER is working properly, the new
FOLLOWER metadata is used to perform a failure recovery operation again.
+
+ 6. The purpose of the above steps is to manufacture a metadata of
FOLLOWER node artificially, and then use this metadata to restart fault
recovery. This avoids inconsistencies in recovering metadata from OBSERVER.
+
+ The meaning of `metadata_failure_recovery` is to empty the metadata of
`bdbje`. In this way, bdbje will not contact other FEs before, but start as a
separate FE. This parameter needs to be set to true only when restoring
startup. After recovery, it must be set to false. Otherwise, once restarted,
the metadata of bdbje will be emptied again, which will make other FEs unable
to work properly.
+ :::
4. After the successful execution of step 3, we delete the previous FEs from
the metadata by using the `ALTER SYSTEM DROP FOLLOWER/OBSERVER` command and add
them again by adding new FEs.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
