RedisSentinelの概要

Redis Sentinelは、Redisにシンプルで自動の高可用性（HA）ソリューションを提供します。 MongoDBの選挙の仕組みに精通している場合、これはそれほど遠くありません。まず、N個のスレーブに複製する特定のマスターがあります。そこから、Sentinelデーモンが実行されます。これは、アプリケーションサーバー上でも、Redisが実行されているサーバー上でも実行できます。これらはマスターの健康状態を追跡します。

Sentinelは、マスターが応答しないことを検出すると、SDOWN（主観的にダウン）メッセージを他のセンチネルにブロードキャストします。次に、マスターがダウンしているというクォーラムに達すると、マスターはODOWN（客観的にダウン）をブロードキャストし、新しいマスターが選出されます。 ODOWN状態に到達することに同意するには、定足数または過半数のセンチネルが必要なので、同点を避けるために奇数のセンチネルを実行することが常にベストプラクティスです。

注：Sentinelで最高のパフォーマンスを得るには、2.8ブランチ以降のバージョンのRedisを使用することを強くお勧めします。

仕組み

センチネルは、実行中のRedisインスタンスの構成ファイルを再書き込みすることでフェイルオーバーを処理します。シナリオを見てみましょう：

マスター「A」がスレーブ「B」と「C」に複製されているとします。アプリケーションサーバー上で実行されている3つのセンチネル（s1、s2、s3）があり、Redisに書き込みます。この時点で、現在のマスターである「A」がオフラインになります。私たちの番兵は全員、「A」をオフラインと見なし、SDOWNメッセージを相互に送信します。次に、「A」がダウンしていることに全員が同意するため、「A」はODOWNステータスに設定されます。ここから、誰が最も進んでいるかを確認するための選挙が行われ、この場合は「B」が新しいマスターとして選択されます。

「B」の設定ファイルは、誰のスレーブでもなくなるように設定されています。一方、「C」の設定ファイルは、「A」のスレーブではなく「B」になるように書き直されています。ここから、すべてが通常どおり続行されます。 「A」がオンラインに戻った場合、センチネルはこれを認識し、「B」が現在のマスターであるため、「A」の構成ファイルを「B」のスレーブになるように書き換えます。

構成

センチネルの設定は、思ったほど難しくはありません。実際、最も難しいことの1つは、Sentinelプロセスを配置する場所を選択することです。可能であれば、アプリサーバーで実行することを個人的にお勧めします。おそらく、これを設定している場合は、マスターへの書き込みの可用性について懸念しています。そのため、Sentinelは、アプリケーションサーバーがマスターと通信できるかどうかについての洞察を提供します。もちろん、RedisインスタンスサーバーでもSentinelsを実行できます。

構成手順を開始するには、ここにあるサンプルファイルを参照してください。これは、Ubuntu14.04のRedis2.8.4で見つかったsentinel.confの例ですが、Redisの2.8.xバージョンで動作するはずです。私は、実際に使用したい上部に2行を自由に追加しました：

daemonize yes
logfile /var/log/redis/redis-sentinel.log

これにより、センチネルプロセスがデーモン化モードになり、すべてのメッセージがstdoutではなくログファイルに記録されます。

ここには多くの構成可能なオプションがあり、ほとんどが非常によくコメントされています。ただし、この投稿では2つだけに焦点を当てます。

最も重要な部分は、現在のマスターがどこに住んでいるかをセンチネルに伝えることです。これは次の行で参照されています：

sentinel monitor mymaster 127.0.0.1 6379 2

これにより、Sentinelは、「mymaster」（これは任意の名前です。適切と思われる名前を付けてください）と特定のポートの特定のIP、およびフェイルオーバーのクォーラムを満たすために必要なSentinelの数を監視するように指示されます（最小値は2）です。ここで変更する可能性が高いのは、マスターのIPアドレスと、標準ポート6379で実行されていない場合はそのポートです。

次に、次の行を変更することをお勧めします：

sentinel down-after-milliseconds mymaster 30000

これは、センチネルがSDOWNでマスターを宣言する前に待機する時間です。デフォルトは30秒ですが、私は通常、これを10秒に少し下げたいと思います。これを低くしすぎないようにします。そうしないと、フェイルオーバーが頻繁に発生するという問題が発生する可能性があります。

他のオプションのいくつかを自由に見てください。多くのユーザーが関心を持つ可能性があるのは、フェイルオーバーが発生したときにそれを追跡したい場合の通知スクリプトです。

必要に応じてsentinel.confを構成したら、次のコマンドでデーモンを起動します。

redis-server /path/to/sentinel.conf --sentinel

フェイルオーバーのテスト

すべての番兵をオンラインにしたら、フェイルオーバーのドライランを実行して、すべてが正しく構成されていることを確認できます。

まず最初に。 redis-cliを介してSentinelに接続します：

redis-cli -p 26379

歩哨に関する情報を受け取りたい場合は、次のコマンドを実行するだけです。

127.0.0.1:26379> INFO

これにより、現在のマスターが誰であるか、スレーブの数、監視している歩哨の数などの情報が得られます。

フェイルオーバーをテストするには、次を実行するだけです。

127.0.0.1:26379> SENTINEL failover mymaster

これにより、現在のマスターでODOWNが強制され、フェイルオーバーが発生します。その後すぐに「INFO」コマンドを再度実行すると、新しいマスターが一覧表示されます。

結論

うまくいけば、これがRedisとSentinelの謎を解くのに役立つでしょう。ご不明な点がございましたら、以下に投稿してください。