You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by wu...@apache.org on 2021/04/26 06:09:59 UTC

[shardingsphere-elasticjob] branch master updated: Update elastic.en.md (#1878)

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

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


The following commit(s) were added to refs/heads/master by this push:
     new 77d698c  Update elastic.en.md (#1878)
77d698c is described below

commit 77d698c637fea5863319e2068e26fd56ac8e09e1
Author: 猿人谷 <he...@sina.com>
AuthorDate: Mon Apr 26 14:09:50 2021 +0800

    Update elastic.en.md (#1878)
---
 docs/content/features/elastic.en.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/content/features/elastic.en.md b/docs/content/features/elastic.en.md
index 5c2e417..2091462 100644
--- a/docs/content/features/elastic.en.md
+++ b/docs/content/features/elastic.en.md
@@ -40,7 +40,7 @@ When new job server joins, ElasticJob will be aware of it from the registry, and
 
 Configuring a larger number of sharding items than the number of servers, or better, a multiplier of the number of servers, makes it more reasonably for the job to leverage the resources, and assign the sharding items dynamically.
 
-For example, we have 10 sharding items and there are 3 servers, the number of sharding items are server A = 0,1,2; server B = 3,4,5; server C = 6,7,8,9.
+For example, we have 10 sharding items and there are 3 servers, the number of sharding items are server A = 0,1,2,9; server B = 3,4,5; server C = 6,7,8.
 If the server C is down, then server A = 0,1,2,3,4 and B = 5,6,7,8,9, maximizing the throughput without losing any sharding item.
 
 ## High Availability