Redis Sentinelの基本構築
Redis Sentinelの概念
Redisマスターモードでは、一旦メインノードが故障のためにサービスを提供できなくなると、人工的にノードからマスタノードにアップグレードする必要があることを知っています。その後、多くのアプリケーションシーンにおいて、このような障害処理の方法は受け入れられない。アプリケーションは、現在の利用可能なノードをリアルタイムで感知する必要がある。この問題を解決するために、Redis Sentinelが生まれました。「哨兵」とも言います。
sentinelを紹介する前に、いくつかのredisの概念を理解します。
メインノードマスタ：Redisプロセス、メインサービス
ノードslaave:redisプロセスからサービス
Redisデータノード：マスタノードとスレーブノード
Sentinelノード：Redisデータノードを監視し、独立したsentinelプロセス
Sentinelノードの集合：いくつかのSentinelノードの抽象的な組み合わせ、いくつかのsentinelノードプロセス
Redis Sentinel：Redis高利用可能な実施形態、sentinelノードセットとredisデータノードプロセス
01マスタコピー問題
前の文章では、主従レプリカについて述べましたが、ノードから主ノードのトラブルシューティングノードとして利用できます。
1、一度メインノードが故障したら、ノードからメインノードに昇進するプロセスとアプリケーションは、新しいマスターノードを調整するプロセスを調整するために、すべて人為的な干渉が必要である。
2、メインノードの書き込み能力はシングルマシンの制限を受けやすいです。
3、メインノードの記憶能力はシングルマシンの制限を受けやすい。
一般的な方法の一つは、シナリオを使用してノードからの役割の切り替えをトリガすることであり、例えば、1つのマスタ2のスレーブ構造において、マスタノードmasterを仮定して、ノードslaave 1から、slaave 2は、故障発生時のアーキテクチャの状態を見ている：
1、マスタノードマスターが故障し、クライアントの接続に失敗し、二つのノードからのコピーに失敗しました。
2、メインノードslaave 1を選択し、slaave of no oneコマンドを実行してメインノードにします。
3、アプリケーション接続を更新するノードはslaave 1のIPアドレスです。
4、slaave 2はslaave 1を新たなマスタノードとして、slaave 1上のコマンドをコピーする。
5、元のマスターが回復したら、slaave 1のスレーブノードにします。
上記のプロセスは自動化のプロセスを行うことができますが、3つの点を考慮する必要があります。
b、複数のスレーブノードがある場合、一つだけノードからマスタノードに昇進することを保証することが重要な問題である。
c、クライアントの新しいマスタノードのメカニズムが十分にロバストであるかどうかを通知する。
02 Redis Sentinelの高利用メカニズム
Sentinelは自動的に故障の発見と故障の転移を完成し、適時にアプリケーションに通知することができます。これはその核心的価値です。
Redis Sentinelは、いくつかのSentinelといくつかのRedisデータノードを含む分散アーキテクチャであり、各Sentinelノードは、データノードと残りのSentinelノードを監視し、ノードが到達しないことが発見されると、ノードを下線で表している。主ノードとしてマークされている場合、他のsentinelとも協議します。ほとんどのsentinelノードが主ノードに到達できないと考えている場合、彼らはsentinelノードを選出して故障自動転送を実現します。同時にこの変化をRedisアプリケーションに通知します。プロセス全体は自動的で、人工介入を必要としません。
Redis SentinelとRedis主従レプリカモードはいくつかのsentinelノードだけが多く、redisノードに対して特別な処理をしていません。これは多くのレディ開発と運営者が紛らわしいところです。
二つのアーキテクチャ図は以下の通りである。
主サービス全体の故障から主サービスの再選択までの過程で、sentinelは主に以下のようなことをする。
1、監視、sentinelノードは定期的にredisデータノードを検出し、残りのsentinelノードが到達するかどうか
2、通知して、sentinelノードは故障の転移の結果をアプリケーションに通知します。
3、メインノードの故障転送：ノードからメインノードに昇進し、後続の正しい主従関係を維持することを実現する。
4、構成プロバイダ：redis sentinel構造では、クライアントは初期化時にsentinelノードのセットに接続し、そこからマスタノード情報を取得する。
上のアーキテクチャ図では、sentinelも複数であることが分かりやすく、このような利点は2つあります。
1、sentinelのたくましさを保証し、一つのsentinelが掛かっており、クラスタ全体の機能に影響を与えない。
2、ノードの故障についての判断は複数のsentinelと同時に判断され、誤審を防止する効果がある。
sentinelノード自体は独立したredisノードですが、データを保存しないで、一部のコマンドだけをサポートします。
次に、sentinelの配置と配置ファイルの内容を見てみます。
03 sentinel展開
sentinelが展開される前に、まずmasterと二つのslaaveの主な二つの構造が必要です。
残りの二つのsentinelの配置ファイルはこれと大同小異です。対応ポートとログファイルを修正すればいいです。sentinel起動コマンドは以下の通りです。
コマンドinfo sentinelを使って現在のsentinelクラスタの情報を調べます。
Redisマスターモードでは、一旦メインノードが故障のためにサービスを提供できなくなると、人工的にノードからマスタノードにアップグレードする必要があることを知っています。その後、多くのアプリケーションシーンにおいて、このような障害処理の方法は受け入れられない。アプリケーションは、現在の利用可能なノードをリアルタイムで感知する必要がある。この問題を解決するために、Redis Sentinelが生まれました。「哨兵」とも言います。
sentinelを紹介する前に、いくつかのredisの概念を理解します。
メインノードマスタ：Redisプロセス、メインサービス
ノードslaave:redisプロセスからサービス
Redisデータノード：マスタノードとスレーブノード
Sentinelノード：Redisデータノードを監視し、独立したsentinelプロセス
Sentinelノードの集合：いくつかのSentinelノードの抽象的な組み合わせ、いくつかのsentinelノードプロセス
Redis Sentinel：Redis高利用可能な実施形態、sentinelノードセットとredisデータノードプロセス
01マスタコピー問題
前の文章では、主従レプリカについて述べましたが、ノードから主ノードのトラブルシューティングノードとして利用できます。
1、一度メインノードが故障したら、ノードからメインノードに昇進するプロセスとアプリケーションは、新しいマスターノードを調整するプロセスを調整するために、すべて人為的な干渉が必要である。
2、メインノードの書き込み能力はシングルマシンの制限を受けやすいです。
3、メインノードの記憶能力はシングルマシンの制限を受けやすい。
一般的な方法の一つは、シナリオを使用してノードからの役割の切り替えをトリガすることであり、例えば、1つのマスタ2のスレーブ構造において、マスタノードmasterを仮定して、ノードslaave 1から、slaave 2は、故障発生時のアーキテクチャの状態を見ている：
1、マスタノードマスターが故障し、クライアントの接続に失敗し、二つのノードからのコピーに失敗しました。
2、メインノードslaave 1を選択し、slaave of no oneコマンドを実行してメインノードにします。
3、アプリケーション接続を更新するノードはslaave 1のIPアドレスです。
4、slaave 2はslaave 1を新たなマスタノードとして、slaave 1上のコマンドをコピーする。
5、元のマスターが回復したら、slaave 1のスレーブノードにします。
上記のプロセスは自動化のプロセスを行うことができますが、3つの点を考慮する必要があります。
b、複数のスレーブノードがある場合、一つだけノードからマスタノードに昇進することを保証することが重要な問題である。
c、クライアントの新しいマスタノードのメカニズムが十分にロバストであるかどうかを通知する。
02 Redis Sentinelの高利用メカニズム
Sentinelは自動的に故障の発見と故障の転移を完成し、適時にアプリケーションに通知することができます。これはその核心的価値です。
Redis Sentinelは、いくつかのSentinelといくつかのRedisデータノードを含む分散アーキテクチャであり、各Sentinelノードは、データノードと残りのSentinelノードを監視し、ノードが到達しないことが発見されると、ノードを下線で表している。主ノードとしてマークされている場合、他のsentinelとも協議します。ほとんどのsentinelノードが主ノードに到達できないと考えている場合、彼らはsentinelノードを選出して故障自動転送を実現します。同時にこの変化をRedisアプリケーションに通知します。プロセス全体は自動的で、人工介入を必要としません。
Redis SentinelとRedis主従レプリカモードはいくつかのsentinelノードだけが多く、redisノードに対して特別な処理をしていません。これは多くのレディ開発と運営者が紛らわしいところです。
二つのアーキテクチャ図は以下の通りである。
主サービス全体の故障から主サービスの再選択までの過程で、sentinelは主に以下のようなことをする。
1、監視、sentinelノードは定期的にredisデータノードを検出し、残りのsentinelノードが到達するかどうか
2、通知して、sentinelノードは故障の転移の結果をアプリケーションに通知します。
3、メインノードの故障転送：ノードからメインノードに昇進し、後続の正しい主従関係を維持することを実現する。
4、構成プロバイダ：redis sentinel構造では、クライアントは初期化時にsentinelノードのセットに接続し、そこからマスタノード情報を取得する。
上のアーキテクチャ図では、sentinelも複数であることが分かりやすく、このような利点は2つあります。
1、sentinelのたくましさを保証し、一つのsentinelが掛かっており、クラスタ全体の機能に影響を与えない。
2、ノードの故障についての判断は複数のsentinelと同時に判断され、誤審を防止する効果がある。
sentinelノード自体は独立したredisノードですが、データを保存しないで、一部のコマンドだけをサポートします。
次に、sentinelの配置と配置ファイルの内容を見てみます。
03 sentinel展開
sentinelが展開される前に、まずmasterと二つのslaaveの主な二つの構造が必要です。
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=169,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=169,lag=1
master_repl_offset:183
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:182
[root@VM_48_10_centos redis]# cat redis-sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
dir "/usr/local/redis-3.0.7"
sentinel monitor mymaster 127.0.0.1 6379 2残りの二つのsentinelの配置ファイルはこれと大同小異です。対応ポートとログファイルを修正すればいいです。sentinel起動コマンドは以下の通りです。
[root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26379.conf &
[1] 7311
[root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26380.conf &
[1] 7366
[root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26381.conf &
[2] 7380
[root@VM_48_10_centos redis]#
[root@VM_48_10_centos redis]# ps -ef|grep sentinel
root 7312 1 0 22:51 ? 00:00:00 redis-sentinel *:26379 [sentinel]
root 7367 1 0 22:52 ? 00:00:00 redis-sentinel *:26380 [sentinel]
root 7381 1 0 22:52 ? 00:00:00 redis-sentinel *:26381 [sentinel]
root 7405 5850 0 22:52 pts/7 00:00:00 grep --color=auto sentinel
[root@VM_48_10_centos redis]# cat redis-sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
dir "/usr/local/redis-3.0.7"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
sentinel known-slave mymaster 127.0.0.1 6380
# Generated by CONFIG REWRITE
sentinel known-slave mymaster 127.0.0.1 6381
sentinel known-sentinel mymaster 127.0.0.1 26381 0a2c77616ef88282fa12ef7c8aca142a2473cd5a
sentinel known-sentinel mymaster 127.0.0.1 26380 3ad6460bf5f4b01f277fdce3aa423d596993eec5
sentinel current-epoch 0コマンドinfo sentinelを使って現在のsentinelクラスタの情報を調べます。
[root@VM_48_10_centos redis]# redis-cli -h 127.0.0.1 -p 26379 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3