Fixing README instructions for split-brain

Signed-off-by: Aaron Layfield <aaron.layfield@gmail.com>

Author: DandyDeveloper

charts/redis-ha/README.md

@@ -463,15 +463,15 @@ Should your Pod require additional egress rules, define them in a `egressRules`
 
 ## Sentinel and redis server split brain detection
 
-Under not entirely known yet circumstances redis sentinel and its corresponding redis server reach a condition that this chart authors call "split brain" (for short). The observed behaviour is the following: the sentinel switches to the new re-elected master, but does not switch its redis server. Majority of original discussion on the problem has happened at the <https://github.com/DandyDeveloper/charts/issues/121>.
+Under not entirely known yet circumstances redis sentinel and its corresponding redis server reach a condition that this chart authors call "split brain" (for short). The observed behaviour is the following: the sentinel switches to the new re-elected master, but does not switch its redis server. Majority of original discussion on the problem has happened at the #121.
 
 The proposed solution is currently implemented as a sidecar container that runs a bash script with the following logic:
 
-1. Every `splitBrainDetection.interval` seconds a master (as known by sentinel) is determined
-1. If it is the current node: ensure the redis server's role is master as well.
-1. If it is not the current node: ensure the redis server also replicates from the same node.
-
-If any of the checks above fails - the redis server reinitialisation happens (it regenerates configs the same way it's done during the pod init), and then the redis server is instructed to shutdown. Then kubernetes restarts the container immediately.
+1. At intervals defined by splitBrainDetection.interval, the sidecar checks which node is recognized as master by Sentinel.
+2. If the current pod is the master according to Sentinel, it verifies that the local Redis server is also running as master.
+3. If the current pod is not the master, it ensures the local Redis server is replicating from the correct master node.
+4. If any of these checks fail, the sidecar will retry the check at intervals defined by splitBrainDetection.retryInterval.
+5. If the checks continue to fail after the retry attempts, the sidecar triggers a reinitialization: it regenerates the Redis configuration and instructs the Redis server to shut down. Kubernetes will then automatically restart the container.
 
 # Change Log
 

charts/redis-ha/README.md.gotmpl

@@ -214,15 +214,15 @@ Should your Pod require additional egress rules, define them in a `egressRules`
 
 ## Sentinel and redis server split brain detection
 
-Under not entirely known yet circumstances redis sentinel and its corresponding redis server reach a condition that this chart authors call "split brain" (for short). The observed behaviour is the following: the sentinel switches to the new re-elected master, but does not switch its redis server. Majority of original discussion on the problem has happened at the <https://github.com/DandyDeveloper/charts/issues/121>.
+Under not entirely known yet circumstances redis sentinel and its corresponding redis server reach a condition that this chart authors call "split brain" (for short). The observed behaviour is the following: the sentinel switches to the new re-elected master, but does not switch its redis server. Majority of original discussion on the problem has happened at the #121.
 
 The proposed solution is currently implemented as a sidecar container that runs a bash script with the following logic:
 
-1. Every `splitBrainDetection.interval` seconds a master (as known by sentinel) is determined
-1. If it is the current node: ensure the redis server's role is master as well.
-1. If it is not the current node: ensure the redis server also replicates from the same node.
-
-If any of the checks above fails - the redis server reinitialisation happens (it regenerates configs the same way it's done during the pod init), and then the redis server is instructed to shutdown. Then kubernetes restarts the container immediately.
+1. At intervals defined by splitBrainDetection.interval, the sidecar checks which node is recognized as master by Sentinel.
+2. If the current pod is the master according to Sentinel, it verifies that the local Redis server is also running as master.
+3. If the current pod is not the master, it ensures the local Redis server is replicating from the correct master node.
+4. If any of these checks fail, the sidecar will retry the check at intervals defined by splitBrainDetection.retryInterval.
+5. If the checks continue to fail after the retry attempts, the sidecar triggers a reinitialization: it regenerates the Redis configuration and instructs the Redis server to shut down. Kubernetes will then automatically restart the container.
 
 
 # Change Log