Redis主从复制 一主二仆 哨兵监控

准备工作

从官网下载redis,且安装完成（网上有很多教程，不在介绍）

1.将redis.conf文件复制三份，原文件保证不动

2.修改一下属性，三个文件对应修改

redis6379.conf 6379作为主

port 6379
# 开启后台运行
daemonize yes 
#设置pid进程
pidfile "/var/run/redis6379.pid"
#设置log文件
logfile "redis6379.log"
#RDB持久化默认是打开，设置一下名字 也可以关闭该功能  sava ""  rdb持久化下次更新
dbfilename "dump6379.rdb"  

redis6380.conf 6380作为仆

# 设置从服务器  这两句加在 bind 127.0.0.1 ::1 下面就行，位置可以随意放
slaveof 127.0.0.1 6379
# 设置从服务器密码，我这里没使用 所以注释了
# masterauth 123456
port 6380
# 开启后台运行
daemonize yes 
#设置pid进程
pidfile "/var/run/redis6380.pid"
#设置log文件
logfile "redis6380.log"
#RDB持久化默认是打开，设置一下名字 也可以关闭该功能  sava ""  rdb持久化下次更新
dbfilename "dump6380.rdb"  

redis6381.conf 6381 作为仆

# 设置从服务器  这两句加在 bind 127.0.0.1 ::1 下面就行，位置可以随意放
slaveof 127.0.0.1 6379
# 设置从服务器密码，我这里没使用 所以注释了
# masterauth 123456
port 6381
# 开启后台运行
daemonize yes 
#设置pid进程
pidfile "/var/run/redis681pid"
#设置log文件
logfile "redis6381.log"
#RDB持久化默认是打开，设置一下名字 也可以关闭该功能  sava ""  rdb持久化下次更新
dbfilename "dump6381.rdb"  

3.启动3个redis

在redis bin目录下执行

redis-server /usr/local/etc/redis6379.conf
redis-server /usr/local/etc/redis6380.conf
redis-server /usr/local/etc/redis6381.conf

接着打开三个命令窗口，分别执行 我这里没配置密码 所以直接进入

redis-cli -p 6379
redis-cli -p 6380
redis-cli -p 6381

启动后分别在三个窗口执行

info replication

效果如下

可以看出，6379为主master 6380,6381为仆slave
接着在master执行

set t1 v1
set t2 v2
set t3 v3

在 slave 执行keys * 查看效果，如下

此时已实现主从复制 一主二仆 且读写分离
尝试在slave set a1 v1

127.0.0.1:6380> set a1 v1
(error) READONLY You can't write against a read only replica.

发现是只读

4.在redis bin目录找到redis-sentinel.conf（默认的哨兵配置文件）并复制3份

如果你的里面没有，我在文末贴一个默认的配置文件
26379配置如下

# 禁止保护模式
protected-mode no# 配置监听的主服务器，这里sentinel monitor代表监控，redis6379代表服务器的名称，1代表只有1个或1个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。
sentinel monitor redis6379 127.0.0.1 6379 1
# sentinel author-pass定义服务的密码，redis6379是服务名称，123456是Redis服务器密码
# sentinel auth-pass <master-name> <password>
# sentinel auth-pass redis6379 123456
# 
port 26379
# 开启后台运行 且设置pid
daemonize yes
pidfile /var/run/redis-sentinel26379.pid

26380、26381跟26379一样，只需要将端口port和进程PID修改了就可以

在redis bin目录下，启动哨兵

redis-sentinel /usr/local/etc/redis-sentinel6379.conf➜  bin redis-sentinel /usr/local/etc/redis-sentinel6379.conf
8276:X 19 Jun 2020 17:53:36.274 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8276:X 19 Jun 2020 17:53:36.274 # Redis version=6.0.1, bits=64, commit=00000000, modified=0, pid=8276, just started
8276:X 19 Jun 2020 17:53:36.274 # Configuration loaded
➜  bin redis-sentinel /usr/local/etc/redis-sentinel6380.conf
8285:X 19 Jun 2020 17:53:43.505 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8285:X 19 Jun 2020 17:53:43.505 # Redis version=6.0.1, bits=64, commit=00000000, modified=0, pid=8285, just started
8285:X 19 Jun 2020 17:53:43.505 # Configuration loaded
➜  bin redis-sentinel /usr/local/etc/redis-sentinel6381.conf
8294:X 19 Jun 2020 17:53:50.609 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8294:X 19 Jun 2020 17:53:50.609 # Redis version=6.0.1, bits=64, commit=00000000, modified=0, pid=8294, just started
8294:X 19 Jun 2020 17:53:50.609 # Configuration loaded
➜  bin

启动成功后，进入6379服务，接着shutdown 将6379关闭
此时会发现6380变成了master

接着再降6379启动

此时6380成了master 6379 6381成了slave

至此搭建完毕

redis-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 itsef:
#
# SENTINEL rename-command mymaster CONFIG CONFIG

本文是在学习过程中整理，如有错误欢迎各位大佬指正！O(∩_∩)O

下次更新RDB和AOF持久化……