ホームページ > データベース > Redis > Redis のセンチネル モードを分析し、構築と実行のプロセスについて説明します。

Redis のセンチネル モードを分析し、構築と実行のプロセスについて説明します。

青灯夜游
リリース: 2022-01-19 10:00:45
転載
3296 人が閲覧しました

この記事では、Redis のセンチネル モードを深く理解し、センチネル モードの構築手順、実行プロセス、センチネルの選出について紹介します。

Redis のセンチネル モードを分析し、構築と実行のプロセスについて説明します。

基本的な紹介

Sentinel は Redis の高可用性 (高可用性) ソリューションです:

  • センチネル クラスターは構成されています1 つ以上のセンチネル インスタンスの 1 つ以上のマスター サーバーと複数のスレーブ サーバーを監視できます。 [関連する推奨事項: Redis ビデオ チュートリアル ]

  • マスター サーバーがオフラインになった場合、センチネルはマスター サーバーの下のスレーブ サーバーをマスター サーバーにアップグレードし、提供を継続できます。 Redis の高可用性を確保するためのサービス。

  • イラスト

Redis のセンチネル モードを分析し、構築と実行のプロセスについて説明します。

センチネル モードの構築手順

1. Sentinel.conf ファイルをコピーします#

cp sentinel.conf sentinel‐26379.conf
cp sentinel.conf sentinel‐26380.conf
cp sentinel.conf sentinel‐26381.conf
ログイン後にコピー

#2. 関連する設定を変更します#

#哨兵sentinel实例运行的端口默认26379
port 26379

#将`daemonize`由`no`改为`yes`
daemonize yes

#哨兵sentinel监控的redis主节点的 ip port
#master-name可以自己命名的主节点名字只能由字母A-z、数字0-9、这三个字符".-_"组成。#quorum当这些quorum个数sentinel哨兵认为master主节点失联那么这时客观上认为主节点失联了
#sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor master 127.0.0.1 6379 2

#当在Redis实例中开启了requirepass foobared授权密码这样所有连接Redis实例的客户端都要提供密码
#设置哨兵sentinel连接主从的密码注意必须为主从设置一样的验证密码
#sentinel auth-pass <master-name> <password>

sentinel auth-pass master MySUPER--secret-0123passw0rd

#指定多少毫秒之后主节点没有应答哨兵sentinel此时哨兵主观上认为主节点下线默认30秒,改成3秒
#sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds master 3000

#这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步,这个数字越小,完成failover所需的时间就越长,但是如果这个数字越大,就意味着越多的slave因为replication而不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
#sentinel parallel-syncs <master-name> <numslaves>

sentinel parallel-syncs master 1

#故障转移的超时时间failover-timeout可以用在以下这些方面:
#1.同一个sentinel对同一个master两次failover之间的间隔时间。
#2.当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了#默认三分钟
#sentinel failover-timeout <master-name> <milliseconds>
sentinelf ailover-timeout master1 80000
ログイン後にコピー
docker run -it --name redis-sentinel2639  -v /Users/yujiale/docker/redis/conf/sentinel6379.conf:/etc/redis/sentinel.conf -v /Users/yujiale/docker/redis/data26379:/data --network localNetwork --ip 172.172.0.16 -d redis:6.2.6 redis-sentinel /etc/redis/sentinel.conf
ログイン後にコピー
3. Sentinel Sentinel インスタンスの開始

#redis-master と redis-slaver の開始

在redis-master目录下  ./redis-server redis.conf
在redis-slaver1目录下 ./redis-server redis.conf
在redis-slaver2目录下 ./redis-server redis.conf
ログイン後にコピー
#redis-sentinel の開始

在redis-sentinel1目录下 ./redis-sentinel sentinel.conf
在redis-sentinel2目录下 ./redis-sentinel sentinel.conf
在redis-sentinel3目录下 ./redis-sentinel sentinel.conf
ログイン後にコピー

4. 起動ステータスの確認

実行プロセス

Redis のセンチネル モードを分析し、構築と実行のプロセスについて説明します。

1. Sentinel の起動と初期化

Sentinel は、永続化を実行しない特別な Redis サーバーです。Sentinel インスタンスが開始されると、各 Sentinel はメイン サーバーへの 2 つのネットワーク接続を作成します

コマンド接続: メイン サーバーにコマンドを送信し、応答を受信するために使用されます。

  • サブスクリプション接続: メイン サーバーの --sentinel-: をサブスクライブするために使用されます。 hello Channel

Redis のセンチネル モードを分析し、構築と実行のプロセスについて説明します。

2. マスター情報の取得

Sentinel のデフォルトはすべて10秒 1回、監視対象のマスターサーバーにinfoコマンドを送信し、マスターサーバーとその配下のスレーブサーバーに関する情報を取得します。

Redis のセンチネル モードを分析し、構築と実行のプロセスについて説明します。

3. スレーブ スレーブ情報の取得

Sentinel が新しいスレーブ サーバーがマスター サーバー 同時に、Sentinel はスレーブ サーバーへのコマンド接続とサブスクリプション接続も確立します。

コマンド接続が確立された後も、Sentinel はデフォルトで 10 秒ごとに info コマンドをスレーブ サーバーに送信し、スレーブ サーバーの情報を記録します。

Redis のセンチネル モードを分析し、構築と実行のプロセスについて説明します。

Redis のセンチネル モードを分析し、構築と実行のプロセスについて説明します。#4. サブスクリプション方式でマスター サーバーとスレーブ サーバーにメッセージを送信します

デフォルトでは、Sentinel は、監視対象のすべてのマスター サーバーとスレーブ サーバーがサブスクライブしている --sentinel-:hello チャネルに 2 秒ごとにメッセージを送信します。メッセージには、Sentinel 自身の情報とマスター サーバーの情報が含まれます。 。

5. マスター サーバーとスレーブ サーバーからチャネル情報を受信する

Sentinel がマスター サーバーまたはスレーブ サーバーとのサブスクリプション接続を確立すると、 Sentinel は、サブスクリプション接続

subscribe—sentinel—:hello
ログイン後にコピー

Sentinel は相互にコマンド接続のみを作成し、サブスクリプション接続ではなく、サブスクリプション接続を介してサーバーに次のコマンドを送信します。これは、Sentinel がマスター サーバーまたはスレーブ サーバーにサブスクライブしているためです。新しい Sentinel の追加を検出でき、新しい Sentinel が参加すると、お互いを認識している Sentinel はコマンド接続を通じて通信できるようになります。

6. 主観的なオフライン ステータスの検出

Sentinel は、確立されたすべてのインスタンス (マスター サーバー、スレーブ サーバーなど) にメッセージを送信します。サーバーと他の Sentinel) は PING コマンド インスタンスを送信し、down-after-milliseconds ミリ秒以内に無効な応答を返します (PONG、-LOADING、-MASTERDOWN を除く)。インスタンスが応答しない場合 (タイムアウト)ミリ秒後のダウン ミリ秒以内に、Sentinel はインスタンスの主観的オフライン (SDown)

7 を考慮します。客観的なオフライン ステータスを確認します

いつSentinel は、同時にこのメイン サーバーを監視する他のすべての Sentinel にクエリ コマンドを送信します。ホストその他のセンチネルの返信

<down_state> <leader_runid> <leader_epoch>
ログイン後にコピー

判断它们是否也认为主服务器下线。如果达到Sentinel配置中的quorum数量的Sentinel实例都判断主服务器为主观下线,则该主服务器就会被判定为客观下线(ODown)。

8、选举Leader Sentinel

当一个主服务器被判定为客观下线后,监视这个主服务器的所有Sentinel会通过选举算法(raft),选出一个Leader Sentinel去执行failover(故障转移)操作。

哨兵选举

Raft

Raft协议是用来解决分布式系统一致性问题的协议。

Raft协议描述的节点共有三种状态:Leader, Follower, Candidate。

term:Raft协议将时间切分为一个个的Term(任期),可以认为是一种“逻辑时间”。

选举流程

Raft采用心跳机制触发Leader选举

  • 系统启动后,全部节点初始化为Follower,term为0。

  • 节点如果收到了RequestVote或者AppendEntries,就会保持自己的Follower身份

  • 节点如果一段时间内没收到AppendEntries消息,在该节点的超时时间内还没发现Leader,Follower就会转换成Candidate,自己开始竞选Leader。

    • 一旦转化为Candidate,该节点立即开始下面几件事情:

      • 增加自己的term。
      • 启动一个新的定时器。
      • 给自己投一票。
      • 向所有其他节点发送RequestVote,并等待其他节点的回复。
  • 如果在计时器超时前,节点收到多数节点的同意投票,就转换成Leader。同时向所有其他节点发送AppendEntries,告知自己成为了Leader。

  • 每个节点在一个term内只能投一票,采取先到先得的策略,Candidate前面说到已经投给了自己,Follower会投给第一个收到RequestVote的节点。

  • Raft协议的定时器采取随机超时时间,这是选举Leader的关键。

  • 在同一个term内,先转为Candidate的节点会先发起投票,从而获得多数票。

Sentinel的leader选举流程

  • 1、某Sentinel认定master客观下线后,该Sentinel会先看看自己有没有投过票,如果自己已经投过票给其他Sentinel了,在一定时间内自己就不会成为Leader。

  • 2、如果该Sentinel还没投过票,那么它就成为Candidate。

  • 3、Sentinel需要完成几件事情:

    • 更新故障转移状态为start
    • 当前epoch加1,相当于进入一个新term,在Sentinel中epoch就是Raft协议中的term。
    • 向其他节点发送is-master-down-by-addr命令请求投票。命令会带上自己的epoch。
    • 给自己投一票(leader、leader_epoch)
  • 4、当其它哨兵收到此命令时,可以同意或者拒绝它成为领导者;(通过判断epoch)

  • 5、Candidate会不断的统计自己的票数,直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum,这时它就成为了Leader。

  • 6、其他Sentinel等待Leader从slave选出master后,检测到新的master正常工作后,就会去掉客观下线的标识。

故障转移

当选举出Leader Sentinel后,Leader Sentinel会对下线的主服务器执行故障转移操作

  • 1.它会将失效Master的其中一个Slave升级为新的Master,并让失效Master的其他Slave改为复制新的Master;

  • 2.当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用现在的Master替换失效Master。

  • 3.Master和Slave服务器切换后,Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变,即,Master主服务器的redis.conf配置文件中会多一行replicaof的配置,sentinel.conf的监控目标会随之调换。

主服务器的选择

  • 1.过滤掉主观下线的节点
  • 2.选择slave-priority最高的节点,如果由则返回没有就继续选择
  • 3.选择出复制偏移量最大的系节点,因为复制偏移量越大则数据复制的越完整,如果由就返回了,没有就继续
  • 4.选择run_id最小的节点,因为run_id越小说明重启次数越少

更多编程相关知识,请访问:编程入门!!

以上がRedis のセンチネル モードを分析し、構築と実行のプロセスについて説明します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

関連ラベル:
ソース:juejin.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート