Redis哨兵模式介绍

哨兵简介

主机"宕机"

• 将宕机的 master 下线
• 找一个 slave 作为 master
• 通知所有的 slave 连接新的 master
• 启动新的 master 和 slave
• 全量复制 *n+ 部分复制*n

存在的问题：

• 谁来确认 master 宕机了
• 重新找一个新的 master ，怎么找法？
• 修改配置后，原来的 master 恢复了怎么办？

哨兵

哨兵(sentinal)是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 master 并将所有的 slave 连接到新的 master。

哨兵的作用

• 监控
  • 不断的检查 master 和 slave 是否正常运行
  • master 存活检测、master 与 slave 运行情况检测
• 通知（提醒）
• 自动故障转移
  • 断开 master 与 slave 连接，选取一个 slave 作为 master，将其他的 slave 连接到新的 master，并告知客户端新的服务器地址

注意：

• 哨兵也是一台 redis 服务器，只是不提供数据服务
• 通常哨兵配置的数量为单数

启用哨兵模式

配置哨兵

• 配置一拖二的主从结构

• 配置三个哨兵（配置相同，端口不同）

  • 参看 sentinel.conf

• 启动哨兵

  redis-sentinel sentinel-端口号.conf

哨兵配置项说明：

# 哨兵服务端口
port 26379

# 哨兵工作信息存储目录
dir /tmp

# 监控 主 连接字符串 哨兵判挂标准（几个哨兵认定他挂了，就判定为主挂了，通常为哨兵数量的一半加一）
sentinel monitor mymaster 127.0.0.1 6379 2

# 主 连接多长时间无响应，就认定它挂了（默认 30s）
sentinel down-after-milliseconds mymaster 30000

# 主挂了之后，新的主上任同步数据的路线数量，数值越小，对服务器压力越小
sentinel parallel-syncs mymaster 1

# 新主同步数据时，多长时间同步完算有效 （默认 180s）
sentinel failover-timeout mymaster 180000

主 redis-6379.conf

port 6379
daemonize no
#logfile "6379.log"
dir /redis-4.0.0/data
dbfilename dump-6379.rdb
rdbcompression yes
rdbchecksum yes
save 10 2
appendonly yes
appendfsync always
appendfilename appendonly-6379.aof
bind 127.0.0.1
databases 16

从1 redis-6380.conf

port 6380
daemonize no
#logfile "6380.log"
dir /redis-4.0.0/data
slaveof 127.0.0.1 6379

从2 redis-6381.conf

port 6381
daemonize no
#logfile "6381.log"
dir /redis-4.0.0/data
slaveof 127.0.0.1 6379

哨兵1 sentinel-26379.conf

port 26379
dir /redis-4.0.0/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

哨兵2 sentinel-26380.conf

port 26380
dir /redis-4.0.0/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

哨兵3 sentinel-26381.conf

port 26381
dir /redis-4.0.0/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

启动哨兵

redis-server /redis-4.0.0/conf/redis-6379.conf

redis-server /redis-4.0.0/conf/redis-6380.conf

redis-server /redis-4.0.0/conf/redis-6381.conf

redis-sentinel /redis-4.0.0/conf/sentinel-26379.conf

redis-sentinel /redis-4.0.0/conf/sentinel-26380.conf

redis-sentinel /redis-4.0.0/conf/sentinel-26381.conf


# 停止 主  ctrl+c

官方原版配置文件：sentinel.conf

# 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.
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 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:
#
# sentinel auth-pass mymaster mysuper--secret-0123passw0rd

# sentinel auth-user <master-name> <username>
#
# this is useful in order to authenticate to instances having acl capabilities,
# that is, running redis 6.0 or greater. when just auth-pass is provided the
# sentinel instance will authenticate to redis using the old "auth <pass>"
# method. when also an username is provided, it will use "auth <user> <pass>".
# in the redis servers side, the acl to provide just minimal access to
# sentinel instances, should be configured along the following lines:
#
#     user sentinel-user >somepassword +client +subscribe +publish \
#                        +ping +info +multi +slaveof +config +client +exec on

# 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 down-after-milliseconds mymaster 30000

# requirepass <password>
#
# you can configure sentinel itself to require a password, however when doing
# so sentinel will try to authenticate with the same password to all the
# other sentinels. so you need to configure all your sentinels in a given
# group with the same "requirepass" password. check the following documentation
# for more info: https://redis.io/topics/sentinel

# 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.
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.
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.

# 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 itself:
#
# sentinel rename-command mymaster config config

到此这篇关于redis哨兵模式介绍的文章就介绍到这了。希望对大家的学习有所帮助，也希望大家多多支持。