精华内容
下载资源
问答
  • 哨兵模式

    2021-01-12 18:26:05
    哨兵模式 主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式 ...

    哨兵模式

    主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式

    哨兵模式概述

    哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令等待Redis服务器响应从而监控运行的多个Redis实例

    在这里插入图片描述

    这里的哨兵有两个作用

    • 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。
    • 当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。

    然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。

    用文字描述一下故障切换(failover)的过程。假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线。这样对于客户端而言,一切都是透明的。

    Redis配置哨兵模式

    配置1个哨兵和1主2从的Redis服务器来演示这个过程。

    服务器类型 是否是主服务器 IP地址 端口
    Redis 127.0.0.1 6379
    Redis 127.0.0.1 6380
    Redis 127.0.0.1 6381

    在这里插入图片描述

    测试

    测试环境:一主二从、一个哨兵

    • 哨兵配置文件 sentinel.config
    # sentinel monitor myredis 被监控主机名称 host 1        数字 1 代表主机挂了, slave 投票看谁接替成为主机, 就会成为主机
    sentinel monitor myredis 127.0.0.1 6379 1
    
    • 启动哨兵
    redis-sentinel myconfig/sentinel.conf
    
    [root@ecs-t6-medium-2-linux-20190910000110 redis-5.0.7]# redis-sentinel myconfig/sentinel.conf
    10933:X 12 Jan 2021 15:55:07.961 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
    10933:X 12 Jan 2021 15:55:07.961 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=10933, just started
    10933:X 12 Jan 2021 15:55:07.961 # Configuration loaded
                    _._                                                  
               _.-``__ ''-._                                             
          _.-``    `.  `_.  ''-._           Redis 5.0.7 (00000000/0) 64 bit
      .-`` .-```.  ```\/    _.,_ ''-._                                   
     (    '      ,       .-`  | `,    )     Running in sentinel mode
     |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
     |    `-._   `._    /     _.-'    |     PID: 10933
      `-._    `-._  `-./  _.-'    _.-'                                   
     |`-._`-._    `-.__.-'    _.-'_.-'|                                  
     |    `-._`-._        _.-'_.-'    |           http://redis.io        
      `-._    `-._`-.__.-'_.-'    _.-'                                   
     |`-._`-._    `-.__.-'    _.-'_.-'|                                  
     |    `-._`-._        _.-'_.-'    |                                  
      `-._    `-._`-.__.-'_.-'    _.-'                                   
          `-._    `-.__.-'    _.-'                                       
              `-._        _.-'                                           
                  `-.__.-'                                               
    
    10933:X 12 Jan 2021 15:55:07.962 # Sentinel ID is af64af6020684a2fe79f1cc4e1727c39778263bc
    10933:X 12 Jan 2021 15:55:07.962 # +monitor master myredis 127.0.0.1 6379 quorum 1
    10933:X 12 Jan 2021 16:04:10.045 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
    10933:X 12 Jan 2021 16:04:30.090 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
    

    当6379宕机或者关闭后

    哨兵日志

    11726:X 12 Jan 2021 16:05:35.830 # Configuration loaded
                    _._                                                  
               _.-``__ ''-._                                             
          _.-``    `.  `_.  ''-._           Redis 5.0.7 (00000000/0) 64 bit
      .-`` .-```.  ```\/    _.,_ ''-._                                   
     (    '      ,       .-`  | `,    )     Running in sentinel mode
     |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
     |    `-._   `._    /     _.-'    |     PID: 11726
      `-._    `-._  `-./  _.-'    _.-'                                   
     |`-._`-._    `-.__.-'    _.-'_.-'|                                  
     |    `-._`-._        _.-'_.-'    |           http://redis.io        
      `-._    `-._`-.__.-'_.-'    _.-'                                   
     |`-._`-._    `-.__.-'    _.-'_.-'|                                  
     |    `-._`-._        _.-'_.-'    |                                  
      `-._    `-._`-.__.-'_.-'    _.-'                                   
          `-._    `-.__.-'    _.-'                                       
              `-._        _.-'                                           
                  `-.__.-'                                               
    
    11726:X 12 Jan 2021 16:05:35.831 # Sentinel ID is af64af6020684a2fe79f1cc4e1727c39778263bc
    11726:X 12 Jan 2021 16:05:35.831 # +monitor master myredis 127.0.0.1 6379 quorum 1
    11726:X 12 Jan 2021 16:07:34.811 # +sdown master myredis 127.0.0.1 6379
    11726:X 12 Jan 2021 16:07:34.811 # +odown master myredis 127.0.0.1 6379 #quorum 1/1
    11726:X 12 Jan 2021 16:07:34.811 # +new-epoch 1
    11726:X 12 Jan 2021 16:07:34.811 # +try-failover master myredis 127.0.0.1 6379
    11726:X 12 Jan 2021 16:07:34.814 # +vote-for-leader af64af6020684a2fe79f1cc4e1727c39778263bc 1
    11726:X 12 Jan 2021 16:07:34.814 # +elected-leader master myredis 127.0.0.1 6379
    # failove 故障转移
    11726:X 12 Jan 2021 16:07:34.814 # +failover-state-select-slave master myredis 127.0.0.1 6379
    11726:X 12 Jan 2021 16:07:34.866 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
    11726:X 12 Jan 2021 16:07:34.866 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
    11726:X 12 Jan 2021 16:07:34.925 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
    11726:X 12 Jan 2021 16:07:35.087 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
    11726:X 12 Jan 2021 16:07:35.087 # +failover-state-reconf-slaves master myredis 127.0.0.1 6379
    11726:X 12 Jan 2021 16:07:35.147 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
    11726:X 12 Jan 2021 16:07:36.094 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
    11726:X 12 Jan 2021 16:07:36.094 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
    
    11726:X 12 Jan 2021 16:07:36.171 # +failover-end master myredis 127.0.0.1 6379
    # 6381
    11726:X 12 Jan 2021 16:07:36.171 # +switch-master myredis 127.0.0.1 6379 127.0.0.1 6381
    11726:X 12 Jan 2021 16:07:36.171 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6381
    11726:X 12 Jan 2021 16:07:36.171 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
    

    此时6381为老大

    127.0.0.1:6381> info replication
    # Replication
    role:master
    connected_slaves:1
    slave0:ip=127.0.0.1,port=6380,state=online,offset=17768,lag=0
    master_replid:25c55d651308dd9fcd2f9c84867ed1a58f2f4286
    master_replid2:9d786450a338f30155c623f99d1bd58129712aab
    master_repl_offset:17768
    second_repl_offset:11402
    repl_backlog_active:1
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:1
    repl_backlog_histlen:17768
    127.0.0.1:6381> 
    

    如果主机此时回来了, 只能归并到新的主机下, 当作从机, 这就是哨兵模式的规则

    11726:X 12 Jan 2021 16:07:36.171 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
    11726:X 12 Jan 2021 16:08:06.192 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
    11726:X 12 Jan 2021 16:22:59.961 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
    11726:X 12 Jan 2021 16:23:34.353 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
    11726:X 12 Jan 2021 16:23:37.565 * +reboot slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
    11726:X 12 Jan 2021 16:23:37.648 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
    11726:X 12 Jan 2021 16:23:47.568 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
    

    哨兵模式

    优点

    • 哨兵集群, 基于主从复制模式, 所有主从配置优点, 它全有
    • 主从可以切换, 故障可以转移, 系统可用性就会很好
    • 哨兵模式就是主从模式的升级, 手动到自动, 更加健壮

    缺点

    • redis 不好在线扩容, 集群容量一旦到达上限, 在线扩容就十分的麻烦
    • 实现哨兵模式的配置其实是很麻烦的, 里面有很多选择

    哨兵模式全部配置

    # Example sentinel.conf
    
    # *** IMPORTANT ***
    #
    # By default Sentinel will not be reachable from interfaces different than
    # localhost, either use the 'bind' directive to bind to a list of network
    # interfaces, or disable protected mode with "protected-mode no" by
    # adding it to this configuration file.
    #
    # Before doing that MAKE SURE the instance is protected from the outside
    # world via firewalling or other means.
    #
    # For example you may use one of the following:
    #
    # bind 127.0.0.1 192.168.1.1
    #
    # protected-mode no
    
    # port <sentinel-port>
    # The port that this sentinel instance will run on
    port 26379          # 如果有哨兵集群, 我们还需要配置每个哨兵端口
    
    # By default Redis Sentinel does not run as a daemon. Use 'yes' if you need it.
    # Note that Redis will write a pid file in /var/run/redis-sentinel.pid when
    # daemonized.
    daemonize no
    
    # When running daemonized, Redis Sentinel writes a pid file in
    # /var/run/redis-sentinel.pid by default. You can specify a custom pid file
    # location here.
    pidfile /var/run/redis-sentinel.pid
    
    # Specify the log file name. Also the empty string can be used to force
    # Sentinel to log on the standard output. Note that if you use standard
    # output for logging but daemonize, logs will be sent to /dev/null
    logfile ""
    
    # sentinel announce-ip <ip>
    # sentinel announce-port <port>
    #
    # The above two configuration directives are useful in environments where,
    # because of NAT, Sentinel is reachable from outside via a non-local address.
    #
    # When announce-ip is provided, the Sentinel will claim the specified IP address
    # in HELLO messages used to gossip its presence, instead of auto-detecting the
    # local address as it usually does.
    #
    # Similarly when announce-port is provided and is valid and non-zero, Sentinel
    # will announce the specified TCP port.
    #
    # The two options don't need to be used together, if only announce-ip is
    # provided, the Sentinel will announce the specified IP and the server port
    # as specified by the "port" option. If only announce-port is provided, the
    # Sentinel will announce the auto-detected local IP and the specified port.
    #
    # Example:
    #
    # sentinel announce-ip 1.2.3.4
    
    # dir <working-directory>
    # Every long running process should have a well-defined working directory.
    # For Redis Sentinel to chdir to /tmp at startup is the simplest thing
    # for the process to don't interfere with administrative tasks such as
    # unmounting filesystems.
    # 哨兵的 sentinel的工作目录
    dir /tmp            
    
    # sentinel monitor <master-name> <ip> <redis-port> <quorum>
    #
    # Tells Sentinel to monitor this master, and to consider it in O_DOWN
    # (Objectively Down) state only if at least <quorum> sentinels agree.
    #
    # Note that whatever is the ODOWN quorum, a Sentinel will require to
    # be elected by the majority of the known Sentinels in order to
    # start a failover, so no failover can be performed in minority.
    #
    # Replicas are auto-discovered, so you don't need to specify replicas in
    # any way. Sentinel itself will rewrite this configuration file adding
    # the replicas using additional configuration options.
    # Also note that the configuration file is rewritten when a
    # 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 监控的 redis 主节点 ip port
    # master-name 可以自己命名的主节点名字  只能由字母 A-Z  数字0-9 这三个字符".-_" 组成
    # quorum 配置多少个 sentinel 哨兵统一认为 master主节点失联, 那么这时候客观上认为主节点失联了
    # sentinel monitor <master-name> <ip> <redis-port> <quorum>
    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 replicas.
    # Useful if there is a password set in the Redis instances to monitor.
    #
    # 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
    # mixed with Redis instances requiring the authentication (as long as the
    # password set is the same for all the instances requiring the password) as
    # the AUTH command will have no effect in Redis instances with authentication
    # switched off.
    #
    # Example:
    #
    # 当Redia实例中开启了 requirepass foobared 授权密码 这样所有的连接Redis 实例的客户端都要提供密码
    # 设置哨兵 sentinel 连接主从密码, 注意必须为主从设置一样的验证密码
    # sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
    
    # sentinel down-after-milliseconds <master-name> <milliseconds>
    #
    # 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 此时 哨兵主管上认为节点下线 默认 30s
    # sentinel down-after-milliseconds <master-name> <milliseconds>
    sentinel down-after-milliseconds mymaster 30000
    
    # sentinel parallel-syncs <master-name> <numreplicas>
    #
    # 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.
    # 这个配置项指定了发生 failover 主备切换时最多有多少个slave同时对新的master 进行同步
    # 这个数字越小 完成 failover 所需时间就越长
    # 但是如果这个数字越大, 就意味着越多的 slave 因为 replication而不可用
    # 可以通过这个值设置为1 来保证每次只有一个 slave 处于不能处理命令的请求状态
    # sentinel parallel-syncs <master-name> <numreplicas>
    sentinel parallel-syncs mymaster 1
    
    # sentinel failover-timeout <master-name> <milliseconds>
    #
    # Specifies the failover timeout in milliseconds. It is used in many ways:
    #
    # - The time needed to re-start a failover after a previous failover was
    #   already tried against the same master by a given Sentinel, is two
    #   times the failover timeout.
    #
    # - 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 replica).
    #
    # - 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.
    #
    # 故障转移超时时间 failover-timeout 可以用在以下这些方面
    # 1 同一个 sentinel 对同一个master两次 failover 之间的间隔时间
    # 2 一个 slave 从一个错误的 master 那里同步数据开始计算时间, 直到 slave 被纠正为正确的 master 那里同步数据时
    # 3 当想要取消一个正在进行的 failover 所需要的时间
    # 4 当进行 failover 时, 配置所有 slaves 指定新的 master 所需要的最大时间. 不过, 即使过了这个超时, slave 依然会被正确的配置为指向 master 但是就不按 paralle1- syncs 所配置规来了
    sentinel failover-timeout mymaster 180000
    
    # SCRIPTS EXECUTION
    #
    # sentinel notification-script and sentinel reconfig-script are used in order
    # to configure scripts that are called to notify the system administrator
    # or to reconfigure clients after a failover. The scripts are executed
    # with the following rules for error handling:
    #
    # If script exits with "1" the execution is retried later (up to a maximum
    # number of times currently set to 10).
    #
    # If script exits with "2" (or an higher value) the script execution is
    # not retried.
    #
    # If script terminates because it receives a signal the behavior is the same
    # as exit code 1.
    #
    # A script has a maximum running time of 60 seconds. After this limit is
    # reached the script is terminated with a SIGKILL and the execution retried.
    
    # 配置当某一件事情发生时, 所需要执行的脚本, 可以通过脚本通知来通知管理员, 例如当系统不能正常发邮件通知相关人员
    # 对于脚本的运行结果有以下规则
    # 若脚本执行后返回1, 那么该脚本稍后将会被再次执行, 重复次数默认为 10
    # 若脚本执行后返回2, 或者比2更高的一个返回值, 脚本将不会重复执行
    # 如果脚本在执行过程中由于收到系统中断信号被终止了, 则同返回值1时的行为相同
    # 一个脚本的最大执行时间为60s, 如果超过了这个时间, 脚本将会被一个SIGKILL信号终止, 之后重新执行 
    
    # NOTIFICATION SCRIPT
    #
    # sentinel notification-script <master-name> <script-path>
    # 
    # Call the specified notification script for any sentinel event that is
    # generated in the WARNING level (for instance -sdown, -odown, and so forth).
    # This script should notify the system administrator via email, SMS, or any
    # other messaging system, that there is something wrong with the monitored
    # Redis systems.
    #
    # The script is called with just two arguments: the first is the event type
    # and the second the event description.
    #
    # The script must exist and be executable in order for sentinel to start if
    # this option is provided.
    #
    # Example:
    #
    # sentinel notification-script mymaster /var/redis/notify.sh
    
    # CLIENTS RECONFIGURATION SCRIPT
    #
    # sentinel client-reconfig-script <master-name> <script-path>
    #
    # When the master changed because of a failover a script can be called in
    # order to perform application-specific tasks to notify the clients that the
    # configuration has changed and the master is at a different address.
    # 
    # The following arguments are passed to the script:
    #
    # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
    #
    # <state> is currently always "failover"
    # <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 replica
    # (now a master).
    #
    # This script should be resistant to multiple invocations.
    #
    # Example:
    #
    # sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
    
    # SECURITY
    #
    # By default SENTINEL SET will not be able to change the notification-script
    # and client-reconfig-script at runtime. This avoids a trivial security issue
    # where clients can set the script to anything and trigger a failover in order
    # to get the program executed.
    
    sentinel deny-scripts-reconfig yes
    
    # REDIS COMMANDS RENAMING
    #
    # Sometimes the Redis server has certain commands, that are needed for Sentinel
    # to work correctly, renamed to unguessable strings. This is often the case
    # of CONFIG and SLAVEOF in the context of providers that provide Redis as
    # a service, and don't want the customers to reconfigure the instances outside
    # of the administration console.
    #
    # 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 replicas, have "CONFIG" all renamed to "GUESSME", I could use:
    #
    # SENTINEL rename-command mymaster CONFIG GUESSME
    #
    # After such configuration is set, every time Sentinel would use CONFIG it will
    # use GUESSME instead. Note that there is no actual need to respect the command
    # case, so writing "config guessme" is the same in the example above.
    #
    # SENTINEL SET can also be used in order to perform this configuration at runtime.
    #
    # In order to set a command back to its original name (undo the renaming), it
    # is possible to just rename a command to itsef:
    #
    # SENTINEL rename-command mymaster CONFIG CONFIG
    

    文章已上传gitee https://gitee.com/codingce/hexo-blog
    项目地址: https://github.com/xzMhehe/codingce-java

    展开全文
  • Redis 哨兵模式的一些思考

    万次阅读 2020-07-29 13:45:23
    为什么会出现哨兵模式 Redis主从复制模式下,如果主节点出现故障将不能再继续提供服务,需要人为将从节点提升为主节点,同时还需要通知各个应用新的主节点的地址,这个在很多场景下是不能接受的,哨兵模式能很好...

    为什么会出现哨兵模式

     Redis主从复制模式下,如果主节点出现故障将不能再继续提供服务,需要人为将从节点提升为主节点,同时还需要通知各个应用新的主节点的地址,这个在很多场景下是不能接受的,哨兵模式能很好的解决这个问题

    • Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态

    • 在Master主服务器发生故障的时候,可以实现Master和Slave服务器的切换,保证系统的高可用(HA)

    • 其已经被集成在redis2.6+的版本中,Redis的哨兵模式到了2.8版本之后就稳定了下来。

     哨兵的作用

    • 监控(Monitoring): 哨兵(sentinel) 会不断地检查集群中的Master和Slave是否运作正常。

    • 提醒(Notification):当被监控的某节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

    • 自动故障迁移(Automatic failover)个Master客观下线时,哨兵(sentinel) 会开始一次自动故障迁移操作

      • 它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master;

      • 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用现在的Master替换失效Master。

      • Master和Slave服务器切换后,Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变,即,Master主服务器的redis.conf配置文件中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换。

    哨兵进程的工作方式

    • 每个Sentinel进程以每秒钟一次的频率向整个集群中的Master主服务器,Slave从服务器以及其他Sentinel进程发送一个 ping 命令
    • 如果一个实例(instance)距离最后一次有效回复 ping 命令的时间超过 down-after-milliseconds 选项所指定的值,则这个实例会被 Sentinel(哨兵)进程标记为主观下线SDOWN
    • 如果一个Master主服务器被标记为主观下线(SDOWN),则正在监视这个Master主服务器的所有Sentinel进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
    • 有足够数量的 Sentinel(个数可配置)进程(大于等于配置文件指定的值)在指定的时间范围内确认Master主服务器进入了主观下线状态(SDOWN), 则Master主服务器会被标记为客观下线(ODOWN)
    • 在一般情况下, 每个Sentinel进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 info命令。
    • 当Master主服务器被 Sentinel进程标记为客观下线(ODOWN)时,Sentinel进程向下线的 Master主服务器的所有 Slave从服务器发送 info命令的频率会从 10 秒一次改为每秒一次。
    • 若没有足够数量的 Sentinel进程同意 Master主服务器下线, Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel进程发送 ping命令返回有效回复,Master主服务器的主观下线状态就会被移除。

    哨兵服务理想部署方案 

     

    进程如下 

    # 在单台机器上做的测试
    root     31363     1  0 7月28 ?       00:01:51 /mnt/redis/bin/redis-server 0.0.0.0:6380
    root     31375     1  0 7月28 ?       00:01:57 /mnt/redis/bin/redis-server 0.0.0.0:6381
    root     31387     1  0 7月28 ?       00:01:55 /mnt/redis/bin/redis-server 0.0.0.0:6382
    root     31552     1  0 7月28 ?       00:02:31 /mnt/redis/bin/redis-sentinel 0.0.0.0:26380 [sentinel]
    root     31557     1  0 7月28 ?       00:02:31 /mnt/redis/bin/redis-sentinel 0.0.0.0:26381 [sentinel]
    root     31563     1  0 7月28 ?       00:02:31 /mnt/redis/bin/redis-sentinel 0.0.0.0:26382 [sentinel]
    
    

    哨兵服务发现和健康检查流程及故障切换流程

     

    哨兵的启动和配置

    # 配置文件:sentinel.conf,在sentinel运行期间是会被动态修改的
    # sentinel如果重启时,根据这个配置来恢复其之前所监控的redis集群的状态
    # 绑定IP
    bind 0.0.0.0
    
    # 后台运行
    daemonize yes
    
    # 默认yes,没指定密码或者指定IP的情况下,外网无法访问
    protected-mode no
    
    # 哨兵的端口,客户端通过这个端口来发现redis
    port 26380
    
    # 哨兵自己的IP,手动设定也可自动发现,用于与其他哨兵通信
    # sentinel announce-ip
    
    # 临时文件夹
    dir /tmp
    
    # 日志
    logfile "/mnt/redis/logs/sentinel-26380.log"
    
    # sentinel监控的master的名字叫做mymaster,初始地址为 192.168.100.241 6380,2代表两个及以上哨兵认定为死亡,才认为是真的死亡
    sentinel monitor mymaster 192.168.16.40 6380 2
    
    # 发送心跳PING来确认master是否存活
    # 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息,那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
    sentinel down-after-milliseconds mymaster 1000
    
    # 如果在该时间(ms)内未能完成failover操作,则认为该failover失败
    sentinel failover-timeout mymaster 3000
    
    # 指定了在执行故障转移时,最多可以有多少个从Redis实例在同步新的主实例,在从Redis实例较多的情况下这个数字越小,同步的时间越长,完成故障转移所需的时间就越长
    sentinel parallel-syncs mymaster 1

    什么是主观下线

    • 使用ping命令
    • 主观下线:单个哨兵自身认为redis实例已经不能提供服务
    • 监测机制:哨兵向redis发送ping请求,+PONG、-LOADING、-MASTERDOWN这三种情况视为正常,其他回复均视为无效
    •  对应配置项:sentinel down-after-milliseconds mymaster 1000

    哨兵如何知道Redis主从信息

    •  使用 redis-cli -p 6380 info Replication命令去获取主从关系
    • 对应配置信息
      
      # Generated by CONFIG REWRITE
      pidfile "/var/run/redis.pid"
      user default on nopass ~* +@all
      sentinel failover-timeout mymaster 3000
      sentinel config-epoch mymaster 3
      sentinel leader-epoch mymaster 3
      sentinel known-replica mymaster 192.168.16.40 6381 #记录了从属节点6381
      sentinel known-replica mymaster 192.168.16.40 6382 #记录了从属节点6382   
      sentinel known-sentinel mymaster 192.168.16.40 26381 4cabf69629c1401289b6d3d239eba18b45da0041
      sentinel known-sentinel mymaster 192.168.16.40 26382 20d8240e06a10cd887b752026c00de0318761eb8
      sentinel current-epoch 3
      

       

    什么是客观下线

    • 使用SENTINEL is-master-down-by-addr命令询问其他哨兵master节点是否已经下线
    • 客观下线:一定数量之的哨兵认为master已经下线,即可判定为master客观下线
    • 检测机制:当哨兵主观认为master下线后,会通过SENTINEL is-master-down-by-addr命令询问其他哨兵是否master已经下线,如果达成共识(达到quorum个数),就认为master节点客观下线,开始故障转移流程
    • 对应的配置项:sentinel monitor mymaster 192.168.16.40 6380 2

    哨兵之间如何通信(发布订阅机制)

    • slaveof 主从连接
    •  sentinel 向Master 发送 SUBSCRIBE 命令,订阅 Master 的 Hello Channel (SUBSCRIBE __sentinel__:hello),等待接收消息
    •  sentinel 向 Master 发送 INFO 命令,获取服务信息,及发现主从关系(获取到 Slave 信息)
    •  sentinel 向 Master/Slave 发送 SUBSCRIBE 命令,与 2 类似(这次有了Slave节点)。如果之前已有的连接正常,则不会再次重复连接,因此正常情况下这一步只会连接新加入的Slave节点。
    •  sentinel 向 Master/Slave 发送INFO命令,与 3 类似。
    •  sentinel 向 Master/Slave 发送PUBLISH命令,扩散消息(当前Sentinel/Master 信息 )。sentinel 接收到了 Master/Slave 中 Hello Channel 中的消息,得到其他的Sentinel 信息,然后保存到对应Master 下的 Sentinels 列表中。至此,整个 sentinel 结构中的节点数据基本完善。
    •  sentinel 向 Master/Slave/Sentinel 发送 PUBLISH命令,扩散消息。
      在经过多次的消息扩散之后,每个 master 下的 sentinels 列表会逐渐增多。最终,每个 sentinel 中将保存着所有 Sentinel/Master/Slave 信息,并且不断进行心跳监测,信息同步。

     哨兵领导选举机制

    • 基于Raft算法实现的选举机制
    •  拉票阶段:每个哨兵节点都希望自己成为leader
    • sentinel节点收到拉票命令后,如果没有收到或者是同意其他sentinel节点的请求,就同意该节点的请求(每个节点只有一个同意票)
    • 如果sentinel节点发现自己的票数已经超过一半的数值,那么它就成为leader,去执行故障转移
    • 投票结束后,如果超过failover-timeover时间,没进行实际的故障转移操作,则重新拉票选举

    RedisMaster选举方案(从slave中选出)

    • 首先,slave节点状态: 非S_DOWN,O_DOWN,DISCONNECED 状态才能满足
      • 判断规则: (down-after-milliseconds*10)+milliseconds_since_master_is_in_SDOWN-state
      • SENTINEL slaves mymaster
    •  其次,查看优先级
      • redis.conf中的配置项:slave-prioprity值越小,优先级越高
    • 再次,数据同步情况
      • Replication offset processed
    • 最后,最小的run id
      • run id 比较方案:字典顺序,ASCII码

    最终主从切换过程 

    • 针对即将成为master的slave节点,将其撤出主从集群
      • 执行命令: slaveof NO ONE
    •  针对其他slave节点,使它们成为新的master从属节点
      • 执行命令:slaveof 192.168.16.40 6381
    展开全文
  • Redis 哨兵模式,哨兵模式优缺点,哨兵模式配置文件的配置信息 废话不多说,直接上代码(总结) Redis 哨兵模式 1.当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段...

    哈喽,欢迎来到小朱课堂,下面开始你的学习吧!

    Redis 哨兵模式,哨兵模式优缺点,哨兵模式配置文件的配置信息
    废话不多说,直接上代码(总结)

    Redis 哨兵模式

    1.当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式。
    2.这时,我们考虑哨兵模式。哨兵模式是一种特殊的模式,是一个独立的进程,它会向redis服务器发送命令,等待redis服务器响应,从而监控多个redis服务器的运行状态,如果监控到主服务器宕机,则会通过选举算法将一台从机选举为新得主机,然后通过发布订阅模式通知其他服务器并修改他们的配置文件,设置新的主机信息。
    3.多哨兵模式:当然一个哨兵也不满足高可用的需求,所以需要有时需多个哨兵同时监控,各个哨兵之间也会相互监控,例如有3个哨兵3个redis服务器,这样就会开启15条监控线。如果哨兵1监控到主服务器下线【主观下线】,不会立即选举新的主机,而是等后面的哨兵检测,当一定数量的哨兵都检测到主服务器下线,则进行投票选举新主机,再过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机【客观下线】。
    4.使用命令:redis-sentinel sentinel.conf来开启哨兵。

    哨兵模式优缺点

    优点:
    1、哨兵集群,基于主从复制模式,所有的主从配置优点,它都有
    2、主从可以切换,故障可以转移,高可用性的系统
    3、哨兵模式就是主从模式的升级,手动到自动,更加健壮
    缺点:
    1、Redis不好在线扩容的,集群容量一旦到达上限,在线扩容就十分麻烦
    2、哨兵模式的配置繁琐

    哨兵模式配置文件的配置信息

    #Example sentinel.conf
    
    #哨兵sentinel实例运行的端口 默认26379
    port 26379
    
    #哨兵sentinel的工作目录
    dir /tmp
    
    #哨兵sentinel监控的redis主节点的 ip port
    #master-name可以自己命名的主节点名字,只能由字母A-z、数字0-9、这三个字符".-_"组成。
    #quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
    #sentinel monitor <master-name> <ip> <redis-port> <quorum>
    sentinel monitor mymaster 127.0.0.1 6379 2
     
    #当在Redis实例中开启了requirepass foobared授权密码,这样所有连接Redis实例的客户端都要提供密码 
    #设置哨兵sentinel连接主从的密码,注意必须为主从设置一样的验证密码
    # sentinel auth-pass <master-name> <password>
    sentinel auth-pass mymaster XXX
    #指定多少毫秒之后主节点没有应答哨兵,此时哨兵主观上认为主节点下线,默认30秒
    # sentinel down-after-milliseconds <master-name> <milliseconds>
    sentinel down-after-milliseconds mymaster 30000
    
    # 这个配置项指定了在发生failover主备切换(选举)时多可以有多少个slave同时对新的master进行同步,数字越小,完成failover所需的时间就越长,但是如果这个数字越大,就意味着越多的slave因为replication而不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
    # sentinel parallel-syncs <master-name> <numslaves>
    sentinel parallel-syncs mymaster 1
    
    #故障转移的超时时间failover-timeout可以用在以下这些方面:
    #1. 同一个sentinel对同一个master两次failover之间的间隔时间。
    #2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
    #3.当想要取消一个正在进行的failover所需要的时间。
    #4.当进行failover时,配置所有slaves指向新的master所需的大时间。不过,即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了#默认三分钟
    # sentinel failover-timeout <master-name> <milliseconds>
    sentinel failover-timeout mymaster 180000
    
    #SCRIPTS EXECUTION
    
    #配置当某一事件发生时所需要执行的脚本,可以通过脚本来通知管理员,例如当系统运行不正常时发邮件通知相关人员。
    #对于脚本的运行结果有以下规则:
    #若脚本执行后返回1,那么该脚本稍后将会被再次执行,重复次数目前默认为10
    #若脚本执行后返回2,或者比2更高的一个返回值,脚本将不会重复执行。
    #如果脚本在执行过程中由于收到系统中断信号被终止了,则同返回值为1时的行为相同。#一个脚本的大执行时间为60s,如果超过这个时间,脚本将会被一个SIGKILL信号终止,之后重新执行。
    
    #通知型脚本:当sentinel有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等),将会去调用这个脚本,这时这个脚本应该通过邮件,SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时,将传给脚本两个参数,一个是事件的类型,一个是事件的描述。如果sentinel.conf配 置文件中配置了这个脚本路径,那么必须保证这个脚本存在于这个路径,并且是可执行的,否则sentinel无 法正常启动成功。
    #通知脚本
    # sentinel notification-script <master-name> <script-path>
    sentinel notification-script mymaster /var/redis/notify.sh
    
    #客户端重新配置主节点参数脚本
    # 当一个master由于failover而发生改变时,这个脚本将会被调用,通知相关的客户端关于master地址已经发生改变的信息。
    #以下参数将会在调用脚本时传给脚本:
    # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
    # 目前<state>总是“failover”, # <role>是“leader”或者“observer”中的一个。
    #参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
    # 这个脚本应该是通用的,能被多次调用,不是针对性的。
    # sentinel client-reconfig-script <master-name> <script-path>
    sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
    

    搬砖路上,希望对你有帮助!可以关注一下哟,持续更新哟! 有问题可以私聊博主,快发表一下你的看法吧!

    展开全文
  • redis哨兵模式哨兵模式概述哨兵模式主要是基于前面用到的主从模式进行改造的,由于主从模式的缺陷,所以哨兵模式弥补了这一缺陷优点监控主数据库和从数据库是否正常运行主数据库出现故障时,可以自动将从数据库转换...

    redis哨兵模式

    f1dc193ad26b6f955a9549009be00667.png


    哨兵模式

    • 概述哨兵模式主要是基于前面用到的主从模式进行改造的,由于主从模式的缺陷,所以哨兵模式弥补了这一缺陷
    • 优点监控主数据库和从数据库是否正常运行主数据库出现故障时,可以自动将从数据库转换为主数据库,实现自动切换如果redis服务出现问题,会发送通知
    • 缺点主数据库出现故障时,选举切换的时候容易出现瞬间断线现象
    • 判断在线情况默认情况下,每个 Sentinel 节点会以 每秒一次 的频率对 Redis 节点和 其它Sentinel 节点发送 PING 命令,并通过节点的 回复 来判断节点是否在线。
    • 架构图
    • 下线/down主观下线主观下线 适用于所有 主节点从节点。如果在 down-after-milliseconds 毫秒内,Sentinel 没有收到 目标节点 的有效回复,则会判定 该节点主观下线只有半数个哨兵节点都主观判定主节点down掉,此时多个哨兵节点交换主观判定结果,才会判定主节点客观下线。客观下线客观下线 只适用于 主节点。如果 主节点 出现故障,Sentinel 节点会通过 sentinel is-master-down-by-addr 命令,向其它 Sentinel 节点询问对该节点的 状态判断。如果超过 个数的节点判定 主节点 不可达,则该 Sentinel 节点会判断 主节点客观下线。基本上哪个哨兵节点最先判断出这个主节点客观下线,就会在各个哨兵节点中发起投票机制,每个哨兵都投自己为领导者。最终被投为领导者的哨兵节点完成主从自动化切换的过程。当判断为主观下线时,不会进行主从切换过程。
    • 选举每个发现主服务器进入客观下线的sentinel都可以要求其他sentinel选自己为领头sentinel,选举是先到先得同时每个sentinel每次选举都会自增配置纪元,每个纪元中只会选择一个领头sentinel。如果所有超过一半的sentinel选举某sentinel领头sentinel。之后该sentinel进行故障转移操作。
    • 环境搭建参考 redis哨兵部署

    参考文章:https://juejin.im/post/5b7d226a6fb9a01a1e01ff64

    展开全文
  • redis和哨兵模式

    2020-12-25 18:33:22
    哨兵模式
  • Redis 哨兵模式本篇主要讲解Redis的哨兵模式,承接上一篇主从复制,解决主从复制的不足之处,依然是1主2从模式概述Sentinel(哨兵)是Redis的高可用性解决方案:由一个或多个Sentinel实例组成的Sentinel系统可以监视...
  • redis哨兵模式

    万次阅读 2020-05-24 16:00:00
    sentinel哨兵模式介绍 Sentinel(哨兵)是用于监控redis集群中Master状态的工具,是Redis 的高可用性解决方案,sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案,sentinel系统...
  • Redis哨兵模式讲解

    万次阅读 多人点赞 2020-06-04 13:08:18
    这不是一种推荐的方式,更多时候,我们优先考虑 哨兵模式。Redis从2.8开始正式提供了Sentinel(哨兵) 架构来解决这个问题。 谋朝篡位的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为...
  • 为什么需要哨兵模式(Sentinel)只依靠持久化方案,在服务器下线后无法恢复服务使用主从复制,在 master 节点下线后,可以手动将 slave 节点切换为 master,但是不能自动完成故障转移哨兵模式(Sentinel)主要功能监控...
  • SpringBoot整合Redis哨兵模式主从搭建 点击哨兵搭建 点击配置yaml# redis 主从哨兵配置spring:redis:database: 0host: 127.0.0.1port: 6379password:pool:max-active: 8max-wait: -1 # 连接池最大阻塞等待时间(使用...
  • Redis哨兵模式

    2021-01-29 15:01:32
    Redis哨兵模式 1、介绍哨兵模式 首先,哨兵模式是一种监控机制,并不是redis独有的。 哨兵模式是一种特殊的模式,首先redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。 其原理是:哨兵通过...
  • 为了实现master自动切换,redis为我们提供了哨兵模式,以提高redis集群的高可用。哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过...
  • 1.环境安排使用三台机器做Redis主从+哨兵模式redis-master----192.168.38.183redis-slave1-----192.168.38.184redis-slave2-----192.168.38.1372.安装Redis-三台服务器同时操作# mkdir /data ---创建安装目录# wget ...
  • 2.哨兵模式造成的redis脑裂现象原因?举例(1主1从2哨兵的情况),由于网络原因或者一些特殊原因,哨兵失去了对master节点器的感知,将会通过选举进行故障转移,将slave节点提升为master节点,这就导致了当前集群中有2...
  • redis哨兵模式哨兵模式概述哨兵模式主要是基于前面用到的主从模式进行改造的,由于主从模式的缺陷,所以哨兵模式弥补了这一缺陷优点监控主数据库和从数据库是否正常运行主数据库出现故障时,可以自动将从数据库转换...
  • 当主机出现了宕机时,需要人工手动去干预,把一台从服务器切换为主服务器,或者手动去重启主机,费时费力,而且还会导致该时间段内的服务不可用,这就要说说Redis的哨兵模式。哨兵自然就是站岗放哨,负责监控。Redis...
  • Redis哨兵模式详解

    千次阅读 2019-03-17 22:32:38
    文章目录哨兵模式什么是哨兵实现哨兵模式1.配置一主两从2.哨兵模式配置3.一个哨兵监控多个Redis主从系统实现原理主观下线客观下线选举领头哨兵故障恢复   在主从模式的Redis系统中,从数据库在整个系统中起到了...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,498
精华内容 2,599
关键字:

哨兵模式