This is an automated email from the ASF dual-hosted git repository.
wangdan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-pegasus-website.git
The following commit(s) were added to refs/heads/master by this push:
new fc42ea1e Update whitelist docs (#77)
fc42ea1e is described below
commit fc42ea1e35c4813bbac82333d0ee8f1ef3b5e1b5
Author: Yingchun Lai <[email protected]>
AuthorDate: Tue Feb 6 14:36:28 2024 +0800
Update whitelist docs (#77)
---
_data/en/translate.yml | 2 +-
_data/zh/translate.yml | 2 +-
_docs/en/administration/whitelist.md | 48 +++++++++++++++++++++++++++++++++++-
_docs/zh/administration/whitelist.md | 46 +++++++++++++++++-----------------
4 files changed, 72 insertions(+), 26 deletions(-)
diff --git a/_data/en/translate.yml b/_data/en/translate.yml
index f9e1be32..a944723e 100644
--- a/_data/en/translate.yml
+++ b/_data/en/translate.yml
@@ -67,7 +67,7 @@ title_experiences: "Experiences"
title_manual-compact: "Manual Compact"
title_usage-scenario: "Usage Scenario"
title_bad-disk: "Bad Disk Repair"
-title_whitelist: "Whitelist"
+title_whitelist: "Replica Server Whitelist"
title_backup-request: "Backup Request"
title_docs: "The Pegasus documentation"
title_tools: "Tools"
diff --git a/_data/zh/translate.yml b/_data/zh/translate.yml
index 25ac85da..a8711c78 100644
--- a/_data/zh/translate.yml
+++ b/_data/zh/translate.yml
@@ -67,7 +67,7 @@ title_experiences: "运维经验"
title_manual-compact: "Manual Compact功能"
title_usage-scenario: "Usage Scenario功能"
title_bad-disk: "坏盘检修"
-title_whitelist: "白名单"
+title_whitelist: "Replica Server 白名单"
title_backup-request: "Backup Request"
title_docs: "Pegasus产品文档"
title_tools: "生态工具"
diff --git a/_docs/en/administration/whitelist.md
b/_docs/en/administration/whitelist.md
index 1022039a..4c367d4a 100644
--- a/_docs/en/administration/whitelist.md
+++ b/_docs/en/administration/whitelist.md
@@ -2,4 +2,50 @@
permalink: administration/whitelist
---
-TRANSLATING
+# Introduction
+
+The Pegasus Replica Server whitelist function is used to prevent unexpected
Replica Server joining the cluster. For example:
+1. The offline Replica Server was restarted unexpectedly and rejoined the
cluster
+2. The Meta Server list configured on Replica Server is incorrect, causing it
to join to another cluster unexpectedly
+
+When the Replica Server whitelist function is disabled, any Replica Server
could join a cluster if configure the corresponding Meta Server list.
+
+When the Replica Server whitelist function is enabled, Meta Server only allows
Replica Servers in the Replica Server whitelist to join the cluster.
+
+# How to use the Replica Server whitelist
+
+## Configuration
+
+Configure `[meta_server].enable_white_list` and
`[meta_server].replica_white_list`, use `,` to separate multiple servers:
+```
+[meta_server]
+ enable_white_list = true
+ replica_white_list = 127.0.0.1:34801,127.0.0.2:34801
+```
+
+## Query
+
+After updating the whitelist configuration, it is necessary to restart the
Meta Server to take effect, it can be queried through shell tools [Remote
commands](remote-commands) or [HTTP API](/api/http).
+
+Taking remote_command as an example:
+```
+>>> remote_command -t meta-server fd.allow_list
+```
+
+# Scale-in and scale-out
+
+When the Replica Server whitelist is enabled, scaling operations need to
consider the impact of this feature.
+
+## Scale-out
+
+Because the newly added Replica Server needs to communicate with Meta Server,
if the Replica Server whitelist has not been updated, it will cause the Meta
Server to reject the new Replica Server from joining the cluster.
+
+So, for the scale-out steps of a cluster with the Replica Server whitelist
function enabled, the following steps need to be taken before [Scale out
steps](/administration/scale-in-out#scale-out-steps):
+1. Add the new Replica Servers to the Replica Server whitelist configuration
on the Meta Server
+2. Restart Meta Server to take effect
+
+## Scale-in
+
+In [Scale in steps](/administration/scale-in-out#scale-in-steps), whether
update the Replica Server whitelist has no impact, the updating can be done at
any time after the scaling is completed.
+
+But for safety reasons, it is recommended to update the Replica Server
whitelist in a timely manner. Just before the final step (i.e. _Restart the
meta server_) of the scaling process, update the Replica Server whitelist
configuration of the Meta Server.
diff --git a/_docs/zh/administration/whitelist.md
b/_docs/zh/administration/whitelist.md
index b6c74685..9afaae33 100644
--- a/_docs/zh/administration/whitelist.md
+++ b/_docs/zh/administration/whitelist.md
@@ -2,50 +2,50 @@
permalink: administration/whitelist
---
-## 介绍
+# 介绍
-Pegasus的白名单功能用来防止非预期的replica server加入集群。例如：
-1. 已stop的replica server因外因重启后，加入集群；
-2. replica server配置的meta server地址有误，加入别的集群。
+Pegasus 的 Replica Server 白名单功能用来防止非预期的 Replica Server 加入到集群。例如：
+1. 已下线的 Replica Server 非预期重启后，重新加入集群
+2. Replica Server 配置的 Meta Server 地址有误，导致它加入到了别的集群
-白名单功能禁用时，任何replica server只需要配置meta server地址，就可以被加入该集群。
+Replica Server 白名单功能未开启时，任何 Replica Server 只需要配置对应集群的 Meta Server 地址，就可以加入该集群。
-白名单功能开启时，meta server只允许白名单中的replica server(ip:port)加入集群。
+Replica Server 白名单功能开启时，Meta Server 只允许 Replica Server 白名单中的 Replica Server
加入集群。
-## 怎样开启白名单
+# Replica Server 白名单使用方式
-### 配置
+## 配置
-配置 [meta_server].enable_white_list 与
[meta_server].replica_white_list，多个ip用','分隔：
+配置 `[meta_server].enable_white_list` 与
`[meta_server].replica_white_list`，多个服务器使用 `,` 分隔：
```
[meta_server]
enable_white_list = true
replica_white_list = 127.0.0.1:34801,127.0.0.2:34801
```
-### 查询
+## 查询
-白名单在meta server运行过程中不允许更改，只能通过修改配置并重启来修改。但是可以通过shell的remote_command来查询。
+Replica Server 白名单配置修改后需要重启 Meta Server 生效。可以通过 shell 工具的 [Remote
commands](remote-commands) 或 [HTTP API](/api/http) 来查询。
-示例：
+以 remote_command 为例：
```
->>> remote_command -t meta-server meta.fd.allow_list
+>>> remote_command -t meta-server fd.allow_list
```
-## 开启白名单的扩缩容
+# 扩缩容
-在白名单开启后，扩缩容操作需要考虑白名单的影响。
+在 Replica Server 白名单开启后，扩缩容操作需要考虑该功能的影响。
-### 扩容
+## 扩容
-由于扩容需replica server先与meta server通信，如果此时白名单未更新，会导致meta server拒绝这个新replica
server加入集群。
+由于扩容的 Replica Server 需要与 Meta Server 通信，如果此时 Replica Server 白名单尚未更新，会导致 Meta
Server 拒绝这个新 Replica Server 加入集群。
-所以，开启白名单的集群扩容步骤，需要在普通[扩容流程](/administration/scale-in-out#扩容流程)前，进行一下步骤：
-1. 修改meta server白名单配置，加入新replica servers
-2. 重启meta server
+所以，对于开启了 Replica Server 白名单功能的集群的扩容步骤，需要在
[扩容流程](/administration/scale-in-out#扩容流程) 前，进行以下步骤：
+1. 修改 Meta Server 的 Replica Server 白名单配置，加入需要扩容的 Replica Server
+2. 重启 Meta Server 使其生效
-### 缩容
+## 缩容
-[缩容流程](/administration/scale-in-out#扩容流程)中，白名单不会造成任何影响。白名单的更新也可以在缩容完成之后任意时刻进行。
+在 [缩容流程](/administration/scale-in-out#缩容流程) 中，Replica Server
白名单不会造成任何影响。Replica Server 白名单的更新可以在缩容完成之后任意时刻进行。
-但为了安全，建议及时更新白名单。只需在缩容流程的最后一步“重启meta server”前，修改meta server的白名单配置。
\ No newline at end of file
+但为了安全，建议及时更新 Replica Server 白名单。只需在缩容流程的最后一步（即：_重启 Meta Server_）前，修改 Meta
Server 的 Replica Server 白名单配置。
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
