Merge pull request #244 from percona/pxc-4702

PXC-4702 [DOCS] - Update restarting-nodes.md 8.4

Author: patrickbirch

docs/restarting-nodes.md

@@ -1,20 +1,19 @@
 # Restart the cluster nodes
 
-To restart a cluster node, shut down MySQL and restarting it.
-The node should leave the cluster
-(and the total vote count for [quorum](glossary.md#quorum) should decrement).
+To restart a cluster node, shut down MySQL and restart the service. The node leaves the cluster, reducing the total vote count for quorum. 
 
-When it rejoins, the node should synchronize using [IST](glossary.md#ist).
-If the set of changes needed for IST are not found in the `gcache` file
-on any other node in the entire cluster,
-then [SST](glossary.md#sst) will be performed instead.
-Therefore, restarting cluster nodes for rolling configuration changes
-or software upgrades is rather simple from the cluster’s perspective.
+The quorum refers to the minimum number of votes required for the cluster to operate effectively and make decisions. Each node in the cluster typically represents one vote. When a node leaves the cluster, the total number of votes decreases, affecting the cluster's ability to achieve quorum. If the cluster does not maintain quorum, it may become unable to process transactions or make changes, potentially leading to a split-brain scenario where different parts of the cluster operate independently.
 
-!!! note
+Upon rejoining, the node synchronizes using IST (Incremental State Transfer). IST allows the node to catch up with the current state of the cluster by transferring only the changes that occurred while the node was offline. If the necessary changes for IST do not exist in the `gcache` file on any other node within the cluster, the process will perform SST (State Snapshot Transfer) instead. SST involves transferring a complete database snapshot to the node, which can be more time-consuming but ensures that the node receives all data. This approach makes restarting cluster nodes for rolling configuration changes, or software upgrades straightforward from the cluster’s perspective. 
 
-    If you restart a node with an invalid configuration change that prevents MySQL from loading, Galera will drop the node’s state and force an SST for that node.
+If a node restarts with an invalid configuration change that prevents MySQL from loading, Galera drops the node’s state and forces an SST for that node.
 
-!!! note
+In the event of a MySQL failure, the system does not remove the PID file because the system deletes this file only during a clean shutdown. As a result, the server does not restart if an existing PID file is present. When MySQL encounters a failure, check the log records for details. You must remove the PID file manually. 
 
-    If MySQL fails for any reason, it will not remove its PID file (which is by design deleted only on clean shutdown). Obviously server will not restart if existing PID file is present. So in case of encountered MySQL failure for any reason with the relevant records in log, PID file should be removed manually.
+Use the `rm` command in a Unix/Linux shell to do this:
+
+```{.bash .data-prompt="$"}
+$ bash rm /path/to/mysql.pid
+```
+
+Replace `/path/to/mysql.pid` with the actual path to your MySQL PID file. The default location for the PID file is often `/var/run/mysqld/mysqld.pid` or `/var/lib/mysql/mysql.pid`, but this can vary based on your configuration. Before executing this command, ensure that MySQL is not running, as removing the PID file while the server is active can lead to issues.