Slave removal: remove slave from sentinel.conf when possible.

All the occurrences translated, but the ones referring to SLAVEOF
must be intact because that describe the actual Sentinel -> Redis
protocol. In theory we could send REPLICAOF to Redis instances, but
actually this would prevent Sentinel to be compatible with older Redis
instances.

sentinel.conf

@@ -73,23 +73,23 @@ dir /tmp
 # be elected by the majority of the known Sentinels in order to
 # start a failover, so no failover can be performed in minority.
 #
-# Slaves are auto-discovered, so you don't need to specify slaves in
+# replicas are auto-discovered, so you don't need to specify replicas in
 # any way. Sentinel itself will rewrite this configuration file adding
-# the slaves using additional configuration options.
+# the replicas using additional configuration options.
 # Also note that the configuration file is rewritten when a
-# slave is promoted to master.
+# replica is promoted to master.
 #
 # Note: master name should not include special characters or spaces.
 # The valid charset is A-z 0-9 and the three characters ".-_".
 sentinel monitor mymaster 127.0.0.1 6379 2
 
 # sentinel auth-pass <master-name> <password>
 #
-# Set the password to use to authenticate with the master and slaves.
+# Set the password to use to authenticate with the master and replicas.
 # Useful if there is a password set in the Redis instances to monitor.
 #
-# Note that the master password is also used for slaves, so it is not
-# possible to set a different password in masters and slaves instances
+# Note that the master password is also used for replicas, so it is not
+# possible to set a different password in masters and replicas instances
 # if you want to be able to monitor these instances with Sentinel.
 #
 # However you can have Redis instances without the authentication enabled
@@ -104,19 +104,19 @@ sentinel monitor mymaster 127.0.0.1 6379 2
 
 # sentinel down-after-milliseconds <master-name> <milliseconds>
 #
-# Number of milliseconds the master (or any attached slave or sentinel) should
+# Number of milliseconds the master (or any attached replica or sentinel) should
 # be unreachable (as in, not acceptable reply to PING, continuously, for the
 # specified period) in order to consider it in S_DOWN state (Subjectively
 # Down).
 #
 # Default is 30 seconds.
 sentinel down-after-milliseconds mymaster 30000
 
-# sentinel parallel-syncs <master-name> <numslaves>
+# sentinel parallel-syncs <master-name> <numreplicas>
 #
-# How many slaves we can reconfigure to point to the new slave simultaneously
-# during the failover. Use a low number if you use the slaves to serve query
-# to avoid that all the slaves will be unreachable at about the same
+# How many replicas we can reconfigure to point to the new replica simultaneously
+# during the failover. Use a low number if you use the replicas to serve query
+# to avoid that all the replicas will be unreachable at about the same
 # time while performing the synchronization with the master.
 sentinel parallel-syncs mymaster 1
 
@@ -128,18 +128,18 @@ sentinel parallel-syncs mymaster 1
 #   already tried against the same master by a given Sentinel, is two
 #   times the failover timeout.
 #
-# - The time needed for a slave replicating to a wrong master according
+# - The time needed for a replica replicating to a wrong master according
 #   to a Sentinel current configuration, to be forced to replicate
 #   with the right master, is exactly the failover timeout (counting since
 #   the moment a Sentinel detected the misconfiguration).
 #
 # - The time needed to cancel a failover that is already in progress but
 #   did not produced any configuration change (SLAVEOF NO ONE yet not
-#   acknowledged by the promoted slave).
+#   acknowledged by the promoted replica).
 #
-# - The maximum time a failover in progress waits for all the slaves to be
-#   reconfigured as slaves of the new master. However even after this time
-#   the slaves will be reconfigured by the Sentinels anyway, but not with
+# - The maximum time a failover in progress waits for all the replicas to be
+#   reconfigured as replicas of the new master. However even after this time
+#   the replicas will be reconfigured by the Sentinels anyway, but not with
 #   the exact parallel-syncs progression as specified.
 #
 # Default is 3 minutes.
@@ -200,7 +200,7 @@ sentinel failover-timeout mymaster 180000
 # <role> is either "leader" or "observer"
 # 
 # The arguments from-ip, from-port, to-ip, to-port are used to communicate
-# the old address of the master and the new address of the elected slave
+# the old address of the master and the new address of the elected replica
 # (now a master).
 #
 # This script should be resistant to multiple invocations.
@@ -228,7 +228,7 @@ sentinel deny-scripts-reconfig yes
 #
 # In such case it is possible to tell Sentinel to use different command names
 # instead of the normal ones. For example if the master "mymaster", and the
-# associated slaves, have "CONFIG" all renamed to "GUESSME", I could use:
+# associated replicas, have "CONFIG" all renamed to "GUESSME", I could use:
 #
 # sentinel rename-command mymaster CONFIG GUESSME
 #