Redis高可用性クラスタ-歩哨モード構築構成チュートリアル【Windows環境】

15369 ワード

No cross,no crown . 風雨を経験しないで、どうして虹が見えますか。

Redis哨兵モードは、今流行していると言えば「哨兵ロボット」であり、「哨兵ロボット」に対応した配置を行った後、この「ロボット」は7*24時間仕事をすることができ、監視、注意、自動処理故障など、自動的に何かをすることができます.

Redis-sentinelの概要

Redis-sentinelはRedisの著者antirezであり、Redisクラスタは各大手企業によって使用されているため、各社は独自のクラスタ管理ツールを書く必要があり、antirezは数週間かけてRedis-sentinelを書いた.
RedisのSentinelシステムは、複数のRedisサーバ(instance)を管理するために使用され、RedisのSentinelはRedisに高い可用性を提供します.哨兵モードを使用して、人為的な介入を必要とせずに様々な障害に対応できるRedis配置を作成します.
システムは、次の3つのタスクを実行します.

モニタ(Monitoring):Centinelは、プライマリ・サーバとセカンダリ・サーバが正常に許可されているかどうかを継続的にチェックします.

アラート(Notification):監視されているRedisサーバに問題が発生した場合、CentinelはAPIを介して管理者または他のアプリケーションに通知を送信できます.

自動フェイルオーバ(Automatic failover):(1)プライマリ・サーバが正常に動作しない場合、Centinelは自動フェイルオーバ・オペレーションを開始します.これにより、フェイルオーバ・プライマリ・サーバの1つをサーバから新しいプライマリ・サーバにアップグレードし、フェイルオーバ・プライマリ・サーバの他のプライマリ・サーバから新しいプライマリ・サーバのコピーに変更します.(2)クライアントが失敗したプライマリサーバに接続しようとすると,クラスタは失効したサーバの代わりに新しいプライマリサーバを使用することができる新しいプライマリサーバのアドレスをカスタマーサービス側に返す.

sentinelの分布特性

Redis Centinelは分散型システムであり、1つのアーキテクチャで複数のCentinelプロセス(progress)を実行できます.これらのプロセスは、噂プロトコル(gossip protocols)を使用してプライマリ・サーバがオフラインであるかどうかに関する情報を受信し、投票プロトコル(agreement protocols)を使用して自動フェイルオーバを実行するかどうか、新しいプライマリ・サーバとしてどのサーバを選択するかを決定します.
単一のsentinelプロセスがredisクラスタを監視するのは信頼できません.sentinelプロセスがダウンすると(sentinel自体にも単一の問題があり、single-point-of-failure)クラスタシステム全体が予想通りに動作しません.sentinelクラスタをいくつかのメリットでクラスタ化する必要があります.

はいくつかのsentinelプロセスがダウンタイムし、redisクラスタのプライマリ・スタンバイ・スイッチングを行うことができます.

sentinelプロセスが1つしかない場合、このプロセスがエラーを実行したり、ネットワークが詰まったりすると、redisクラスタのプライマリ・スタンバイ・スイッチング(単一の問題)は実現されません.

複数のsentinelがある場合、redisのクライアントは、任意のsentinelに任意に接続して、redisクラスタに関する情報

を得ることができる.
丈夫な配置には少なくとも3人の哨兵の実例が必要だ.
3つの哨兵インスタンスは、お客様が独立した方法で障害を確認するコンピュータまたは仮想マシンに配置する必要があります.例えば、異なる物理マシンまたは異なる利用可能な領域の仮想マシン.【今回の説明は1つの機械で構築され、マルチレベルと同じ理屈です】

Redis-sentinel構築

環境

Windows10
Redis-x64-3.2.100


      ：
master：127.0.0.1:6379 【   master】

slave：127.0.0.1:6380  127.0.0.1:6381

sentinel：127.0.0.1:26379  127.0.0.1:26380  127.0.0.1:26381

インストールおよび基本構成

Redisクラスタのマスタースレーブ構成については、既に説明していますが、インストールと基本構成が入っていますので、ここでは説明しません.不明な場合は、Redisクラスタのマスタースレーブレプリケーション(マスタースレーブ)構築構成チュートリアル【Windows環境】を参照してください.

Sentinel構成はインストールと基本構成により、既に主従構成があり、対応フォルダRedis 6379~Redis 6381がある.各フォルダの下にsentinelという名前を追加します.confのファイル.構成内容は次のとおりです:

#    Redis6379    ，                 ，26380，  26381。

#  Sentinel       
port 26379  
#           
sentinel monitor mymaster 127.0.0.1 6379 2
# 3s mymaster   ，   mymaster   
sentinel down-after-milliseconds mymaster 3000
#  10  ,mysater      ，   failover  
sentinel failover-timeout mymaster 10000  
#        ，    1                  
sentinel parallel-syncs mymaster 1

プロファイルはmasterの情報を構成するだけで良いので、slaveの情報を構成する必要はありません.slaveは自動的に検出できるからです(masterノードにはslaveに関するメッセージがあります).
各行の構成の意味をより明確にするには、各オプションの意味を簡単に説明します.

sentinel monitor [master-group-name] [ip] [port] [quorum]

master-group-name:master名(カスタマイズ可能)

ip port:IPアドレスとポート番号

quorun:票数、Sentinelはmasterが到着できるかどうかを協議する必要があります.

最初の行の構成は、mymasterというプライマリ・サーバを監視するようにSentinelに指示します.このプライマリ・サーバのIPアドレスは127.0.0.1で、ポート番号は6379です.このプライマリ・サーバを失効と判断するには、少なくとも2つのSentinel同意が必要です(Sentinelの数が基準に達しない限り、自動障害移行は実行されません).票数は本稿ではredisクラスタに3つのsentinelの例があり,そのうちmasterが切れたが,ここで票数を2に設定し,2つのsentinelがmasterが切れたと思っていることを示し,やっと本物だと思われるようになった.

sentinel

down-after-millisecondsオプションは、Sentineがサーバが断線したと判断するミリ秒数を指定します.

サーバが所与のミリ秒数以内にSentinelが送信したPINGコマンドの返信を返さなかったり、エラーを返したりした場合、Sentinelはこのサーバを主観的なダウンライン(subjectively down、略称SDOWN)とマークします.ただし、1つのCentinelがサーバを主観的なダウンラインとしてマークすると、必ずしもサーバの自動障害移行を引き起こすわけではありません.十分な数のCentinelが1つのサーバを主観的なダウンラインとしてマークしている場合にのみ、サーバは客観的なダウンライン(ODOWNと略称)としてマークされ、自動障害移行が実行されます.サーバを客観的なダウンラインとしてマークするために必要なSentinelの数は、プライマリ・サーバの構成によって決まります.

parallel-syncsオプションは、フェイルオーバを実行するときに、サーバから新しいプライマリ・サーバを同時に同期できる最大数を指定します.この数が小さいほど、フェイルオーバを完了するのに要する時間が長くなります.

5.その他の構成新規Redis起動スクリプト:startRedisServer.bat

@echo off
redis-server.exe redis.windows.conf
@pause

新しいRedis-Entinel起動スクリプト:startRedisSentinel.bat

@echo off
redis-server.exe sentinel.conf --sentinel 
@pause

設定開始startredis 6379.cmd,その他同理!

@echo off
cd Redis6379
startRedisServer.bat

構成でstartredisSentine 26379を起動する.cmd,その他同理!

@echo off
cd Redis6379
startRedisSentinel.bat
at

図のように構成されています.

Sentinalインスタンス

を起動

哨兵起動命令redis-server.exe sentinel.conf --sentinel

ステップ1:startRedisをクリックします.cmd,Redisクラスタを起動する
ステップ2:startRedisSentineをクリックします.cmd、哨兵を起動した例
Sentinal起動ログを見て、```が歩哨ID(Sentinal ID)を生成し、メインサーバーとスレーブサーバーを自動的に識別します!

[114252] 03 Mar 13:32:57.896 # Sentinel ID is 89f521b40a803495472c0457b0396473c4bfb100
[114252] 03 Mar 13:32:57.896 # +monitor master mymaster 127.0.0.1 6379 quorum 2
[114252] 03 Mar 13:32:57.909 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:32:57.917 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

マスター・サーバ6379(Master)情報を表示するには、次の手順に従います.

F:
osql_learn\Redis-Sentinel\Redis6379>redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=54148,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=54148,lag=1
master_repl_offset:54414
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:54413
127.0.0.1:6379>

プライマリ・サーバ6380(Slave)情報を表示するには、次の手順に従います.

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:80531
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6380>

Redis-Entinel高可用性シーンのプレゼンテーション

シーン1:マスターマスターダウン

プライマリ・サーバのmasterがダウンタイムした場合、Sentinelは、Salveから新しいMasterとして選択(アルゴリズム)メカニズムを使用します.多分、SlaveがMasterとして当選すると、slaveofno oneにコマンドを送信して選択したこのslaveをキャンセルし、Masterにするのが原理です.ホイッスルは、サーバSlave構成から選択した新しいプライマリサーバMasterに送信され、リスニングリストに障害が発生したMasterサーバが削除されます.(1)6379マスタサーバをシャットダウンする

127.0.0.1:6379> shutdown
not connected>

(2)選挙の新しいmasterを観察する過程とfailoverを表示した過程を見ると,ログ情報全体が比較的完全である.最後に6381メインサーバーを選出しました!

[114252] 03 Mar 13:32:59.945 * +sentinel sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:33:00.018 * +sentinel sentinel 7fc21e38de0408ccaa06111e44638e2693794e08 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.223 # +sdown master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.300 # +odown master mymaster 127.0.0.1 6379 #quorum 2/2
[114252] 03 Mar 13:53:19.300 # +new-epoch 1
[114252] 03 Mar 13:53:19.300 # +try-failover master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.306 # +vote-for-leader 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.319 # 7fc21e38de0408ccaa06111e44638e2693794e08 voted for 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.369 # +elected-leader master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.370 # +failover-state-select-slave master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.530 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.327 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.328 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.398 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +failover-end master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
[114252] 03 Mar 13:53:21.447 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:21.449 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:23.193 # +sdown sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:24.451 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

(3)6381サーバ情報を表示し、ロールを主とし、サーバ6380から!

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=33358,lag=1
master_repl_offset:33505
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:33504
127.0.0.1:6381>

シーン2:前の障害の6379 master再起動

(1)6379サービスを開始すると,6379が6381のスレーブサーバとなることが分かった!

F:
osql_learn\Redis-Sentinel\Redis6379>redis-server.exe redis.windows.conf

[116640] 03 Mar 13:59:25.753 * The server is now ready to accept connections on port 6379
[116640] 03 Mar 13:59:48.315 * SLAVE OF 127.0.0.1:6381 enabled (user request from 'id=2 addr=127.0.0.1:61677 fd=7 name=sentinel-7fc21e38-cmd age=10 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec')
[116640] 03 Mar 13:59:48.326 # CONFIG REWRITE executed with success.
[116640] 03 Mar 13:59:48.826 * Connecting to MASTER 127.0.0.1:6381
[116640] 03 Mar 13:59:48.851 * MASTER  SLAVE sync started

(2)6381サーバの状態情報を表示する:元のmasterは自動的にslaveに切り替えられ、自動的にmasterに復元されない.

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=73183,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=73183,lag=0
master_repl_offset:73183
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:73182
127.0.0.1:6381>

シーン3：サーバSlaveからのダウンタイムと再起動

(1)6380サーバをシャットダウンする:

127.0.0.1:6380> shutdown
not connected>

(2)Sentinalログ:

[113488] 03 Mar 14:06:50.143 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381

(3)サーバ6381のステータス情報を表示する:

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=111361,lag=1
master_repl_offset:111361
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:111360
127.0.0.1:6381>

(4)サーバからの起動

Connecting to MASTER 127.0.0.1:6381

(5)サーバ6381のステータス情報を確認:6380が戻ってきた!

role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6379,state=online,offset=141232,lag=0
slave1:ip=127.0.0.1,port=6380,state=online,offset=141232,lag=1
master_repl_offset:141232
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:141231
127.0.0.1:6381>

Redis-sentinelに関する知識

主観下線と客観下線

Sentineごとに定期的に実行する必要があるタスク

Sentinelとサーバから自動的に検出されます....

RedisのSentinalドキュメントを参照できます

JedisクライアントがSentinalを使用する

;

import java.util.HashSet;
import java.util.Set;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPoolConfig;
import redis.clients.jedis.JedisSentinelPool;

public class RedisManagerUtil {

    private static JedisSentinelPool pool = null;
    //         JedisSentinelPool,            
    static {
        try {
            JedisPoolConfig config = new JedisPoolConfig();
            //     pool      jedis  ，  pool.getResource()   ；
            //      -1，      ；  pool     maxActive jedis  ，   pool    exhausted(  )。
            config.setMaxTotal(Integer.valueOf(1000));
            //     pool         idle(   ) jedis  。
            config.setMaxIdle(Integer.valueOf(20));
            //    borrow(  )  jedis   ，       ，        ，     JedisConnectionException；
            config.setMinEvictableIdleTimeMillis(Integer.valueOf(-1));
            //  borrow  jedis   ，      validate  ；   true，    jedis       ；
            config.setTestOnBorrow(Boolean.valueOf(true));

            // master              
            String master = "mymaster";
            //setinel      master      
            Set sentinels = new HashSet();
            sentinels.add("127.0.0.1:26379");
            sentinels.add("127.0.0.1:26380");
            sentinels.add("127.0.0.1:26381");

            pool = new JedisSentinelPool(master, sentinels, config);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    /**
     *   redis   
     * 
     * @return JedisPool
     */
    public static JedisSentinelPool getPool() {
        return pool;
    }

    /**
     *       
     * 
     * @param pool
     * @param redis
     */
    public static void returnResource(JedisSentinelPool pool, Jedis redis) {
        if (redis != null) {
            try {
                pool.returnResource(redis);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }

    /**
     *   redis       
     * @param args
     */
    public static void main(String[] args) {
        JedisSentinelPool pool = RedisPoolAPIManager.getPool();
        Jedis redis = pool.getResource();
        System.out.println("redis = " + redis);

        if(redis != null){
            returnResource(pool,redis);
        }
    }
}

まとめ

Redis-sentinelはRedisが公式に推奨する高可用性(HA)ソリューションであり、Redis-sentinel自体も独立して動作するプロセスであり、複数のmaster-slaveクラスタを監視し、masterのダウンタイムを発見した後、自動的に切り替えることができます.Sentinalは、任意の複数のプライマリ・サーバ(多重化)、およびプライマリ・サーバの下にあるスレーブ・サーバを監視し、監視されているプライマリ・サーバがダウンラインしたときに自動的にフェイルオーバ操作を実行します.
sentinelの単一の障害を防止するために、sentinelをクラスタ化し、複数のsentinelを作成することができます.
このブログで構成されているredis-Entinelを使用したい場合は、ここでRedis-Entinelをダウンロードできます.

参考博文

Redis学習ノート(四)Redis哨兵(sentinel)
Sentiel(哨兵)構築に基づいてRedis高可用性クラスタを実現

このシリーズの記事:

第一篇:Redisクラスター主従レプリケーション(一主両従)構築構成教程【Windows環境】
第二篇:Redis高可用性クラスター-歩哨モード構築配置教程【Windows環境】
第三篇:Redisクラスターモード-主従レプリケーション構築構成教程【Windows環境】
もしこのブログがあなたに役に立つと思ったら、下の好きなものを注文して、もっと多くの人に見せてください.ありがとうございます.
もしかっこいい(美しい)、英知(聡明)が、私と同じように簡単で善良なあなたがこのブログに問題があるのを見たら、私は謙虚にあなたが私を成長させた批判を受け入れて、読んでくれてありがとうと指摘してください.今日は楽しかったですね.
私のcsdnブログへようこそ、私たちは一緒に成長します!
何をするにしても、続けていくだけで違いが見えます!道で、卑屈ではありません!
ブログhttp://blog.csdn.net/u010648555

どのように次のSWRを使用します.jsアプリ

[react]scssに関するバージョンの問題