Redis/sentinel/cluster

15343 ワード

sentinel:前編では主従切替について述べましたが、sentinelの役割はこのプロセスを自動化し、高可用性を実現することです.主な機能は次のとおりです.

は、redisが予想通りに良好に動作するかどうかを時々監視する.

redisノードの実行状況が発見された場合、別のプロセス(例えばクライアント)に通知することができる.

は自動切替が可能である.1つのmasterノードが使用できない場合、masterの複数のslave(1つ以上のslaveがある場合)のうちの1つを新しいmasterとして選択することができ、他のslaveノードは、それに追随するmasterのアドレスをmasterのslaveに昇格された新しいアドレスに変更する.

Sentinel自体もクラスタをサポートしており、redisクラスタを監視するために単一のsentinelプロセスのみを使用するのは信頼できません.sentinelプロセスがダウンすると、sentinel自体にも単一の問題があります.sentinelクラスタをいくつかのメリットでクラスタ化する必要があります.

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

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

sentinelクラスタ自体も多数のメカニズム、すなわち2つのsentinelプロセスが必要である場合、1つのもう1つを削除すると使用できません.

デフォルトでは、CentinelはTCPポート26379を使用します(通常のRedisサーバは6379を使用します).CentinelはRedisプロトコル形式のコマンド要求を受け入れるので、redis-cliまたは他のRedisクライアントを使用してCentinelと通信することができます.

# redis-cli -p 26379
127.0.0.1:26379> ping
PONG

sentinelの起動:プロファイル:

port 26329
sentinel monitor myredis 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel notification-script

第1行portはsentinelポートを指定します.

第2行モニタ構成は、myredisというプライマリredisインスタンスを監視するためにSentineに指示する.Centinelのプロファイルでは、このプライマリ・インスタンスが属するセカンダリ・インスタンスを説明する必要はありません.なぜなら、Centinelインスタンスは、プライマリ・インスタンスに問い合わせることで、すべてのセカンダリ・インスタンスの情報を得ることができるからです.行末2は、この主インスタンスを失効と判断するには少なくとも2つのSentineプロセスの同意が必要であり、Sentineの数が基準に達しない限り、自動failoverは実行されないことを示す.

down-after-millisecondsオプションは、Redisインスタンスが無効になったと判断するSentinalに必要なミリ秒数を指定します.インスタンスがこの時間を超えてPINGを返さなかったり、エラーを直接返したりした場合、Centinelはこのインスタンスを主観的なダウンライン(subjectively down、略称SDOWN)とマークします.

failover-timeoutは、この時間(ms)内にfailover操作が完了しなかった場合、failoverが失敗したと判断したことを示す.

parallel-syncs新しいプライマリ・インスタンスをすべてインスタンスから同期すると、Redisインスタンスから短時間ですべて使用できなくなる可能性があります.この値を1に設定することで、毎回1つのslaveだけがコマンドリクエストを処理できない状態にあることを保証できます.

notification-scriptモニタのredisインスタンスが指すインスタンス異常をsentinelが検出した場合に呼び出されるアラームスクリプトを指定します.この構成項目はオプションです.

Sentinelの起動:Sentinelは特殊モードで実行されるRedisインスタンスにすぎません.通常のRedisインスタンスを起動するときに、-sentinelオプションを指定してRedis Sentinelインスタンスを起動できます.例えば:redis-server /path/to/sentinel.conf --sentinelはもちろんRedisが持参したredis-sentinelを実行することもできます.例えば:redis-sentinel /path/to/sentinel.confSentinalクラスタ:1.他のクラスタとは異なり、他のCentinelのアドレスを設定する必要はありません.Centinelプロセスは、同じプライマリ・インスタンスを監視している他のCentinelをパブリッシュおよびサブスクリプションすることで自動的に発見できます.Sentineが新しいSentineを発見すると、新しいSentineがリストに追加されます.このリストには、同じプライマリ・サーバの他のすべてのSentineが監視されていることが知られています.2.Sentinelクラスタ内のSentinelは、同じ時点でfailoverと同じマスターを同時に行うことはありません.最初にfailoverを行うSentinelが失敗した場合(上記のfailover-timeout)、もう1つはfailoverを再実行します.3.Sentineがslaveをマスターに選択してSLAVE OF NO ONEを送信すると、他のslaveが新しいマスターに対して自分を再構成していなくても、failoverは成功したと考えられます.4.上記のオーバーフロー中に、この時点でold masterを再起動すると、redisクラスタはmasterがない状態になり、この時点でプロファイルを手動で変更してクラスタを再起動するしかない.5.Master-Slaveを切り替えると、Sentineはmaster、slave、sentinelのconfプロファイルを書き換えます.6.Sentineが1つのmasterに対してfailoverを正常に実行すると、masterに関する最新の構成がブロードキャスト形式で他のsentinelに通知され、他のSentineは対応するmasterの構成を更新する.
例:redisを起動するには:

/etc/redis/redis-m.conf
daemonize yes
pidfile /var/run/redis/redis-server-m.pid
port 6379
loglevel notice
logfile /var/log/redis/redis-server-m.log
databases 16
##disable snapshot
save ""
dir /app/redis-m
appendonly yes
appendfilename "appendonly.aof"
##not to be a slave
#slaveof no one

/etc/redis/redis-s1.conf
daemonize yes
pidfile /var/run/redis/redis-server-s1.pid
port 6380
loglevel warning
logfile /var/log/redis/redis-server-s1.log
databases 16
##disable snapshot
save ""
dir /app/redis-s1
appendonly yes
appendfilename "appendonly.aof"
##to be a slave
slaveof 127.0.0.1 6379

/etc/redis/redis-s2.conf
daemonize yes
pidfile /var/run/redis/redis-server-s2.pid
port 6381
loglevel warning
logfile /var/log/redis/redis-server-s2.log
databases 16
##disable snapshot,enable AOF
save ""
dir /app/redis-s2
appendonly yes
appendfilename "appendonly.aof"
##to be a slave
slaveof 127.0.0.1 6379

プロセスインスタンスを表示するには、次の手順に従います.

ps -ef | grep redis
root     17560     1  0 09:48 ?        00:00:00 redis-server *:6379                 
root     17572     1  0 09:48 ?        00:00:00 redis-server *:6380                  
root     17609     1  0 09:49 ?        00:00:00 redis-server *:6381

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

sentinelの起動:

sentinel1.conf
port 26379
sentinel monitor myredis 127.0.0.1 6379 2
sentinel down-after-milliseconds myredis 60000
sentinel failover-timeout myredis 180000
sentinel parallel-syncs myredis 1
sentinel notification-script myredis /etc/redis/log-issues.sh

sentinel2.conf
port 26380
sentinel monitor myredis 127.0.0.1 6379 2
sentinel down-after-milliseconds myredis 60000
sentinel failover-timeout myredis 180000
sentinel parallel-syncs myredis 1
sentinel notification-script myredis /etc/redis/log-issues.sh

log-issues.sh
#!/bin/bash
echo "master failovered at `date`" > /root/redis_issues.log

-------  --------
nohup redis-sentinel /etc/redis/sentinel1.conf
nohup redis-sentinel /etc/redis/sentinel2.conf

接続:

127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "myredis"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) "a88ffd6548e333f3ac895cf1b890ef32a527dd66"
......
   37) "parallel-syncs"
   38) "1"
   39) "notification-script"
   40) "/etc/redis/log-issues.sh"
127.0.0.1:26379> sentinel slaves myredis
1)  1) "name"
    2) "127.0.0.1:6381"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6381"
......
2)  1) "name"
    2) "127.0.0.1:6380"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6380"

sentinel reset:すべての名前と指定されたモードpatternが一致するプライマリ・サーバをリセットします.patternパラメータはGlobスタイルのモードです.リセット操作はsentinelの保存したすべての状態情報を消去し、再発見プロセスを行う.

127.0.0.1:26379> sentinel reset myredis
(integer) 1

sentinel failover:アクティブなfailoverを1回行います.すなわち,他のSentinelの意見を聞かずに,自動フェイルオーバを強制的に開始する.フェイルオーバを開始したSentinelは、他のSentinelに新しい構成を送信し、他のSentinelはこの構成に従って更新します.

127.0.0.1:26379> sentinel failover myredis
OK

masterはlocalhost:6381に切り替えました.

127.0.0.1:26379> sentinel get-master-addr-by-name myredis
1) "127.0.0.1"
2) "6381"
## redis-cli 
redis-cli
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up

クライアント:sentinelのfailoverプロセスはクライアントに対して透過的であり、Java Jedisを例に挙げます.

public class RedisSentinelClient {

    /**
     * @param args
     */
    public static void main(String[] args) {
        Set sentinels = new HashSet();
        sentinels.add(new HostAndPort("172.30.37.73", 26379).toString());
        sentinels.add(new HostAndPort("172.30.37.73", 26380).toString());
        sentinels.add(new HostAndPort("172.30.37.73", 26381).toString());
        JedisSentinelPool sentinelPool = new JedisSentinelPool("myredis", sentinels);
        System.out.println("Current master: " + sentinelPool.getCurrentHostMaster().toString());
        
        Jedis master = sentinelPool.getResource();
        master.set("username","tom");
        sentinelPool.returnResource(master);
        
        Jedis master2 = sentinelPool.getResource();
        String value = master2.get("username");
        System.out.println("username: " + value);
        master2.close();
        sentinelPool.destroy();
    }

}

cluster: 1.1つのRedisクラスタは、16384個のハッシュスロット(hash slot)を含み、データベース内の各キーは、この16384個のハッシュスロットのうちの1つに属し、クラスタ内の各ノードは、ハッシュスロットの一部の処理を担当する.例えば、1つのクラスタには3つのノードがあり、ノードAは0〜5500番のハッシュスロットの処理を担当する.ノードBは、5501〜11000番のハッシュスロットの処理を担当する.ノードCは11001番から16384番までのハッシュスロットの処理を担当する.このようなハッシュスロットを異なるノードに分散することにより、ユーザはクラスタにノードを容易に追加または削除することができる.たとえば、ユーザが新しいノードDをクラスタに追加する場合、クラスタは、ノードA、B、CのいくつかのスロットをノードDに移動するだけでよい.ユーザがクラスタからノードAを除去する場合、クラスタは、ノードA内のすべてのハッシュスロットをノードBおよびノードCに移動してから、空白(ハッシュスロットを含まない)のノードAを除去するだけでよい.2.Redisクラスタはノードに対して主従レプリケーション機能を使用している:クラスタ内の各ノードには1個からN個のレプリケーション(replica)があり、そのうちの1個のレプリケーションは主ノード(master)であり、残りのN-1個のレプリケーションは従ノード(slave)である.3.Redisクラスタのノード間でGossipプロトコルを介して通信する.
コマンド:

//  (cluster)  
CLUSTER INFO          
CLUSTER NODES              （node），           。   
//  (node)  
CLUSTER MEET     ip   port              ，          。  
CLUSTER FORGET         node_id      。  
CLUSTER REPLICATE           node_id          。  
CLUSTER SAVECONFIG                。   
// (slot)  
CLUSTER ADDSLOTS  [slot ...]        （slot）  （assign）     。  
CLUSTER DELSLOTS  [slot ...]                 。  
CLUSTER FLUSHSLOTS              ，                   。  
CLUSTER SETSLOT  NODE     slot     node_id      ，             ，             >，       。  
CLUSTER SETSLOT  MIGRATING         slot     node_id       。  
CLUSTER SETSLOT  IMPORTING    node_id           slot     。  
CLUSTER SETSLOT  STABLE      slot    （import）    （migrate）。   
//  (key)  
CLUSTER KEYSLOT      key           。  
CLUSTER COUNTKEYSINSLOT      slot           。  
CLUSTER GETKEYSINSLOT      count   slot     。

クラスタの起動:Redis Clusterデータ冗長性が1の場合、少なくとも3つのMasterと3つのSlaveが必要です.

192.168.XXX.XXX:7000
192.168.XXX.XXX:7001
192.168.XXX.XXX:7002
192.168.XXX.XXX:7003
192.168.XXX.XXX:7004
192.168.XXX.XXX:7005

プロファイル:

bind 192.168.XXX.XXX //     192.168.XXX.XXX localhost，             ”Connection refused”   。
port 7000
daemonize yes //    
cluster-enabled yes //  Cluster
cluster-require-full-coverage no //   yes，         16384       ，           ，  no。
cluster-config-file nodes_7000.conf //      ,              ，  Redis          ，              。
cluster-node-timeout 5000 //           。
appendonly yes
logfile ./redis_7000.log

各ノードの起動:redis-server redis_700X.confはrubyベースのクラスタツールをインストールします.

yum install ruby rubygems -y
wget https://rubygems.org/downloads/redis-3.2.1.gem
gem install -l redis-3.2.1.gem
cp redis-3.2.1/src/redis-trib.rb /usr/local/bin/redis-trib //         /usr/local/bin

クラスタの作成:

redis-trib create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

--replicas 1は、クラスタ内の各プライマリノードにスレーブノードを作成することを意味します.以上のコマンドは、redis-tribプログラムに3つのプライマリノードと3つのスレーブノードを含むクラスタを作成させることを意味します.
テスト:

$ redis-cli -c -p 7000  
redis 127.0.0.1:7000> set foo bar  
-> Redirected to slot [12182] located at 127.0.0.1:7002  
OK  
redis 127.0.0.1:7002> set hello world  
-> Redirected to slot [866] located at 127.0.0.1:7000  
OK  
redis 127.0.0.1:7000> get foo  
-> Redirected to slot [12182] located at 127.0.0.1:7002  
"bar"  
redis 127.0.0.1:7000> get hello  
-> Redirected to slot [866] located at 127.0.0.1:7000  
"world"

値は対応するノードのHashスロットに配置され、redis−cliは700 Xノードの前にジャンプをリダイレクトし続けた.起動時に-cオプションを付けないと、エラー形式で表示されたMOVEDリダイレクトメッセージが表示されます.
再スライス:再スライスは、基本的には、一部のノードから別の一部のノードにハッシュスロットを移動し、クラスタを作成するようにredis-tribツールを使用して完了します.
新しいノードの追加:2つの新しいインスタンス70107011が同じ方法で開始されました.そのうち7010が主で、7011が従である.

//     
redis-trib.rb add-node 192.168.1.100:7010 192.168.1.100:7000
//      ，7010     
redis-cli -c -h 192.168.1.100 -p 7000 cluster nodes
...
...
0d1f9c979684e0bffc8230c7bb6c7c0d37d8a5a9 192.168.1.100:7010 master - 0 1442452249525 0 connected
...
...
//     
redis-trib.rb add-node --slave --master-id 0d1f9c979684e0bffc8230c7bb6c7c0d37d8a5a9 192.168.1.100:7011 192.168.1.100:7000

移行Slot:

# redis-trib.rb reshard 192.168.1.100:7000 //         
How many slots do you want to move (from 1 to 16384)? 1000 //  slot 1000  
What is the receiving node ID? 03ccad2ba5dd1e062464bc7590400441fafb63f2 //   node id  
Please enter all the source node IDs.  
 Type 'all' to use all the nodes as source nodes for the hash slots.  
 Type 'done' once you entered all the source nodes IDs.  
Source node #1:all //            
Do you want to proceed with the proposed reshard plan (yes/no)? yes //

ノードの削除:プライマリノードが削除されている場合、彼女はslotを持っています.割り当てられたslotを削除してから、プライマリノードを削除する必要があります.

# redis-trib.rb reshard 192.168.10.219:6378 //     slot,         
How many slots do you want to move (from 1 to 16384)? 1000 //   master   slot    
What is the receiving node ID? 5d8ef5a7fbd72ac586bef04fa6de8a88c0671052 //  6378  slot master  
Please enter all the source node IDs.  
 Type 'all' to use all the nodes as source nodes for the hash slots.  
 Type 'done' once you entered all the source nodes IDs.  
Source node #1:03ccad2ba5dd1e062464bc7590400441fafb63f2 //   master node-id  
Source node #2:done     
Do you want to proceed with the proposed reshard plan (yes/no)? yes //  slot ，reshard  
//         slot
# redis-trib.rb del-node 192.168.10.219:6378 '03ccad2ba5dd1e062464bc7590400441fafb63f2'

Jedisクライアント:

Set jedisClusterNodes = new HashSet();
//Jedis Cluster will attempt to discover cluster nodes automatically
jedisClusterNodes.add(new HostAndPort("127.0.0.1", 7379));
JedisCluster jc = new JedisCluster(jedisClusterNodes);
jc.set("foo", "bar");
String value = jc.get("foo");

要点:Centinelは自動failoverのソリューションです.Clusterはスライス方式で、failoverを持参し、Clusterを使用するときにSentineを使用する必要はありません.Sentinel: 1.Sentinalの役割は主従切替を自動化することである.2.Centinel自体もクラスタをサポートし、Centinelクラスタでredisクラスタを監視する.3.Centinelクラスタ自体にも多数のメカニズムが必要である.(単一の問題を避けるには、少なくとも3つが必要)4.Sentinalは、特殊モードで実行されるRedisインスタンスにすぎません.

     –sentinel       Redis Sentinel   。 ：
redis-server /path/to/sentinel.conf --sentinel
       Redis   redis-sentinel， ：
redis-sentinel /path/to/sentinel.conf

デフォルトでは、CentinelはTCPポート26379を使用する.redis−cliを使用して、redis−cli−p 26379と通信することができる.4.Sentinelプロセスは、同じプライマリ・インスタンスを監視している他のSentinelをパブリッシュおよびサブスクリプションすることによって自動的に発見することができ、同じプライマリ・インスタンスを監視するだけで、他のSentinelのアドレスを設定する必要はありません.

#    conf 
sentinel monitor myredis 127.0.0.1 6379 2

5.Sentinalのfailoverプロセスはコードクライアントに対して透過的である.
参照先:http://blog.csdn.net/dc_726/article/details/48552531 http://blog.51yip.com/nosql/1726.html http://carlosfu.iteye.com/blog/2243483

オブジェクト向け

アストロレシピ収集ウェブサイト-パート3カテゴリーフィルタページ