Redis 감시 모드에서 마스터-슬레이브 장애 조치를 구현하는 방법

Redis Sentinel은 하나의 아키텍처에서 여러 Sentinel 프로세스(진행)를 실행할 수 있습니다. 이러한 프로세스는 메시지 수신 여부에 대한 정보를 사용합니다. 서버는 오프라인 상태이며 계약 프로토콜을 사용하여 자동 장애 조치를 수행할지 여부와 새 마스터 서버로 선택할 슬레이브 서버를 결정합니다.

Redis Sentinel은 별도의 실행 파일인 redis-sentinel로 출시되지만 실제로는 특수 모드에서 실행되는 Redis 서버일 뿐입니다. --sentinel 옵션을 지정하면 일반 Redis 서버를 시작할 수 있습니다. Redis Sentinel을 시작합니다.

Sentinel 시스템은 여러 Redis 서버(인스턴스)를 관리하는 데 사용됩니다. 시스템은 다음 세 가지 작업을 수행합니다.

1. 모니터링: Sentinel은 마스터 서버인지 여부를 지속적으로 확인합니다. 슬레이브 서버는 정상적으로 작동하고 있습니다.

2. 알림: 모니터링되는 Redis 서버에 문제가 있는 경우 Sentinel은 API를 통해 관리자나 다른 애플리케이션에 알림을 보낼 수 있습니다.

3. 자동 장애 조치: 마스터 서버가 제대로 작동하지 않으면 Sentinel은 장애가 발생한 마스터 서버의 슬레이브 서버 중 하나를 새 서버로 업그레이드합니다. 클라이언트가 실패한 마스터 서버에 연결을 시도할 때 실패한 마스터 서버의 다른 슬레이브 서버가 새 마스터 서버를 복제하도록 변경하면 클러스터도 새 마스터 서버의 주소를 클라이언트에 반환합니다. 클러스터는 새 마스터 서버를 사용할 수 있습니다. 마스터 서버는 실패한 서버를 대체합니다.

Configuration

마스터가 다운되면 슬레이브가 인계받아 새 마스터가 됩니다. 실제로 이는 MySQL의 이중 마스터 모드와 동일하며 상호 마스터-슬레이브 모드를 사용하려면 redis-sentinel 프로그램과 sentinel.conf 구성 파일이 필요합니다.

mkdir -p /usr/local/redis
mkdir -p /usr/local/redis/6379
mkdir -p /usr/local/redis/6380
mkdir -p /usr/local/redis/redis_cluster

기본 구성

vim redis_6379.conf

daemonize yes
pidfile /usr/local/redis/6379/redis_6379.pid
port 6379
tcp-backlog 128
timeout 0
tcp-keepalive 0
loglevel notice
logfile ""
databases 16
save 900 1    ###save
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb   ###dbfile
dir "/usr/local/redis/6379"
masterauth "123456"
requirepass "123456"
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes

vim sentinel_1.conf

Sentinel 파일 구성#🎜 🎜 #

port 6000
dir "/usr/local/redis/sentinel"
# 守护进程模式
daemonize yes
protected-mode no
logfile "/usr/local/sentinel/sentinel.log"

구성에서

vim redis_6380.conf

daemonize yes
pidfile "/usr/local/redis/6380/redis_6380.pid"
port 6380
tcp-backlog 128
timeout 0
tcp-keepalive 0
loglevel notice
logfile ""
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump.rdb"
dir "/usr/local/redis/6380"
masterauth "123456"
requirepass "123456"
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes

vim sentinel_2.conf

#sentinel端口
port 6000
#工作路径，注意路径不要和主重复
dir "/usr/local/sentinel"
# 守护进程模式
daemonize yes
protected-mode no
# 指明日志文件名
logfile "/usr/local/sentinel/sentinel.log"

#🎜🎜 # 참고:

1 애플리케이션은 센티넬 포트에 연결하고 다른 마스터 이름을 지정하여 특정 마스터 복제본에 연결합니다.

2. Sentinel 구성 파일에서는 마스터-슬레이브 복제에서 마스터 복제본 IP와 포트만 구성하면 됩니다. 마스터-슬레이브 전환 시 Sentinel은 자동으로 마스터 복제본 IP를 수정합니다. Sentinel 구성 파일을 기본 복제본 IP로 복사합니다.

3. 동시에 여러 마스터-슬레이브 복제를 모니터링하도록 Sentinel 구성 파일을 구성할 수 있습니다.

4. 마스터-슬레이브 장애 모니터링에는 단일 센티널을 사용할 수 있지만 센티널 프로세스가 하나만 있는 경우 이 프로세스가 잘못 실행되거나 네트워크가 차단되면 마스터-슬레이브 전환이 발생합니다. (단일 질문) <쿼럼>이 2는 투표 수를 나타냅니다. 두 센티널이 마스터를 더 이상 사용할 수 없다고 판단하면 장애 조치가 실행되고 그 후에만 가능합니다. 마스터는 실제로 사용할 수 없는 것으로 간주됩니다. (Sentinel 클러스터의 각 Sentinel은 가십 프로토콜을 통해 서로 통신합니다.) 따라서 합리적인 구성은 여러 Sentinel 프로세스를 동시에 시작하는 것이며 서로 다른 서버에서 시작하는 것이 가장 좋습니다.

5. mymaster는 전체 네트워크 환경에서 고유해야 합니다. Sentinel은 네트워크 환경이 연결되어 있는 한 자동으로 mastername을 통해 관계를 설정합니다.

redis 시작

1. 마스터와 슬레이브를 모두 시작해야 합니다

src/redis-server redis.conf

2. -슬레이브 관계#🎜🎜 #

redis-cli -p 6380
slaveof 192.168.137.40 6379

센티널 구성

마스터와 슬레이브 센티널 모두 시작해야 하며 "redis-server sentinel과 같은 redis-server를 통해서도 시작할 수 있습니다. .conf --sentinel"

1. 센트리 시작

src/redis-sentinel sentinel.conf

2. 센트리에 로그인합니다(실행하려면 두 센트리 모두 로그인해야 함). 마스터-슬레이브 추가 모니터링 정보

redis-cli -p 6000

sentinel monitor mymaster 192.168.137.40 6379 2
sentinel set mymaster down-after-milliseconds 5000
sentinel set mymaster failover-timeout 15000
sentinel set mymaster auth-pass 123456

오류 처리 시작

오류 1:

#🎜🎜 #WARNING overcommit_memory가 0으로 설정되었습니다! 메모리 부족 상태에서 백그라운드 저장이 실패할 수 있습니다. 이 문제를 해결하려면 /etc/sysctl.conf에 'vm.overcommit_memory = 1'을 추가한 다음 재부팅하거나 'sysctl vm.overcommit_memory=1' 명령을 실행하세요. '를 적용하려면

2A 솔루션(overcommit_memory)

1. echo "vm.overcommit_memory=1" > conf 또는 vi /etcsysctl.conf 그런 다음 재부팅하여 머신을 다시 시작합니다#🎜🎜 #

2. echo 1 > /proc/sys/vm/overcommit_memory 머신을 시작하지 않고도 적용됩니다

# 🎜🎜#

overcommit_memory 매개변수 설명:

# 🎜🎜#메모리 할당 정책 설정(선택 사항, 서버의 실제 상황에 따라 설정)

/proc /sys/vm/overcommit_memory

선택 값: 0, 1 ,2.

0은 애플리케이션 프로세스가 사용할 수 있는 메모리가 충분한지 확인한다는 의미입니다. 사용 가능한 메모리가 충분하면 메모리 애플리케이션이 허용됩니다. 그렇지 않으면 메모리 애플리케이션이 실패하고 오류가 발생합니다. 신청 절차로 돌아갑니다.

1은 커널이 현재 메모리 상태에 관계없이 모든 물리적 메모리를 할당하도록 허용함을 나타냅니다.

2는 커널이 모든 물리적 메모리와 스왑 공간의 합을 초과하는 메모리를 할당할 수 있음을 나타냅니다

注意：redis在dump数据的时候，会fork出一个子进程，理论上child进程所占用的内存和parent是一样的，比如parent占用 的内存为8G，这个时候也要同样分配8G的内存给child,如果内存无法负担，往往会造成redis服务器的down机或者IO负载过高，效率下降。所 以这里比较优化的内存分配策略应该设置为 1（表示内核允许分配所有的物理内存，而不管当前的内存状态如何）。

这里又涉及到Overcommit和OOM。

什么是Overcommit和OOM

在Unix中，当一个用户进程使用malloc()函数申请内存时，假如返回值是NULL，则这个进程知道当前没有可用内存空间，就会做相应的处理工作。许多进程会打印错误信息并退出。

Linux使用另外一种处理方式，它对大部分申请内存的请求都回复"yes"，以便能跑更多更大的程序。因为申请内存后，并不会马上使用内存。这种技术叫做Overcommit。

当内存不足时，会发生OOM killer(OOM=out-of-memory)。它会选择杀死一些进程(用户态进程，不是内核线程)，以便释放内存。

Overcommit的策略

Linux下overcommit有三种策略(Documentation/vm/overcommit-accounting)：

0. 启发式策略。合理的overcommit会被接受，不合理的overcommit会被拒绝。

1. 任何overcommit都会被接受。

2. 当系统分配的内存超过swap+N%*物理RAM(N%由vm.overcommit_ratio决定)时，会拒绝commit。

overcommit的策略通过vm.overcommit_memory设置。

overcommit的百分比由vm.overcommit_ratio设置。

# echo 2 > /proc/sys/vm/overcommit_memory

# echo 80 > /proc/sys/vm/overcommit_ratio

当oom-killer发生时，linux会选择杀死哪些进程

选择进程的函数是oom_badness函数(在mm/oom_kill.c中)，该函数会计算每个进程的点数(0~1000)。

点数越高，这个进程越有可能被杀死。

每个进程的点数跟oom_score_adj有关，而且oom_score_adj可以被设置(-1000最低，1000最高)。

错误2：
WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

echo 511 > /proc/sys/net/core/somaxconn

错误3：

16433:X 12 Jun 14:52:37.734 * Increased maximum number of open files to 10032 (it was originally set to 1024).

新装的linux默认只有1024，当负载较大时，会经常出现error: too many open files

ulimit -a：使用可以查看当前系统的所有限制值

vim /etc/security/limits.conf

在文件的末尾加上

* soft nofile 65535
* hard nofile 65535

执行su或者重新关闭连接用户再执行ulimit -a就可以查看修改后的结果。

故障切换机制

1. 启动群集后，群集程序默认会在从库的redis文件中加入连接主的配置

# Generated by CONFIG REWRITE
slaveof 192.168.137.40 6379

2.启动群集之后，群集程序默认会在主从的sentinel.conf文件中加入群集信息

主：

port 26379
dir "/usr/local/redis-6379"
# 守护进程模式
daemonize yes
# 指明日志文件名
logfile "./sentinel.log"
sentinel monitor mymaster 192.168.137.40 6379 1
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 18000
sentinel auth-pass mymaster 123456
# Generated by CONFIG REWRITE
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 1
sentinel known-slave mymaster 192.168.137.40 6380
sentinel known-sentinel mymaster 192.168.137.40 26380 c77c5f64aaad0137a228875e531c7127ceeb5c3f
sentinel current-epoch 1

从：

#sentinel端口
port 26380
#工作路径
dir "/usr/local/redis-6380"
# 守护进程模式
daemonize yes
# 指明日志文件名
logfile "./sentinel.log"
#哨兵监控的master，主从配置一样，在进行主从切换时6379会变成当前的master端口，
sentinel monitor mymaster 192.168.137.40 6379 1
# master或slave多长时间（默认30秒）不能使用后标记为s_down状态。
sentinel down-after-milliseconds mymaster 5000
#若sentinel在该配置值内未能完成failover操作（即故障时master/slave自动切换），则认为本次failover失败。
sentinel failover-timeout mymaster 18000
#设置master和slaves验证密码
sentinel auth-pass mymaster 123456
#哨兵程序自动添加的部分
# Generated by CONFIG REWRITE
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 1
###指明了当前群集的从库的ip和端口，在主从切换时该值会改变
sentinel known-slave mymaster 192.168.137.40 6380
###除了当前的哨兵还有哪些监控的哨兵
sentinel known-sentinel mymaster 192.168.137.40 26379 7a88891a6147e202a53601ca16a3d438e9d55c9d
sentinel current-epoch 1

模拟主故障

[root@monitor redis-6380]# ps -ef|grep redis
root       4171      1  0 14:20 ?        00:00:15 /usr/local/redis-6379/src/redis-server *:6379                          
root       4175      1  0 14:20 ?        00:00:15 /usr/local/redis-6380/src/redis-server *:6380                          
root       4305      1  0 15:28 ?        00:00:05 /usr/local/redis-6379/src/redis-sentinel *:26379 [sentinel]                            
root       4306      1  0 15:28 ?        00:00:05 /usr/local/redis-6380/src/redis-sentinel *:26380 [sentinel]                            
root       4337   4144  0 15:56 pts/1    00:00:00 grep redis
[root@monitor redis-6380]# kill -9 4171
[root@monitor redis-6380]# ps -ef|grep redis
root       4175      1  0 14:20 ?        00:00:15 /usr/local/redis-6380/src/redis-server *:6380                          
root       4305      1  0 15:28 ?        00:00:05 /usr/local/redis-6379/src/redis-sentinel *:26379 [sentinel]                            
root       4306      1  0 15:28 ?        00:00:05 /usr/local/redis-6380/src/redis-sentinel *:26380 [sentinel]                            
root       4339   4144  0 15:56 pts/1    00:00:00 grep redis
[root@monitor redis-6380]#

从哨兵配置文件中可以看到当前的主库的已经发生了改变

总结

redis的哨兵端口26379、26380使用客户端软件无法连接，使用程序可以连接，客户端软件只能直接连接6379和6380端口。使用哨兵监控当主故障后会自动切换从为主，当主启动后就变成了从。有看到别人只配置单哨兵26379的这种情况，这种情况无法保证哨兵程序自身的高可用。

更多redis知识请关注redis数据库教程栏目。

위 내용은 Redis 감시 모드에서 마스터-슬레이브 장애 조치를 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!