Redis Sentinel、Sentinel の構築プロセス、Sentinel の運用プロセス、選出原理 (主観的オフライン、客観的オフライン、Sentinel リーダーの選出方法) について詳しく説明します。

Redis Sentinel (センチネル)

センチネルとは何ですか?

内部告発者は、バックグラウンドのマスター ホストに障害がないかどうかをパトロールして監視します。障害がある場合は、続行するための 投票の数に基づいて、スレーブ データベースを新しいマスター データベースに自動的に変換します。外部サービス。 [関連する推奨事項: Redis ビデオ チュートリアル ]

は、一般に無人操作とメンテナンスとして知られています。 ＃＃＃＃＃＃何をするか？

• メッセージ通知: Sentinel はフェイルオーバー結果をクライアントに送信できます
• フェイルオーバー: スレーブの 1 つを新しいマスターとして使用します
• 構成センター: クライアントはセンチネルに接続することで現在の Redis サービスのマスター ノード アドレスを取得します
• Case

アーキテクチャ

: クラスターを自動的に監視および保守します。これはデータを保存せず、単なる内部告発です。

: データの読み取りと保存に使用されます

ステップ

redis インストール パスの Sentinel.conf を myredis ディレクトリにコピーします

• cp sentinel.conf /myredis/sentinel26379.conf

  ログイン後にコピー

設定ファイルを変更します

• vim sentinel26379.conf
      
  bind 0.0.0.0
      
  # protected-mode yes 修改为 protected-mode no
  protected-mode no
  
  # daemonize no 修改为 daemonize yes
  daemonize yes
  
  # port 
  port 26379
  
  # pid文件名字，pidfile
  pidfile /var/run/redis_26379.pid
      
  # log文件名字，logfile（修改 logfile "" 为 logfile "/myredis/26379.log"）
  logfile "/myredis/26379.log"
  
  # 指定当前的工作目录（修改 dir /temp 为 dir /myredis）
  dir /myredis

  ログイン後にコピー
  マスター サーバーを監視対象に設定します

  クォーラム: オフラインで目的を確認する監視員の最小数。フェイルオーバーを承認するための投票の定足数。

  # sentinel monitor <master-name> <ip> <redis-port> <quorum>

  ログイン後にコピー
  マスター サービスに接続するためのパスワードを設定します

  # sentinel auth-pass <master-name> <password>

  ログイン後にコピー
  ネットワークが信頼できないことはわかっています。監視員は、ネットワークが信頼性の高いものであると誤って考えることがあります。ネットワークの輻輳により、新しいものを作成しました。マスター redis が停止しています。センチネル クラスター環境では、複数のセンチネルが相互に通信して、マスターが本当に停止しているかどうかを確認する必要があります。クォーラム パラメーターは、目的のオフラインの基礎です。つまり、少なくとも次のことを意味しますクォーラム監視員はこう考えます。マスターに障害が発生すると、マスターはオフラインになり、フェイルオーバーされます。場合によっては、センチネル ノードが独自のネットワーク上の理由でマスターに接続できないことがありますが、現時点ではマスターに障害はありません。したがって、複数のセンチネルは、次の手順に進む前にマスターに問題があることに同意する必要があります。次のステップの操作により、公平性と高可用性が保証されます。

3 つの Linux をインストールします

IP とポートは

# sentinel00
192.168.157.112    26379
# sentinel01
192.168.157.113    26380
# sentinel02
192.168.157.118    26381

3 つの Sentinel を構成します

sentinelxxxx.conf ファイル

sentinel00

sentinel26379.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

sentinel01

sentinel26380.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

sentinel02

sentinel26381.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

Test

前の Redis レプリケーションに基づいて、1 つのマスターと 2 つのスレーブを開始してマスター/スレーブ レプリケーションが正常かどうかをテストし、情報レプリケーションを入力して正常かどうかを確認します。通常
3 つの監視を開始し、監視を完了します

• redis-sentinel /myredis/sentinel26379.conf --sentinel
  redis-sentinel /myredis/sentinel26380.conf --sentinel
  redis-sentinel /myredis/sentinel26381.conf --sentinel

  ログイン後にコピー

マスター/スレーブ レプリケーションをテストします。すべて問題ありません
ログの表示

> 后面为自动新增内容

-

# 模拟宕机
shudown

ログイン後にコピー

• 問題

  スレーブ機2台のデータは正常ですか？ (はい)

  残りの 2 台のマシンから新しいマスターが選択されますか? (はい)
  再起動後、以前のマスターが再び引き継がれ、再びマスターになりますか? (いいえ)
  salveデータの取得

設定ファイルを比較します。

ファイルの内容は、動作中に Sentinel によって動的に変更されます。主従関係が切り替わると、設定ファイルの内容が自動的に変更されます。

#sentinel6379.conf ファイル

• 新master

哨兵运行流程和选举原理

当一个主从配置中的master失效后，sentinel可以选举出一个新的master用于自动替换原master的工作，主从配置中的其他redis服务自动指向新的master同步数据，一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。

SDown主观下线(Subjectively Down)

SDOWN（主观不可用）是单个哨兵自己主观检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就到达了SDOQN的条件。

sentinel配置文件中的 down-after-milliseconds 设置了主观下线的时间长度（默认30秒）。

# sentinel down-after-milliseconds <masterName> <timeout>
sentinel down-after-milliseconds mymaster 30000

ODown客观下线(Objectively Down)

ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能确认一个master客观上已经宕机了。

# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

选举出领导者哨兵

当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点，并由该领导者哨兵节点进行failover（故障迁移）

领导者哨兵如何选出来的？

Raft算法

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得，即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。

选新的master（im）

整个过程由sentinel自己独立完成，无需人工干涉。

新主登基

某一个slave被选中成为master

选出新的master的规则，剩余slave节点健康的前提下

1. redis.conf文件中，优先级slave-priority或者replica-priority最高节点（数字越小优先级越高）
2. 复制偏移量offset最大的从节点。
3. 最小Run ID的从节点。

群臣俯首

• 执行 slaveof no one 命令让选出来的从节点成为新的主节点，并通过 slaveof 命令让其他节点成为其从节点。

• sentinel leader 会对选举出来的新 master 执行 slaveof no one，将其提升为master节点

• sentinel leader 向其他slave发送命令，让剩余的slave成为新的master节点的slave。

旧主拜服

• 将之前的已经下线的旧master设置为新选出的新master的从节点，当旧master重新上线后，它会成为新master的从节点
• sentinel leader 会让原来的master降级为slave并恢复正常工作。

哨兵使用建议

• 哨兵节点数量应该为多个，哨兵本身应该为集群，保证高可用
• 哨兵节点数量应该是奇数
• 各个哨兵节点的配置应该一致
• 如果哨兵节点部署在docker等容器里面，尤其要注意端口的正确映射
• 哨兵集群 + 主从复制，并不能保证数据零丢失

更多编程相关知识，请访问：编程视频！！

以上がRedis のセンチネルを詳しく理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。