chore: remove redundant words

Signed-off-by: camcui <[email protected]>
kubedb · Feb 7, 2025 · c56b026 · c56b026
1 parent 2366860
commit c56b026
Show file tree

Hide file tree

Showing 11 changed files with 11 additions and 11 deletions.
diff --git a/docs/guides/mariadb/pitr/nfs/index.md b/docs/guides/mariadb/pitr/nfs/index.md
@@ -471,7 +471,7 @@ MariaDB [hello]> select count(*) from demo_table;
 
 ## Point-in-time Recovery
 Point-In-Time Recovery allows you to restore a MariaDB database to a specific point in time using the archived transaction logs. This is particularly useful in scenarios where you need to recover to a state just before a specific error or data corruption occurred.
-Let's say accidentally our dba drops the the table demo_table and we want to restore.
+Let's say accidentally our dba drops the table demo_table and we want to restore.
 
 ```bash
 $ kubectl exec -it -n demo  mariadb-0 -- bash

diff --git a/docs/guides/mariadb/pitr/overview/index.md b/docs/guides/mariadb/pitr/overview/index.md
@@ -332,7 +332,7 @@ MariaDB [hello]> select count(*) from demo_table;
 
 ## Point-in-time Recovery
 Point-In-Time Recovery allows you to restore a MariaDB database to a specific point in time using the archived transaction logs. This is particularly useful in scenarios where you need to recover to a state just before a specific error or data corruption occurred.
-Let's say accidentally our dba drops the the table demo_table and we want to restore.
+Let's say accidentally our dba drops the table demo_table and we want to restore.
 
 ```bash
 $ kubectl exec -it -n demo  mariadb-0 -- bash

diff --git a/docs/guides/mongodb/arbiter/replicaset.md b/docs/guides/mongodb/arbiter/replicaset.md
@@ -683,7 +683,7 @@ persistentvolumeclaim/datadir-mongo-arb-arbiter-0   Bound    pvc-169fd172-0e41-4
 
 ## Resume Halted Database
 
-Now, to resume the database, i.e. to get the same database setup back again, you have to set the the `spec.halted` as false. You can use the below command.
+Now, to resume the database, i.e. to get the same database setup back again, you have to set the `spec.halted` as false. You can use the below command.
 
 ```bash
 $ kubectl patch -n demo mg/mongo-arb  -p '{"spec":{"halted":false}}' --type="merge"

diff --git a/docs/guides/mongodb/clustering/replicaset.md b/docs/guides/mongodb/clustering/replicaset.md
@@ -573,7 +573,7 @@ persistentvolumeclaim/datadir-mgo-replicaset-2   Bound    pvc-5a50bce3-f85f-4157
 
 ## Resume Halted Database
 
-Now, to resume the database, i.e. to get the same database setup back again, you have to set the the `spec.halted` as false. You can use the below command.
+Now, to resume the database, i.e. to get the same database setup back again, you have to set the `spec.halted` as false. You can use the below command.
 
 ```bash
 $ kubectl patch -n demo mg/mgo-replicaset -p '{"spec":{"halted":false}}' --type="merge"

diff --git a/docs/guides/mongodb/clustering/sharding.md b/docs/guides/mongodb/clustering/sharding.md
@@ -657,7 +657,7 @@ From the above output, you can see that MongoDB object, PVCs, Secret are still t
 
 ## Resume Halted Database
 
-Now, to resume the database, i.e. to get the same database setup back again, you have to set the the `spec.halted` as false. You can use the below command.
+Now, to resume the database, i.e. to get the same database setup back again, you have to set the `spec.halted` as false. You can use the below command.
 
 ```bash
 $ kubectl patch -n demo mg/mongo-sh -p '{"spec":{"halted":false}}' --type="merge"

diff --git a/docs/guides/mongodb/quickstart/quickstart.md b/docs/guides/mongodb/quickstart/quickstart.md
@@ -484,7 +484,7 @@ persistentvolumeclaim/datadir-mgo-quickstart-2   Bound    pvc-2e6dfb71-056b-4186
 
 ## Resume Halted Database
 
-Now, to resume the database, i.e. to get the same database setup back again, you have to set the the `spec.halted` as false. You can use the below command.
+Now, to resume the database, i.e. to get the same database setup back again, you have to set the `spec.halted` as false. You can use the below command.
 
 ```bash
 $ kubectl patch -n demo mg/mgo-quickstart -p '{"spec":{"halted":false}}' --type="merge"

diff --git a/docs/guides/mongodb/scaling/horizontal-scaling/sharding.md b/docs/guides/mongodb/scaling/horizontal-scaling/sharding.md
@@ -998,7 +998,7 @@ NAME                     TYPE                STATUS       AGE
 mops-hscale-down-shard   HorizontalScaling   Successful   81s
 ```
 
-We can see from the above output that the `MongoDBOpsRequest` has succeeded. If we describe the `MongoDBOpsRequest` we will get an overview of the steps that were followed to scale down the the database.
+We can see from the above output that the `MongoDBOpsRequest` has succeeded. If we describe the `MongoDBOpsRequest` we will get an overview of the steps that were followed to scale down the database.
 
 ```bash
 $ kubectl describe mongodbopsrequest -n demo mops-hscale-down-shard                     

diff --git a/docs/guides/mysql/pitr/restic/archiver.md b/docs/guides/mysql/pitr/restic/archiver.md
@@ -314,7 +314,7 @@ mysql> select count(*) from demo_table;
 
 ## Point-in-time Recovery
 Point-In-Time Recovery allows you to restore a MySQL database to a specific point in time using the archived transaction logs. This is particularly useful in scenarios where you need to recover to a state just before a specific error or data corruption occurred.
-Let's say accidentally our db drops the the table `demo_table` and we want to restore that.
+Let's say accidentally our db drops the table `demo_table` and we want to restore that.
 
 ```bash
 $ kubectl exec -it -n demo  mysql-0 -- bash

diff --git a/docs/guides/postgres/arbiter/arbiter.md b/docs/guides/postgres/arbiter/arbiter.md
@@ -86,7 +86,7 @@ ha-postgres-0           2/2     Running   0          84s
 ha-postgres-1           2/2     Running   0          78s
 ha-postgres-arbiter-0   1/1     Running   0          68s
 ```
-Get the the pvc,
+Get the pvc,
 
 ```bash
 kubectl get pvc -n demo

diff --git a/docs/guides/postgres/pitr/archiver.md b/docs/guides/postgres/pitr/archiver.md
@@ -314,7 +314,7 @@ hi=# select count(*) from tab_1 ;
 
 ## Point-in-time Recovery
 Point-In-Time Recovery allows you to restore a PostgreSQL database to a specific point in time using the archived transaction logs. This is particularly useful in scenarios where you need to recover to a state just before a specific error or data corruption occurred.
-Let's say accidentally our dba drops the the table tab_1 and we want to restore.
+Let's say accidentally our dba drops the table tab_1 and we want to restore.
 
 ```bash
 $ kubectl exec -it -n demo  demo-pg-0 -- bash

diff --git a/docs/guides/proxysql/concepts/declarative-configuration/index.md b/docs/guides/proxysql/concepts/declarative-configuration/index.md
@@ -29,7 +29,7 @@ User will provide the configuration under the `.spec.initConfig` section of the
 <figcaption align="center">Fig: ProxySQL Configuration Secret Lifecycle</figcaption>
 </figure>
 
-At any time the user might need to change the configuration. To serve that purpose we have introduced ProxySQLOpsRequest. When an ops request is being created, the `KubeDB` Ops Manager updates the configuration secret and applies the changes to the proxysql cluster nodes. This is how the the configuration secret remains as a source of truth for the ProxySQL CRO and any changes are made in a declarative way. 
+At any time the user might need to change the configuration. To serve that purpose we have introduced ProxySQLOpsRequest. When an ops request is being created, the `KubeDB` Ops Manager updates the configuration secret and applies the changes to the proxysql cluster nodes. This is how the configuration secret remains as a source of truth for the ProxySQL CRO and any changes are made in a declarative way. 
 
 > User can exec into any proxysql pod and change any configuration from the admin panel anytime. But that won't update the configuration secret. We recommend the ops-request to keep things declarative and keep the proxysql.cnf file always updated.