Sentinel: new test unit 07 that tests master down conditions.

Sentinel: check Slave INFO state more often when disconnected.

During the initial handshake with the master a slave will report to have
a very high disconnection time from its master (since technica

Sentinel: check Slave INFO state more often when disconnected.

During the initial handshake with the master a slave will report to have
a very high disconnection time from its master (since technically it was
disconnected since forever, so the current UNIX time in seconds is
reported).

However when the slave is connected again the Sentinel may re-scan the
INFO output again only after 10 seconds, which is a long time. During
this time Sentinels will consider this instance unable to failover, so
a useless delay is introduced.

Actaully this hardly happened in the practice because when a slave's
master is down, the INFO period for slaves changes to 1 second. However
when a manual failover is attempted immediately after adding slaves
(like in the case of the Sentinel unit test), this problem may happen.

This commit changes the INFO period to 1 second even in the case the
slave's master is not down, but the slave reported to be disconnected
from the master (by publishing, last time we checked, a master
disconnection time field in INFO).

This change is required as a result of an unrelated change in the
replication code that adds a small delay in the master-slave first
synchronization.

show more ...

Sentinel: CKQUORUM tests

Sentinel / Cluster test: exit with non-zero error code on failures.

Spell software correctly

Sentinel test: more correct sentinels config reset.

In the initialization test for each instance we used to unregister the
old master and register it again to clear the config.
However there is a ra

Sentinel test: more correct sentinels config reset.

In the initialization test for each instance we used to unregister the
old master and register it again to clear the config.
However there is a race condition doing this: as soon as we unregister
and re-register "mymaster", another Sentinel can update the new
configuration with the old state because of gossip "hello" messages.

So the correct procedure is instead, unregister "mymaster" from all the
sentinel instances, and re-register it everywhere again.

show more ...

Sentinel test: tolerate larger delays in init tests.

Sentinel test: unit 02, avoid some time related false positives.

Sentinel test: add manual failover test.

Add correct exit value to failed tests

Cluster / Sentinel test: instances count moved to run.tcl.

Sentinel test files / directories layout improved.

The test now runs in a self-contained directory.
The general abstractions to run the tests in an environment where
mutliple instances are executed

Sentinel test files / directories layout improved.

The test now runs in a self-contained directory.
The general abstractions to run the tests in an environment where
mutliple instances are executed at the same time was extrapolated into
instances.tcl, that will be reused to test Redis Cluster.

show more ...