[incubator-kvrocks-website] branch main updated: Some cleanups in docs (#65)

[tw...@apache.org]

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

twice pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-kvrocks-website.git


The following commit(s) were added to refs/heads/main by this push:
     new c85266f  Some cleanups in docs (#65)
c85266f is described below

commit c85266faf30d46f722457555f993c767043664ff
Author: Binbin <bi...@qq.com>
AuthorDate: Mon Mar 20 20:32:46 2023 +0800

    Some cleanups in docs (#65)
    
    - Corrected CLUSTERX commands to CLUSTERX
    - Use `` to wrap commands
    - Fix typo
---
 docs/cluster.md                           | 10 +++++-----
 docs/namespace.md                         |  2 +-
 docs/replication.md                       |  6 +++---
 src/components/HomepageFeatures/index.tsx |  2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/docs/cluster.md b/docs/cluster.md
index 6606deb..87f721f 100644
--- a/docs/cluster.md
+++ b/docs/cluster.md
@@ -41,7 +41,7 @@ where
 - `$master_node_id`: set to the master node id when the current node's role is a slave; `-` if it's master
 - `$slot_range`: slots are served by current node, the format can be the range or single value, like `0-100 200 205`, which means slots 0 to 100, 200 and 205 are served by this node
 
-`$VERSION` is the topology information version used to control update the order. The topology information can be updated iff the version is newer than the current version.
+`$VERSION` is the topology information version used to control update the order. The topology information can be updated if the version is newer than the current version.
 
 `$FORCE` (0 or 1) indicates force update the topology information without verifying the version, you can use this flag when the topology information is totally broken. For example:
 
@@ -65,7 +65,7 @@ For a complete cluster solution, we need to depend on another controller to mana
 
 ## Client access
 
-Users can use Redis Cluster SDK to access the Kvrocks cluster since it's compatible with the Redis cluster solution(Kvrocks supported `CLUSTER NODES` and `CLUSTER SLOTS` command to respond to the cluster topology).  Kvrocks also responds to the `MOVED $slot_id $ip:$port` to redirect the target node when the slot is NOT served by the current node. You can also use the Redis Cluster Proxy like `redis-cluster-proxy` to hide the cluster topology.
+Users can use Redis Cluster SDK to access the Kvrocks cluster since it's compatible with the Redis cluster solution(Kvrocks supported `CLUSTER NODES` and `CLUSTER SLOTS` commands to respond to the cluster topology).  Kvrocks also responds to the `MOVED $slot_id $ip:$port` to redirect the target node when the slot is NOT served by the current node. You can also use the Redis Cluster Proxy like `redis-cluster-proxy` to hide the cluster topology.
 
 ## Deploy and operate
 
@@ -73,7 +73,7 @@ Users need to self-manage the cluster topology information since the Kvrocks con
 
 1. Deploy Kvrocks nodes
 2. Design the kvrocks topology which is mentioned at [topology management](#topology-management)
-3. Set node unique id for each node by using `CLUSTER SETNODEID` command
+3. Set node unique id for each node by using `CLUSTERX SETNODEID` command
 4. Apply the topology information to all nodes by using `CLUSTER NODES` command
 
 Kvrocks would auto-setup the master-slave replication after receiving the setup topology command, and repeats steps 2-4 when we want to switch the node role or number.
@@ -88,9 +88,9 @@ To guarantee the correctness of client SDK, we rename the `CLUSTER` command to `
 
 Kvrocks data migration is based on the slot instead of on key like Redis, we can migrate one slot to another node at once.
 
-Kvrocks storage is based on disk instead of memory, so the key migration may be time cost. Now, the controller/DBA can use `CLUSTER MIGRATE` command to migrate slots.
+Kvrocks storage is based on disk instead of memory, so the key migration may be time cost. Now, the controller/DBA can use `CLUSTERX MIGRATE` command to migrate slots.
 
-After `CLUSTERX MIGRATE` command to migrate the slot, you should use `CLUSTER SETSLOT` to modify the topology information:
+After `CLUSTERX MIGRATE` command to migrate the slot, you should use `CLUSTERX SETSLOT` to modify the topology information:
 
 ```shell
 CLUSTERX SETSLOT $slot NODE $node_id $new_version
diff --git a/docs/namespace.md b/docs/namespace.md
index 08652f0..4a001de 100644
--- a/docs/namespace.md
+++ b/docs/namespace.md
@@ -31,7 +31,7 @@ Be careful that you must use the `config rewrite` command to persist the new nam
 
 ## Switch Namespace
 
-Firstly, we use the namespace command to create namespace `ns1` and `ns2` with the corresponding tokens `token1` and `token2`.
+Firstly, we use the `namespace add` command to create namespace `ns1` and `ns2` with the corresponding tokens `token1` and `token2`.
 
 ```shell
 127.0.0.1:6666> namespace add ns1 token1
diff --git a/docs/replication.md b/docs/replication.md
index c7f08a0..1c1a566 100644
--- a/docs/replication.md
+++ b/docs/replication.md
@@ -25,11 +25,11 @@ On the slave side, replication is composed of the following steps:
 
 ## Partial Synchronization (PSYNC)
 
-PSYNC takes advantage of the rocksdb's WAL iterator. If the requesting sequence number of PSYNC is in the range of the WAL files, PSYNC is considered viable.
+`PSYNC` takes advantage of the rocksdb's WAL iterator. If the requesting sequence number of `PSYNC` is in the range of the WAL files, `PSYNC` is considered viable.
 
-PSYNC is a command implemented on master role instance. Unlike other commands (e.g. GET), PSYNC cmd is not a REQ-RESP command, but a REQ-RESP-RESP style. That's the response never ends once the req is accepted.
+`PSYNC` is a command implemented on master role instance. Unlike other commands (e.g. `GET`), `PSYNC` cmd is not a REQ-RESP command, but a REQ-RESP-RESP style. That's the response never ends once the req is accepted.
 
-So, PSYNC has two main parts in the code:
+So, `PSYNC` has two main parts in the code:
 
 * libevent callback: This is for sending the batches when the WAL iterator has new data.
 * timer callback: When the libevent callback quited because of the exhaustion of the WAL data, the timer callback will check if WAL has new data available from time to time, so to awake the libevent callback again.
diff --git a/src/components/HomepageFeatures/index.tsx b/src/components/HomepageFeatures/index.tsx
index 0ec5f60..ba00aac 100644
--- a/src/components/HomepageFeatures/index.tsx
+++ b/src/components/HomepageFeatures/index.tsx
@@ -36,7 +36,7 @@ const FeatureList: FeatureItem[] = [
     title: 'High Available',
     description: (
       <>
-        Support redis sentinel to failover when master or slave was failed.
+        Support Redis sentinel to failover when master or slave was failed.
       </>
     ),
   },