毎日ではRedisのマスター失敗した時に、私たちは通常の使用の接続スレーブ完全なサービスへの応用を可能にスレーブ読み取り専用モードを閉じながら、マスタースレーブモードで、我々は一般的な分離を達成するために、読み取りおよび書き込み、それだけで、効率は改善されません。Sentinelは、私たちが自動的に切り替えることができます。
Sentinelは、分散を実行するために、サービスのRedisサーバとは無関係です。ときセンチネルの展開はどんなRedisの構成を変更する必要はありません。Redisのクラスタ・マスタとスレーブ状態を検出するかどうか動作中センチネル缶、それはノード障害があると判定された場合、通知は、センチネルAPI自体または他のアプリケーションによって発行されてもよい、センチネルよう複数の投票、フェイルオーバー。マスターへの他のAスレーブサーバ。マスターを交換しません。クライアントへの最後センチネルサービスバック新しいアドレス。実行中のアプリケーション保護。
Sentinelは説明して働く
奴隷のRedis-Serverのを見つけるために、どのように
他のセンチネルリンパ節を見つける方法を
ノードに障害が発生したかを決定する方法
センチネルのインストールと設定
ここでは異なるポートを区別するために、あまりにも多くのサーバーに開いていない
マスターが192.168.1.1であるマスター・スレーブ・アーキテクチャマスター・スレーブレプリケーションを、構築するためのRedis Redisのサービスを、デモはありません、見て左に行くことはありません
設定センチネル
Redisのソースパッケージでのセンチネルテンプレート設定ファイルは、あなたはそれが直接テンプレートなしで書き込むことができます変更コピーすることができます
port 26379 ## 端口
daemonize yes ## 后台启动
dir /soft/redis/data ## 工作目录
logfile "/soft/redis/log/sentinel.log" ## 日志目录
sentinel monitor mymaster 192.168.1.1 6379 2 ## 监控master，当判断失效时，至少需要2个sentinel判定master失败才可以。
sentinel down-after-milliseconds mymaster 10000 ## Sentinel 判断master失效的时间，单位为毫秒。
sentinel parallel-syncs mymaster 1 # 故障转移后每次有多少个slave向slave发起复制请求。
sentinel failover-timeout mymaster 60000 #1、同一个Sentinel对同一个master两次tailover的间隔。
#########################我是分割线#########################
#以下配置是当所有Sentinel节点启动之后，自动写入的配置
//自动发现的两个slave节点
sentinel konwn-slave mymaster 192.168.1.2 6379
sentinel konwn-slave mymaster 192.168.1.3 6379
//自动发现的两个Sentinel节点
sentinel known-sentinel mymaster 192.168.1.2 26379 814149a8600fede18177b7cc0611a86eab61699c
sentinel known-sentinel mymaster 192.168.1.3 26379 9ec521108aacc04347b0b5aa36d32680f394dc4b
sentinel current-epoch 0 #当前配置信息版本，如果配置文件发生变化，版本信息也会变化。スタートセンチネル
## 第一种启动方式（推荐）
[root@Master ~]# /soft/redis/bin/redis-sentinel /soft/redis/conf/sentlnel.conf
## 第二种启动方式
[root@Master ~]# /soft/redis/bin/redis-server /soft/redis/conf/sentlnel.conf --sentinel3台のサーバプロファイルセンチネルを見るために起動するように設定された後、余分な情報は他のロールで見つかりました。
センチネルの作品を説明します
1）各センチネル・サーバは、一般的にマスターとスレーブを持つINFOコマンドを送信間隔ごとに10秒に一度の頻度が必要です。このタスクは、ノードを追加または削除するかどうか奴隷で見つけることができます。マスターがオフラインとしてマークされている場合は、2番目のコマンドを送信するように変更されます。
2）各Sentinelは既知のマスター、スレーブ、および他の実施例のSentinelに一度毎秒の周波数を送信するpingコマンド。場合はping、コマンドは、有効な応答を取得し、最後のオプション設定した応答時間があるため、それは主観的にオフラインとしてマークされますダウン後のミリ秒の値を超えることはできません
3）各センチネル周波数意志が2秒ごとに一度、パブリッシュ・サブスクライブ機能によって、それモニターはセンチネルサーバ情報から、すべてのマスターサーバーと送信helloパケットが他にセンチネルのIPアドレス、およびポート番号が含まれています実行ID（RUNID）
スレーブのRedis-サーバーを見つける方法
1.タスク1、伝送INFO解析によってコマンドINFO、コマンド、スレーブノード検出の戻り値を監視し、スレーブ。だからこそ、センチネル構成、ノードから理由もなくRedisの-Serverの設定情報です。
2.情報のトポロジINFOと、メインスイッチ、または削除ノードの増加からRedisのサーバートポロジが発生し表示するためのコマンド、センチネルの監視リストにリアルタイムで更新することができます。
どのように他のノードを見つけるために、センチネル
ハローチャンネル、（未知の歩哨を探して）見センチネル前に見られなかった。1.各センチネル3の使命は、すべてによってモニターし、センチネルサーバからのことをメインサーバに加入しています。センチネルは、それが新しいリストに追加し、ノードに接続を作成する新しいセンチネル、センチネルを見つけた場合は、リストはセンチネルが知られているが含まれ、他のすべてのセンチネルのプライマリサーバで監視。
2.Sentinel送信された情報は、さらに完全なマスターサーバーの現在の構成を備えています。古いに送信されたコンフィギュレーションセンチネルセンチネルが含まれているよりも、プライマリサーバ構成ならば、Sentinelは、すぐに設定を更新します。
3.Sentinelノード間のマスターノードのステータス情報交換は、客観組立ラインオフの背後にあるだけでなく、選挙のリーダーに基づいて行われます。
ノードに障害が発生したかを決定する方法
1.上記の作業を通じて、我々は新しいRedisの-Serverノードを発見することができます、また、最新の情報、およびセンチネルノード情報へのアクセスを得ることができます。
2.タイマータスク2、マスターとスレーブノードへのRedis-サーバーあたり。だけでなく、他のセンチネルノードが送信しpingたコマンドを。
3.によって各ノードの制御を達成するために、各ノードのハートビート（RedisのとSentinelは）、このタスクは、障害が発生したノードの重要な基礎を決定することです。
4.例センチネル-1がダウンした後、ミリ秒単位の時間がより有効回答を対応するノード以外ではない、センチネルノードの障害が決定され、オフラインとマークされていました。この動作は、主観的にオフラインと呼ばれています。
マスタは、マスタがセンチネルセンチネルを介して他のノードへのセンチネルリンパ節を要求決定マスタダウン・バイ・ADDRコマンドである場合にオフラインに主観的Redisの場合Sentinelは5ノード。投票のセット数よりも多くの（私たちの3つのノードは、2票、要約前の設定を忘れてしまっを設定する）場合は、ノードが目的オフラインの意思決定を行います。客観的な判断の後に組立ラインオフしたら誰もが知っているの背後に、我々は切り替えを開始します。