redis sentinel 클러스터 그래픽 튜토리얼

Sentinel은 Redis를 위한 고가용성 솔루션입니다. 하나 이상의 Sentinel 인스턴스로 구성된 Sentinel 시스템은 원하는 수의 마스터 서버는 물론 이러한 마스터 서버 아래의 모든 슬레이브 서버를 모니터링할 수 있습니다. 서버가 오프라인이 되면 오프라인 마스터 서버 아래의 슬레이브 서버가 자동으로 새 마스터 서버로 업그레이드됩니다. 권장 사항: redis 비디오 튜토리얼

예:

Server1이 오프라인이 된 후:

Server2를 새 기본 서버로 업그레이드:

2.

Sentinel 클러스터를 설명하기 전에 먼저 간단한 마스터-슬레이브 분리(읽기-쓰기 분리)를 구축해 보겠습니다.

우선, 기본적으로 모든 사람이 redis를 설치했습니다. 그런 다음 redis.conf의 여러 복사본을 복사하고 여러 redis 서비스를 구별하기 위해 여러 디렉터리를 만듭니다.

여기 각 디렉터리에는 자체 Redis가 있습니다. conf 구성 파일 다음으로 먼저 메인 서버의 구성 파일을 설정합니다.

1. 마스터 구성

1. 포트를 수정합니다.

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6380

Redis의 기본 포트는 6379입니다. 여기서는 메인 서버의 포트를 6380

으로 설정합니다. pidfile을 수정합니다

# If a pid file is specified, Redis writes it where specified at startup
# and removes it at exit.
#
# When the server runs non daemonized, no pid file is created if none is
# specified in the configuration. When the server is daemonized, the pid file
# is used even if not specified, defaulting to "/var/run/redis.pid".
#
# Creating a pid file is best effort: if Redis is not able to create it
# nothing bad happens, the server will start and run normally.
pidfile /var/run/redis_6380.pid

pidfile입니다. redis, linux 우리에게 할당된 pid 프로세스 번호를 수정하지 않으면 후속 redis 서비스 시작에 영향을 미칩니다

3. redis를 시작하세요

redis를 시작하면 redis가 포트 6380

을 점유하고 있음을 알 수 있습니다.

Enter Client

redis-cli -p 6380
127.0.0.1:6380> info
...
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
...

현재 Redis의 역할은 마스터가 시작한 서비스임을 알 수 있습니다.

2. 슬레이브 구성

위의 마스터 구성과 마찬가지로 포트 번호와 pid 파일을 수정해야 합니다. 수정 후 슬레이브 서비스를 구성하는 방법에는 두 가지가 있습니다

1.

################################# REPLICATION #################################

# Master-Slave replication. Use slaveof to make a Redis instance a copy of
# another Redis server. A few things to understand ASAP about Redis replication.
#
# 1) Redis replication is asynchronous, but you can configure a master to
#    stop accepting writes if it appears to be not connected with at least
#    a given number of slaves.
# 2) Redis slaves are able to perform a partial resynchronization with the
#    master if the replication link is lost for a relatively small amount of
#    time. You may want to configure the replication backlog size (see the next
#    sections of this file) with a sensible value depending on your needs.
# 3) Replication is automatic and does not need user intervention. After a
#    network partition slaves automatically try to reconnect to masters
#    and resynchronize with them.
#
# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6380

구성 파일에서 Slaveof 속성을 직접 수정할 수 있습니다. 메인 서버의 IP 주소와 포트 번호를 직접 구성합니다. 여기 메인 서버에 구성 비밀번호가 있는 경우

masterauth를 구성하여 링크 비밀번호를 설정할 수 있습니다

# If the master is password protected (using the "requirepass" configuration
# directive below) it is possible to tell the slave to authenticate before
# starting the replication synchronization process, otherwise the master will
# refuse the slave request.
#
# masterauth <master-password>

redis 서비스 시작:

현재 두 개가 실행 중인 것을 볼 수 있습니다. 6381의 클라이언트에 들어가서 그의 상태를 살펴보겠습니다.

# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:71
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

현재 Redis가 슬레이브 서비스 역할임을 알 수 있습니다. , 6380 서비스에 연결되었습니다.

2. 서비스 시작 후 설정

포트 6382의 서버 구성 파일을 수정한 후 서비스를 시작합니다.

클라이언트에 들어가서 현재 서버의 상태를 확인합니다.

# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

다음을 볼 수 있습니다. 현재 서버의 상태가 마스터 서비스로 실행되면 다음으로 상태를 수정하겠습니다:

127.0.0.1:6382> slaveof 127.0.0.1 6380

//修改后状态
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:617
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

3. 요약

먼저 마스터의 현재 상태를 살펴보겠습니다.

# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=785,lag=0
slave1:ip=127.0.0.1,port=6382,state=online,offset=785,lag=0
master_repl_offset:785
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:784

두 개의 슬레이브 서비스가 이미 메인 서버에 연결되어 있는데, 위 두 구성의 차이점은 슬레이브의 연결이 끊겼다가 다시 연결될 때

클래스 구성 파일을 수정하면 다시 연결된 후 마스터에 연결되고 동기화됩니다.

메인 서버에 수동으로 연결하면 슬레이브 서버는 자체 로컬 RDB 응답 데이터를 읽고 자동으로 메인 서비스에 연결하지 않습니다.

읽기-쓰기를 설정해야 하는 경우 분리하려면 메인 서버에서만 설정하면 됩니다.

# Note: read only slaves are not designed to be exposed to untrusted clients
# on the internet. It's just a protection layer against misuse of the instance.
# Still a read only slave exports by default all the administrative commands
# such as CONFIG, DEBUG, and so forth. To a limited extent you can improve
# security of read only slaves using 'rename-command' to shadow all the
# administrative / dangerous commands.
slave-read-only yes

3. Sentinel Sentinel

1. 포트 구성

sentinel.conf 구성 파일에서 포트 속성을 찾을 수 있습니다. 일반적인 상황에서는 Redis를 모니터링하려면 최소한 3개의 센티널이 필요합니다. 포트를 수정하여 여러 개의 센티널 서비스를 시작할 수 있습니다.

# port <sentinel-port># The port that this sentinel instance will run on
port 26379

2. 메인 서버의 IP와 포트를 구성합니다

리스닝 포트를 6380으로 변경하고 가중치 2를 추가합니다. 여기서 가중치는 메인 서버로 업그레이드해야 하는 서버를 계산하는 데 사용됩니다.

# 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.
#
# Slaves are auto-discovered, so you don&#39;t need to specify slaves in
# any way. Sentinel itself will rewrite this configuration file adding
# the slaves using additional configuration options.
# Also note that the configuration file is rewritten when a
# slave 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 6380 2

3. Sentinel 시작

/sentinel$ redis-sentinel sentinel.conf

Sentinel이 시작되면 이제 마스터 서버 1개와 슬레이브 서버 2개가 있는 것을 모니터링합니다

当我们把其中一个从服务器器关闭之后，我们可以看到日志：

10894:X 30 Dec 16:27:03.670 # +sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

日志表示，6381这个从服务器已经从主服务器中脱离了出来，我们重新把6381 接回去。

10894:X 30 Dec 16:28:43.288 * +reboot slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 638010894:X 30 Dec
16:28:43.365 # -sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

4、关闭Master 

我们手动关闭Master 之后，sentinel 在监听master 确实是断线了之后，将会开始计算权值，然后重新分配主服务器

我们可以看到，6380主服务器断了之后，sentinel 帮我们选了6382作为新的主服务器

我们进到6382的客户端，查看他的状态：

# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=13751,lag=0
master_repl_offset:13751
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:13750

我们可以看到 6382，重slave 荣升为master 

127.0.0.1:6382> set name jaycekon
OK

原本的没有权限写，也得到了相应的权限

5、重连Master

大家可能会好奇，如果master 重连之后，会不会抢回属于他的位置，答案是否定的，就比如你被一个小弟抢了你老大的位置，他肯给回你这个位置吗。因此当master 回来之后，他也只能当个小弟　　

4、Sentinel 总结

一、Sentinel的作用：

A、Master 状态监测

B、如果Master 异常，则会进行Master-slave 转换，将其中一个Slave作为Master，将之前的Master作为Slave 

C、Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换 

二、Sentinel的工作方式:

1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 

2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。 

3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 

4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 

5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 

6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 

7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。 

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

更多redis相关文章请关注redis数据库教程栏目。

위 내용은 redis sentinel 클러스터 그래픽 튜토리얼의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!