NoSQLデータベースのケースコンバット--Redisの高可用性ソリューション--Redis +センチネル

Redis高可用性ソリューション--Redis +センチネル

序文

この環境は、Redis学習環境を構築するためのCentos 7.8システムに基づいています。
具体的な構築については、Redis-5.0.9環境の展開を参照してください

Redisマスタースレーブ同期はデータの冗長性の問題を解決しますが、複数のRedisノードでは、マスターノードがダウンすると、Redisサーバーのコレクションが麻痺します。この問題は、Redisの高可用性ソリューションを通じて解決する必要があります。
次に、Redisの高可用性ソリューションであるRedisSentinelに焦点を当てます。


Redis高可用性ソリューション

  • マスタースレーブレプリケーション(レプリケーション-センチネルモード)
  • Redisクラスター(Redis-クラスターモード)

1.歩哨とは

歩哨とは

Sentinel(英語名Sentinel)は、マスタースレーブ構造内の各サーバーを監視するために使用される分散システムです。マスターノードに障害が発生すると、投票メカニズムによって新しいマスターノードが選択され、すべてのスレーブノードが接続されます。マスターノード。

Sentinel sentinelは、redisによって公式に提供される高可用性ソリューションであり、複数のRedisサービスインスタンスの実行ステータスを監視するために使用できます。
Redis Sentinelは、特別なモードで実行されているRedisサーバーです。Redis Sentinelは、複数のSentinelプロセスの環境で協調して動作します。

歩哨の役割

  • 監視:歩哨は、マスターとスレーブが正しく機能しているかどうかを常にチェックします。
  • 通知:監視対象のRedisに問題がある場合、センチネルはAPIを介して管理者または他のアプリケーションに通知を送信できます。
  • 自動フェイルオーバー:マスターが正常に機能しない場合、センチネルは自動フェイルオーバー操作を開始します。これにより、障害が発生したマスターのスレーブの1つが新しいマスターにアップグレードされ、障害が発生したマスターの他のスレーブが代わりに新しいマスターをコピーします。 ;クライアントがフェイルオーバーしたマスターに接続しようとすると、クラスターは新しいマスターのアドレスもクライアントに返すため、クラスターはフェイルオーバーしたマスターの代わりにマスターを使用できます。

センチインアーキテクチャ

ここに画像の説明を挿入
複数の歩哨監視マスター監視マスターに
ここに画像の説明を挿入
加えて、歩哨はお互いを監視します
ここに画像の説明を挿入

第二に、歩哨の構成

センチネル構成

歩哨は、redisインスタンスの監視として、選択アルゴリズムを通じて歩哨の堅牢性と高可用性を保証します。したがって、歩哨は、半数の原則に準拠する少なくとも3ユニットを展開する必要があります。5または7、半分以上、生きているときの半分は含まない。リーダーが選出されたときのみ、主従切り替え機能を実行できる。
センチネルの正常な動作を保証するには、少なくとも1つのredisサービスが存続する必要があります。新しいマスターを選択する原則は、利用可能な最新のデータ、最高の優先度、最長のアクティブです。

歩哨システムを構築する過程で注意すべきいくつかのポイントがあります

  • センチネルシステムのマスタースレーブノードは、通常のマスタースレーブノードと同じです。障害の検出と転送は、センチネルによって制御および完了されます。
  • センチネルノードは本質的にredisノードです。
  • センチネルノードごとに、他のセンチネルノードとスレーブノードを自動的に検出するように監視マスターノードを構成するだけで済みます。
  • センチネルノードの起動およびフェイルオーバーフェーズ中に、各ノードの構成ファイルが書き換えられます(config rewrite)。
  • センチネルは1つのマスターノードのみを監視できます。実際、センチネルは複数のマスターノードを監視できます。これは、複数のセンチネルモニターを構成することで実現できます。

環境への備え

すべてのノードのマスタースレーブ同期が構成され、有効になっています

役割 ノード ip Redisバージョン
主人 reids-yum 192.168.5.11 Redis-5.0.9
slave1 reids_source_code 192.168.5.12 Redis-5.0.9
slave2 redis-server 192.168.5.13 Redis-5.0.9

reids_source_codeは、システムサービススクリプトを提供します

[root@reids_source_code ~]# vim /usr/lib/systemd/system/redis-sentinel.service
[Unit]
Description=Redis Sentinel
After=network.target

[Service]
ExecStart=/usr/local/redis/bin/redis-sentinel /etc/redis/sentinel.conf --supervised systemd
ExecStop=/usr/bin/kill `pidof redis-sentinel`
Type=notify
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target

3つのノードがSentine構成ファイルを提供します

[root@reids-yum ~]# vim /etc/sentinel.conf
[root@reids_source_code redis]# vim /etc/redis/sentinel.conf
[root@redis-server ~]# vim /etc/sentinel.conf 
#是否为守护进程
daemonize yes
pidfile "/var/run/redis/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"
bind 192.168.5.13
port 26379
#工作目录
dir "/var/lib/redis"
#声明该哨兵的主库是mymaster,主库的ip和端口分别为127.0.0.1和6379
#最后一个2的含义是,在哨兵发生领导选举时,该哨兵需要获得2票才能成为leader
sentinel myid c0fc53842608bba5e5807226ce96d7c412bd069b
#在mymaster宕机30秒后进行主观下线
sentinel deny-scripts-reconfig yes
#指定在发生failover故障转移时最多可以有1个slave同时对新的master进行同步
sentinel monitor mymaster 192.168.5.11 6379 2
#设置故障转移超时时间为180秒
#这个参数的意义比较复杂,详细可以参考官方的注释说明
sentinel config-epoch mymaster 0
#发现两个从节点
sentinel leader-epoch mymaster 0
sentinel known-replica mymaster 192.168.5.13 6379
#epoch实现类似版本号的功能
sentinel known-replica mymaster 192.168.5.12 6379
# Generated by CONFIG REWRITE
protected-mode no
sentinel current-epoch 0

歩哨を開始

[root@reids-yum ~]# systemctl start redis-sentinel
[root@reids_source_code ~]# systemctl start redis-sentinel
[root@redis-server ~]# systemctl start redis-sentinel

# 查看进程
[root@reids-yum ~]# netstat -lnutp | grep 6379
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      8236/redis-server 1 
tcp        0      0 192.168.5.11:6379       0.0.0.0:*               LISTEN      8236/redis-server 1 
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN      8077/redis-sentinel 
tcp6       0      0 :::26379                :::*                    LISTEN      8077/redis-sentinel 

[root@reids_source_code ~]# netstat -lnutp | grep 6379
tcp        0      0 192.168.5.12:26379      0.0.0.0:*               LISTEN      3800/redis-sentinel 
tcp        0      0 192.168.5.12:6379       0.0.0.0:*               LISTEN      3265/redis-server 1

[root@redis-server ~]# netstat -lnutp | grep 6379
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      12404/redis-server  
tcp        0      0 192.168.5.13:6379       0.0.0.0:*               LISTEN      12404/redis-server  
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN      12326/redis-sentine 
tcp6       0      0 :::26379                :::*                    LISTEN      12326/redis-sentine 

歩哨は正常に構成されました!

テスト
ビューノード情報

メイン
ここに画像の説明を挿入
スレーブ1
ここに画像の説明を挿入
スレーブ2
ここに画像の説明を挿入
メイン図書館Redisのサービスを停止

[root@reids-yum ~]# systemctl stop redis
[root@reids-yum ~]# netstat -lnutp | grep 6379
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN      9751/redis-sentinel 
tcp6       0      0 :::26379  

ノード情報の表示
slave1slave2
ここに画像の説明を挿入
RedisSentinel
ここに画像の説明を挿入
が正常に達成しました=マスタースレーブフェイルオーバー

おすすめ

転載: blog.csdn.net/XY0918ZWQ/article/details/113804107