redis sentinel実戦

知識ポイントの準備
redis sentinelを導入する前に、次の点を理解する必要があります.1.公式ドキュメントではredis sentinelの導入に最低3つのsentinelノードを推奨していますが、その原因は主に2つあります.(1)マルチノードsentinelが実行されている場合、quorumが設定したパラメータに達している場合にのみ、masterはodown(客観的にオフライン)と見なされますが、この場合はフェイルオーバは発生しません.(2)フェイルオーバ前に、ほとんどのsentinelを介してリーダーを選出し、フェイルオーバを許可する必要がある.2つのsentinelしかない場合、masterとそのうちの1つのsentinelが停止すると、2つ目のポイントに基づいて、leaderを推挙してfailoverを許可できないことが発生します.また,脳裂が発生した場合,クライアントはどちらが書き込むmasterであるかを判断できない.
2.主観的な下線(sdown)と客観的な下線(odown)は、masterがdown-after-milliseconds時間内に達成できない場合、sentinelはmasterがsdownであると考えている.quorum個数に達したsentinelがmasterをsdownとすると、sentinelはmasterをodownとし、その後sentine選挙を行いfailoverを行う.
3.failoverプロセスでは、parallel-syncsは、新しいmasterを同時に同期できるslaveが最大何個あるかを指定します.この数字が小さいほど、failoverを完了するのにかかる時間が長くなりますが、この数字が大きいほど、replicationのために使用できないslaveが多くなることを意味します.この値を1に設定することで、毎回1つのslaveだけがコマンドリクエストを処理できない状態にあることを保証できます.
4.redisは非同期レプリケーションであるため、masterがネットワークによって分離されると、クライアントはmasterにデータを書くことができるが、ネットワークが回復すると、masterはredisのslaveになり、ネットワーク分離中にクライアントがmasterに書いたデータが失われる.このような状況を回避するには、redisで次の2つのパラメータを構成する必要があります.

min-slaves-to-write 1
min-slaves-max-lag 10

masterがネットワークから隔離されている場合、masterがmin-slaves-to-write個数のslaveにデータをコピーできない場合、またはmasterがmin-slaves-max-lag時間内にslaveにデータをコピーできない場合、masterはクライアントの書き込みを受け入れることができず、この方法でデータ損失を緩和することができます.
以上より、redis sentinelのいくつかの動作メカニズムを理解しました.次に、導入します.
環境準備
ip
redisポート
ロール＃ロール＃
sentinelポート
10.10.123.86
6380
slave
26379
10.10.123.87
6379
slave
26379
10.10.123.88
6379
master
26379
配置
1.3つのノードにredisを配置する

#master  
bind 127.0.0.1 10.10.123.88
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile "/var/run/redis_6379.pid"
loglevel notice
logfile "/usr/local/redis/logs/6379.log"
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/data/6379"
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 no
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-size -2
list-compress-depth 0
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

＃  slave     bind           ：
slaveof 10.10.123.88 6379

2.3つのノードでsentinelを構成する

bind 0.0.0.0
port 26379
daemonize yes
dir "/usr/local/redis/data/"
logfile "/usr/local/redis/logs/sentinel.log"
sentinel monitor mymaster 10.10.123.88 6379 2
sentinel down-after-milliseconds mymaster 6000
sentinel failover-timeout mymaster 18000
sentinel parallel-syncs mymaster 1

注意:デフォルトではsentinelはprotected-modeにあります.この場合、ローカルループバックアドレスのみが許可され、外部はip+portでアクセスできません.そのため、他のsentinelはdown-after-milliseconds 6000時間経過すると、sdown sentinelの場合があります.このモードは、コンフィギュレーションファイルでbindまたはprotected-mode noを構成することでオフにできます.ここではbind 0.0.0.0を使用することを推奨します.
3.3ノードredisを起動する

[test@test ~] redis-server 6379.conf
#  redis  
[test@test ~] redis-cli -h 10.10.123.88 -p 6379
10.10.123.88:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.10.123.86,port=6380,state=online,offset=4526241,lag=1
slave1:ip=10.10.123.87,port=6379,state=online,offset=4526241,lag=0
master_repl_offset:4526241
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:3477666
repl_backlog_histlen:1048576

4.3つのノードsentinelを起動する

[test@test ~] redis-sentinel sentinel.conf
＃      
22123:X 27 Oct 09:21:41.458 # Sentinel ID is 78aae51608ef7ee160001b9466ffb01193195526
22123:X 27 Oct 09:21:41.458 # +monitor master mymaster 10.10.123.88 6379 quorum 2
22123:X 27 Oct 09:21:41.459 * +slave slave 10.10.123.87:6379 10.10.123.87 6379 @ mymaster 10.10.123.88 6379
22123:X 27 Oct 09:21:41.462 * +slave slave 10.10.123.86:6380 10.10.123.86 6380 @ mymaster 10.10.123.88 6379
22123:X 27 Oct 09:23:28.981 * +sentinel sentinel 9918ab7835d217f91768857d8af99d30df40ed8c 10.10.123.86 26379 @ mymaster 10.10.123.88 6379
22123:X 27 Oct 09:24:44.045 * +sentinel sentinel 4d6724c49b78bc9842cfb855cc610916e4c5b530 10.10.123.87 26379 @ mymaster 10.10.123.88 6379

＃  sentinel  
[test@test ~] redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=10.10.123.88:6379,slaves=2,sentinels=3

bindを構成することによってaddressは最初にipを表示するが、そうでなければ127.0.0.1を表示する.以上より,masterの名前はmymasterで,slaveノードが2つ,sentinelノードが3つあることが分かった.

＃  master     
127.0.0.1:26379> sentinel master mymaster
＃  slave     
127.0.0.1:26379> sentinel slaves mymaster

ここでflagsは現在のステータスであり、masterまたはslaveサービスが停止すると現在のステータス情報が表示されます.
以上の手順で、3つのノードのredis+sentinel環境が実行され、master、slave、sentinelを停止してテストするだけです.
注意:masterノードのみsdownが表示され、slaveとsentinelではodownのみが表示されます.