review mysql,percona,proxy

Signed-off-by: Bonusree <[email protected]>

Author: Bonusree

docs/examples/mariadb/restart/MariaDB.yaml

@@ -0,0 +1,17 @@
+apiVersion: kubedb.com/v1
+kind: MariaDB
+metadata:
+  name: mariadb
+  namespace: demo
+spec:
+  version: "10.5.23"
+  replicas: 3
+  storageType: Durable
+  storage:
+    storageClassName: standard
+    accessModes:
+      - ReadWriteOnce
+    resources:
+      requests:
+        storage: 1Gi
+  deletionPolicy: WipeOut

docs/examples/redis/restart/redis.yaml

@@ -13,7 +13,7 @@ spec:
     resources:
       requests:
         storage: 1Gi
-    storageClassName: local-path
+    storageClassName: standard
     accessModes:
       - ReadWriteOnce
   deletionPolicy: WipeOut

docs/guides/mariadb/restart/restart.md

@@ -46,7 +46,6 @@ spec:
   replicas: 3
   storageType: Durable
   storage:
-    storageClassName: local-path
     accessModes:
       - ReadWriteOnce
     resources:
@@ -58,7 +57,7 @@ spec:
 Let's create the `MariaDB` CR we have shown above,
 
 ```bash
-$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/MariaDB/restart/MariaDB.yaml
+$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mariadb/restart/MariaDB.yaml
 MariaDB.kubedb.com/mariadb created
 ```
 
@@ -81,10 +80,10 @@ spec:
 - `spec.type` specifies the Type of the ops Request
 - `spec.databaseRef` holds the name of the MariaDB database.  The db should be available in the same namespace as the opsRequest
 - The `spec.timeout` field specifies the maximum amount of time the operator will wait for the operation to complete before marking it as failed. 
-- The `spec.apply` field determines whether the operation should always be applied (Always) or only when there are changes (IfReady).
+- The `spec.apply` field determines whether the operation should always be applied (Always) or if the database phase is ready (IfReady).
 
 
-> Note: The method of restarting the standalone & cluster mode db is exactly same as above. All you need, is to specify the corresponding MairiDB name in `spec.databaseRef.name` section.
+> Note: The method of restarting the standalone & cluster mode db is exactly same as above. All you need, is to specify the corresponding MariaDB name in `spec.databaseRef.name` section.
 
 Let's create the `MariaDBOpsRequest` CR we have shown above,
 
@@ -95,7 +94,6 @@ MariaDBopsrequest.ops.kubedb.com/restart created
 ```
 
 In `MariaDB`, all pods act as primary, so the Ops-manager operator will restart the pods one by one in sequence.
-> Note: This will not restart the arbiter pod if you have one. Arbiter pod doesn't have any data related to your database. So you can ignore restarting this pod because no restart is necessary for arbiter pod but if you want so, just kubectl delete the arbiter pod (dbName-arbiter-0) in order to restart it.
 
 ```shell
 $ kubectl get mariaops -n demo restart 

docs/guides/mysql/restart/restart.md

@@ -82,7 +82,7 @@ spec:
 - `spec.type` specifies the Type of the ops Request
 - `spec.databaseRef` holds the name of the MySQL database.  The db should be available in the same namespace as the opsRequest
 - The `spec.timeout` field specifies the maximum amount of time the operator will wait for the operation to complete before marking it as failed.
-- The `spec.apply` field determines whether the operation should always be applied (Always) or only when there are changes (IfReady).
+- The `spec.apply` field determines whether the operation should always be applied (Always) or if the database phase is ready (IfReady).
 
 Let's create the `MySQLOpsRequest` CR we have shown above,
 
@@ -96,8 +96,7 @@ In MySQL, pods follow a `primary-standby` architecture:
 - The `primary` pod is restarted last.
 - During the primary pod restart, one of the standby pods is automatically promoted to primary to ensure continuous availability.
 
-> Note: This will not restart the arbiter pod if you have one. Arbiter pod doesn't have any data related to your database. So you can ignore restarting this pod because no restart is necessary for arbiter pod but if you want so, just kubectl delete the arbiter pod (dbName-arbiter-0) in order to restart it.
-
+Now, let's see the status of the `MySQLOpsRequest` we just created.
 ```shell
 $ kubectl get myops -n demo
 NAME      TYPE      STATUS       AGE

docs/guides/percona-xtradb/restart/index.md

@@ -50,7 +50,6 @@ spec:
   replicas: 3
   storageType: Durable
   storage:
-    storageClassName: "local-path"
     accessModes:
       - ReadWriteOnce
     resources:
@@ -141,7 +140,7 @@ Here,
 
 - `spec.timeout` the maximum time the operator will wait for the operation to finish before marking it as failed.
 
-- `spec.apply` determines whether to always apply the operation (Always) or only if there are changes (IfReady).
+- `spec.apply` determines whether to always apply the operation (Always) or  if the database phase is ready (IfReady).
 
 Let's create the `PerconaXtraDBOpsRequest` CR we have shown above,
 
@@ -174,7 +173,6 @@ pxc-1   2/2     Running       0          42s
 pxc-2   2/2     Terminating   0          56m
 
 ```
-> Note: The arbiter pod (if any) is not restarted by the operator. The arbiter doesn’t store any database data, so it doesn’t require a restart. If you want to restart it manually, simply run kubectl delete pod <db-name>-arbiter-0.
 
 ```shell
 $ kubectl get PerconaXtraDBopsrequest -n demo

docs/guides/percona-xtradb/restart/yamls/pxc.yaml

@@ -8,7 +8,7 @@ spec:
   replicas: 3
   storageType: Durable
   storage:
-    storageClassName: "local-path"
+    storageClassName: "standard"
     accessModes:
       - ReadWriteOnce
     resources: