1. 11 Feb, 2021 1 commit
  2. 08 Feb, 2021 1 commit
    • Yossi Gottlieb's avatar
      Fix and cleanup Sentinel leaked fds test. (#8469) · dbcc0a85
      Yossi Gottlieb authored
      * For consistency, use tclsh for the script as well
      * Ignore leaked fds that originate from grandparent process, since we
        only care about fds redis-sentinel itself is responsible for
      * Check every test iteration to catch problems early
      * Some cleanups, e.g. parameterization of file name, etc.
      dbcc0a85
  3. 30 Jan, 2021 1 commit
    • Wen Hui's avatar
      fix sentinel tests error (#8422) · eacccd2a
      Wen Hui authored
      This commit fixes sentinel announces hostnames test error in certain linux environment
      Before this commit, we only check localhost is resolved into 127.0.0.1, however in ubuntu
      or some other linux environments "localhost" will be resolved into ::1 ipv6 address first if
      the network stack is capable.
      eacccd2a
  4. 28 Jan, 2021 1 commit
    • Yossi Gottlieb's avatar
      Add hostname support in Sentinel. (#8282) · bb7cd974
      Yossi Gottlieb authored
      
      
      This is both a bugfix and an enhancement.
      
      Internally, Sentinel relies entirely on IP addresses to identify
      instances. When configured with a new master, it also requires users to
      specify and IP and not hostname.
      
      However, replicas may use the replica-announce-ip configuration to
      announce a hostname. When that happens, Sentinel fails to match the
      announced hostname with the expected IP and considers that a different
      instance, triggering reconfiguration, etc.
      
      Another use case is where TLS is used and clients are expected to match
      the hostname to connect to with the certificate's SAN attribute. To
      properly implement this configuration, it is necessary for Sentinel to
      redirect clients to a hostname rather than an IP address.
      
      The new 'resolve-hostnames' configuration parameter determines if
      Sentinel is willing to accept hostnames. It is set by default to no,
      which maintains backwards compatibility and avoids unexpected DNS
      resolution delays on systems with DNS configuration issues.
      
      Internally, Sentinel continues to identify instances by their resolved
      IP address and will also report the IP by default. The new
      'announce-hostnames' parameter determines if Sentinel should prefer to
      announce a hostname, when available, rather than an IP address. This
      applies to addresses returned to clients, as well as their
      representation in the configuration file, REPLICAOF configuration
      commands, etc.
      
      This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET
      which can be used to introspect or configure global Sentinel
      configuration that was previously was only possible by directly
      accessing the configuration file and possibly restarting the instance.
      Co-authored-by: default avatarmyl1024 <myl92916@qq.com>
      Co-authored-by: default avatarsundb <sundbcn@gmail.com>
      bb7cd974
  5. 26 Jan, 2021 1 commit
    • Wen Hui's avatar
      Sentinel: Fix Config Dependency and Rewrite Sequence (#8271) · 1aad55b6
      Wen Hui authored
      This commit fixes a well known and an annoying issue in Sentinel mode.
      
      Cause of this issue:
      Currently, Redis rewrite process works well in server mode, however in sentinel mode,
      the sentinel config has variant semantics for different configurations, in example configuration
      https://github.com/redis/redis/blob/unstable/sentinel.conf, we put comments on these.
      However the rewrite process only treat the sentinel config as a single option. During rewrite
      process, it will mess up with the lines and comments.
      
      Approaches:
      In order to solve this issue, we need to differentiate different subconfig options in sentinel separately,
      for example, sentinel monitor <master-name> <ip> <redis-port> <quorum>
      we can treat it as sentinel monitor option, instead of the sentinel option.
      
      This commit also fixes the dependency issue when putting configurations in sentinel.conf.
      For example before this commit,we must put
      `sentinel monitor <master-name> <ip> <redis-port> <quorum>` before
      `sentinel auth-pass <master-name> <password>` for a single master,
      otherwise the server cannot start and will return error. This commit fixes this issue, as long as
      the monitoring master was configured, no matter the sequence is, the sentinel can start and run properly.
      1aad55b6
  6. 22 Jan, 2021 1 commit
  7. 20 Jan, 2021 1 commit
  8. 19 Jan, 2021 1 commit
  9. 13 Sep, 2020 1 commit
  10. 07 Oct, 2019 2 commits
    • Yossi Gottlieb's avatar
      TLS: Configuration options. · 61733ded
      Yossi Gottlieb authored
      Add configuration options for TLS protocol versions, ciphers/cipher
      suites selection, etc.
      61733ded
    • Yossi Gottlieb's avatar
      TLS: Connections refactoring and TLS support. · b087dd1d
      Yossi Gottlieb authored
      * Introduce a connection abstraction layer for all socket operations and
      integrate it across the code base.
      * Provide an optional TLS connections implementation based on OpenSSL.
      * Pull a newer version of hiredis with TLS support.
      * Tests, redis-cli updates for TLS support.
      b087dd1d
  11. 26 Aug, 2018 1 commit
  12. 26 Jun, 2018 1 commit
  13. 22 Jul, 2016 2 commits
    • antirez's avatar
      8b76d55f
    • antirez's avatar
      Sentinel: check Slave INFO state more often when disconnected. · 3e9ce38b
      antirez authored
      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.
      3e9ce38b
  14. 19 May, 2015 1 commit
  15. 30 Mar, 2015 1 commit
  16. 29 Sep, 2014 1 commit
  17. 23 Jun, 2014 1 commit
    • antirez's avatar
      Sentinel test: more correct sentinels config reset. · e21e0ba3
      antirez authored
      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.
      e21e0ba3
  18. 19 Jun, 2014 3 commits
  19. 18 Jun, 2014 1 commit
  20. 29 Apr, 2014 1 commit
  21. 24 Apr, 2014 1 commit
    • antirez's avatar
      Sentinel test files / directories layout improved. · 897adc1c
      antirez authored
      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.
      897adc1c