Redis マスター/スレーブ レプリケーション、セントリー モード、クラスター モード

1. マスター/スレーブ レプリケーション

1. マスター/スレーブ レプリケーション - センチネル クラスター

マスター/スレーブ レプリケーション: マスター/スレーブ レプリケーションは高可用性 Redis の基礎であり、Sentinel と Cluster はどちらもマスター/スレーブ レプリケーションに基づいて高可用性を実現します。マスター/スレーブ レプリケーションでは、主にデータのマルチマシン バックアップのほか、読み取り操作の負荷分散と単純な障害回復が実装されます。欠点: 障害回復を自動化できない、書き込み操作の負荷分散ができない、ストレージ容量が 1 台のマシンによって制限される

Sentinel: Sentinel は、マスター/スレーブ レプリケーションに基づいて、自動障害回復を実装します。欠点: 書き込み操作は負荷分散できない; ストレージ容量は 1 台のマシンによって制限される; Sentinel はスレーブ ノードの自動フェイルオーバーを実行できない 読み書き分離シナリオでは、スレーブ ノードの障害により読み取りサービスが利用できなくなり、追加の監視が必要になりますスレーブノードの切り替え動作が必要です。

クラスター: Redis はクラスター化を通じて、書き込み操作の負荷分散ができず、ストレージ容量が 1 台のマシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。

2. マスタースレーブレプリケーションの概念

• マスター/スレーブ レプリケーションとは、1 つの Redis サーバーから他の Redis サーバーにデータをコピーすることを指します。前者はマスター ノード (Master)、後者はスレーブ ノード (Slave) と呼ばれ、データの複製は一方向であり、マスター ノードからスレーブ ノードへのみ可能です。

• デフォルトでは、各 Redis サーバーはマスター ノードであり、マスター ノードは複数のスレーブ ノードを持つことができます (またはスレーブ ノードを持たない) が、スレーブ ノードはマスター ノードを 1 つだけ持つことができます。

3. マスター/スレーブ レプリケーションの役割

① データ冗長化マスタスレーブレプリケーションは、永続化以外のデータ冗長化方式であるデータのホットバックアップを実現します。

② 障害復旧 マスターノードで障害が発生した場合、スレーブノードがサービスを提供して迅速な障害復旧を実現しますが、これは一種のサービスの冗長化です。

③ 負荷分散はマスターとスレーブのレプリケーションに基づいており、読み取りと書き込みの分離と組み合わせることで、マスター ノードは書き込みサービスを提供し、スレーブ ノードは読み取りサービスを提供できます (つまり、Redis データを書き込むとき、アプリケーションはマスター ノードに接続し、 Redis データを読み取るとき、アプリケーションはスレーブ ノードに接続します)、サーバーの負荷を共有するために、特に書き込みが少なく読み取りが多いシナリオでは、複数のスレーブ ノードで読み取り負荷を共有すると、Redis サーバーの同時実行性が大幅に向上します。 。

④ 高可用性の基礎 上記の機能に加え、センチネルやクラスタの実装の基盤となるマスター・スレーブ・レプリケーションが Redis の高可用性の基盤となります。

4. マスター/スレーブ レプリケーション プロセス

① スレーブマシンのプロセスが開始されると、マスターマシンに「同期コマンド」コマンドを送信して同期接続を要求します。

② 初回接続でも再接続でも、マスターマシンはバックグラウンドプロセスを開始し、データスナップショットをデータファイルに保存(RDB操作を実行)すると同時に、データを変更するためのコマンドもすべて記録し、それらをデータ ファイルにキャッシュします。

③ バックグラウンドプロセスによるキャッシュ処理が完了すると、マスターマシンはデータファイルをスレーブマシンに送信し、スレーブマシンはデータファイルをハードディスクに保存し、メモリにロードし、マスターマシンはすべての処理を完了します。データを変更する操作がスレーブ マシンに送信されます。スレーブに障害が発生してダウンタイムが発生した場合、正常に戻った後に自動的に再接続されます。

④ マスターマシンはスレーブマシンからの接続を受信した後、その完全なデータファイルをスレーブマシンに送信します。マスターが複数のスレーブから同時に同期要求を受信した場合、マスターマシンはバックグラウンドでプロセスを開始し、データファイルを保存します。データ ファイルを作成し、それをすべてのスレーブ マシンに送信して、すべてのスレーブ マシンが正常であることを確認します。

5. Redis マスター/スレーブ レプリケーションの手順を展開する

5.1 環境の準備

マスターノード: 192.168.2.66 Redis

スレーブ 1 ノード: 192.168.2.22 Redis

スレーブ 2 ノード: 192.168.2.200 Redis

5.2 まず Redis を構築し、ファイアウォールをオフにします

yum install -y gcc gcc-c++ make
#将redis-5.0.7.tar.gz的压缩包上传到/opt中
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
cd /opt/redis-5.0.7/utils
./install_server.sh
......
Please select the redis executable path [/usr/loca1/bin/redis-server]  /usr/local/redis/bin/redis-server
 
ln -s /usr/local/redis/bin/* /usr/local/bin/

  

systemctl stop firewalld
systemctl disable firewalld
setenforce 0

5.3 Redis設定ファイルの変更(マスターノードの操作)

vim /etc/redis/6379.conf
bind 0.0.0.0                       #70行,注释掉bind项,或修改为0.0.0.0,默认监听所有网卡
daemonize yes                      #137行,开启守护进程
logfile /var/log/redis_6379.log            #172行,指定日志文件目录
dir /var/lib/redis/6379                    #264行,指定工作目录
appendonly yes                     #700行,开启AOF持久化功能
 
/etc/init.d/redis_6379 restart

5.4 Redis設定ファイルの変更(スレーブノード操作)

vim /etc/redis/6379.conf
bind 0.0.0.0                         #70行,修改监听地址为0.0.0.0
daemonize yes                        #137行,开启守护进程
logfile /var/log/redis_6379.log                  #172行,指定日志文件目录
dir /var/lib/redis/6379                          #264行,指定工作目录
replicaof 192.168.2.66 6379                    #287行,取消注释并指定要同步的Master节点IP和端口
appendonly yes                       #700行,开启AOF持久化功能
 
/etc/init.d/redis_6379 restart

5.5 マスタースレーブ効果を検証する

在Master节点上看日志:
tail -f /var/log/redis_6379.log
 
在Master节点上验证从节点:
redis-cli
127.0.0.1:6379> info replication

6. 操作例: Redis マスター/スレーブ レプリケーションのデプロイ

6.1 まず Redis を構築し、ファイアウォールをオフにします

6.2 Redis設定ファイルの変更(マスターノードの操作)

6.3 Redis設定ファイルの変更(スレーブノード操作)

2 つのスレーブ ノードの構成は同じです


 

6.4 マスタースレーブ効果の検証

ログの検証 (マスター ノードのログを表示します:):

マスター ノード上のスレーブ ノードを確認します。

スレーブ ノードのキーをチェックして、データが同期されているかどうかを確認します。

2.セントリーモード

Sentinel のコア機能: Sentinel は、マスター/スレーブ レプリケーションに基づいて、マスター ノードの自動フェイルオーバーを導入します。

1.セントリーモードの原理

Sentinel は、マスター/スレーブ構造の各サーバーを監視するために使用される分散システムです。障害が発生した場合、投票メカニズムを通じて新しいマスターが選択され、すべてのスレーブが新しい​​マスターに接続されるため、Sentinel 全体が実行されます。 3 ノード以上にする必要があります

2.セントリーモードの役割

• 監視: Sentinel はマスター ノードとスレーブ ノードが適切に機能しているかどうかを常にチェックします。

• 自動フェイルオーバー: マスター ノードが正常に動作しない場合、Sentinel は自動フェイルオーバー操作を開始し、障害が発生したマスター ノードのスレーブ ノードの 1 つを新しいマスター ノードにアップグレードし、他のスレーブ ノードが新しいマスター ノードを複製するように変更します。マスターノード。

• 通知 (リマインダー): Sentinel はフェイルオーバーの結果をクライアントに送信できます。

3. センチネル構造は、センチネル ノードとデータ ノードの 2 つの部分で構成されます。

• Sentinel ノード: Sentinel システムは 1 つ以上の Sentinel ノードで構成され、Sentinel ノードはデータを保存しない特別な Redis ノードです。

• データノード: マスターノードとスレーブノードの両方がデータノードです。

Sentinel の起動はマスター/スレーブ モードに依存するため、Sentinel モードを開始する前にマスター/スレーブ モードをインストールする必要があります。Sentinel モードはすべてのノードにデプロイする必要があります。Sentinel モードは、すべての Redis 動作ノードが正常であるかどうかを監視しますマスターが現れた場合 他のノードがマスターノードと連絡が取れなくなったため、問題が発生した場合に投票を行い、半数以上の票が投じられた場合、確かにマスターに問題があるとみなします。その後、監視室に通知が届き、スレーブの 1 人が新しいマスターとして選択されます。

客観的オフラインはマスター ノードにのみ存在する概念であることに注意することが重要です。スレーブ ノードとセンチネル ノードに障害が発生し、センチネルによって主観的にオフラインになった場合、その後の客観的オフラインおよびフェイルオーバー操作は行われません。

4. センチネルモードの展開手順

4.1 環境の準備

マスターノード: 192.168.229.66 Redis

スレーブ 1 ノード: 192.168.229.22 Redis

スレーブ 2 ノード: 192.168.229.200 Redis

4.2 Redisセンチネルモードの設定ファイルの変更(全ノード操作)

vim /opt/redis-5.0.7/sentinel.conf
protected-mode no                                              #17行,关闭保护模式
port 26379                                                     #21行,Redis哨兵默认的监听端口
daemonize yes                                                  #26行,指定sentinel为后台启动
logfile "/var/log/sentinel.log"                                #36行,指定日志存放路径
dir "/var/lib/redis/6379"                                      #65行,指定数据库存放路径
sentinel monitor mymaster 192.168.2.66 6379 2                #84行, 修改
指定该哨兵节点监控192.168.2.66:6379这个主节点,该主节点的名称是mymaster,最后的2的含义与主节点的故障判定有关:至少需要2个哨兵节点同意,才能判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 30000                #113行,判定服务器down掉的时间周期,默认30000毫秒(30秒)
sentinel failover-timeout mymaster 180000                      #146行,故障节点的最大超时时间为180000 (180秒 )

4.3 セントリーモードの開始

注意:先启master,再启slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &

4.4 センチネル情報の表示

redis-cli -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.200.10:6379,slaves=2,sentinels=3

4.5 故障シミュレーション

#查看redis-server进程号(在Master 上进行):
ps -ef | grep redis
5 S root      57521      1  0  80   0 - 39869 ep_pol 15:31 ?        00:00:02 /usr/local/redis/bin/redis-server 0.0.0.0:6379
5 S root      57951      1  0  80   0 - 38461 ep_pol 16:00 ?        00:00:01 redis-sentinel *:26379 [sentinel]
0 R root      58035  15559  0  80   0 - 28169 -      16:08 pts/2    00:00:00 grep --color=auto redis
 
#杀死 Master 节点上redis-server的进程号
kill -9 57521      #Master节点上redis-server的进程号
 
#验证结果,查看master是转换至从服务器
tail -f /var/log/sentinel.log
 
#在Slave1上查看是否转换成功
redis-cli -p 26379 INFO Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.200.20:6379,slaves=2,sentinels=3

5. 運用例:センチネルモードの導入

5.1 Redisセンチネルモードの設定ファイルの変更(全ノード操作)


 

5.2 セントリーモードの開始

5.3 センチネル情報の表示

4.5 故障シミュレーション

redis の pid を取得し、マスター ノード上の redis-server のプロセス番号を強制終了します。

結果を確認し、マスターがスレーブサービスに変換されたかどうかを確認します

Slave1 で変換が成功したかどうかを確認します

3. クラスターモード

• クラスター、つまり Redis クラスターは、R​​edis 3.0 以降に導入された分散ストレージ ソリューションです。

• クラスターは複数のノード (Node) で構成され、Redis データはこれらのノードに分散されます。クラスター内のノードはマスター ノードとスレーブ ノードに分割されます。マスター ノードのみが読み取りおよび書き込みリクエストとクラスター情報の保守を担当し、スレーブ ノードはマスター ノードのデータとステータス情報のみを複製します。

• クラスタ内のノードはマスター ノードとスレーブ ノードに分割されます。

マスター ノードは、読み取りおよび書き込みリクエストとクラスター情報のメンテナンスを担当します。

スレーブ ノードはマスター ノードのデータとステータス情報のみを複製します。

1. クラスターの役割は次の 2 点に要約できます。

① データパーティショニング:データパーティショニング(またはデータシャーディング)はクラスタの中核機能です

クラスターはデータを複数のノードに分散します。一方で、Redis 単一マシンのメモリー サイズ制限を突破し、ストレージ容量を大幅に増加します。他方、各マスター ノードは外部の読み取りサービスと書き込みサービスを提供できるため、クラスターの応答性が向上します。

Redis スタンドアロン メモリ サイズの制限の問題は、永続性とマスター/スレーブ レプリケーションの導入時に言及されています。たとえば、スタンドアロン メモリが大きすぎる場合、bgsave と bgrewriteaof のフォーク操作によりメイン プロセスがブロックされる可能性があります。これにより、マスター/スレーブ環境でホストの切り替えが発生する可能性があり、その結果、スレーブ ノードが長時間サービスを提供できなくなり、完全なレプリケーション フェーズ中にマスター ノードのレプリケーション バッファーがオーバーフローする可能性があります。

② 高可用性: クラスターはマスター/スレーブ レプリケーションとマスター ノードの自動フェイルオーバー (Sentinel と同様) をサポートしており、いずれかのノードに障害が発生しても、クラスターは引き続き外部にサービスを提供できます。

2. Redisクラスターのデータシャーディング

Redis クラスターではハッシュ スロットの概念が導入されています

• Redis クラスターには 16384 個のハッシュ スロット (0 ~ 16383 の番号が付けられます) があります。

• クラスター内の各ノードは、ハッシュ スロットの一部を担当します。

• 各キーは CRC16 チェックに合格し、16384 の残りを使用して、どのハッシュ スロットに配置するかを決定します。この値を使用して、対応するスロットに対応するノードを見つけ、アクセスするために対応するノードに自動的にジャンプします。

3. 3 つのノードで構成されるクラスターを例に挙げます

ノード A にはハッシュ スロット 0 ~ 5460 が含まれます

ノード B にはハッシュ スロット 5461 ~ 10922 が含まれます

ノード C にはハッシュ スロット 10923 ~ 16383 が含まれます

4. Redis クラスターのマスター/スレーブ レプリケーション モデル

クラスターには 3 つのノード A、B、C があります。ノード B に障害が発生すると、5461 ~ 10922 の範囲のスロットが不足するため、クラスター全体が使用できなくなります。

各ノードにスレーブ ノード A1、B1、C1 を追加すると、クラスター全体が 3 つのマスター ノードと 3 つのスレーブ ノードで構成されます。ノード B に障害が発生した後、クラスターはサービスを継続するマスター ノードとして B1 を選択します。B と B1 の両方に障害が発生すると、クラスターは使用できなくなります

5. Redis クラスターのデプロイ手順

5.1 環境の準備

Redis クラスターには通常、6 つのノード、3 つのマスター、3 つのスレーブが必要です。

便宜上、ここでのすべてのノードは同じサーバー上でシミュレートされます: ポート番号によって区別されます: 3 つのマスター ノードのポート番号: 6001/6002/6003、対応するスレーブ ノードのポート番号: 6004/6005/6006  

5.2 ディレクトリを作成し、設定ファイルを対応するノードにコピーします。

cd /etc/redis/
mkdir -p redis-cluster/redis600{1..6}
 
for i in {1. .6}
do
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
done

5.3 本体設定ファイルの変更とクラスタ機能の設定

他の 5 つのフォルダーの構成ファイルも同様に変更されますが、6 つのポートはすべて異なることに注意してください。  

cd /etc/redis/redis-cluster/redis6001
vim redis.conf
#bind 127.0.0.1         #69行,注释掉bind项,默认监听所有网卡
protected-mode no       #88行,修改,关闭保护模式
port 6001               #92行,修改,redis监听端口
daemonize yes           #136行,开启守护进程,以独立进程启动
appendonly yes          #699行,修改,开启AOF持久化
cluster-enabled yes     #832行,取消注释,开启群集功能
cluster-config-file nodes-6001.conf    #840行,取消注释,群集名称文件设置
cluster-node-timeout 15000             #846行,取消注释群集超时时间设置
 
#可以写一个for循环将6001的文件复制给6002~6006,这样就不需要全部一个一个文件进行修改了
for i in {2..6}
do
/usr/bin/cp -f /etc/redis/redis-cluster/redis6001/redis.conf /etc/redis/redis-cluster/redis600$i/redis.conf
done
#之后稍微修改文件即可

5.4 Redisノードの起動

方法一:<br>分别进入那六个文件夹,执行命令: redis-server redis.conf,来启动redis节点
cd /etc/redis/redis-cluster/redis6001
redis-server redis.conf
<br>方法二:使用for循环
for d in {1..6}
do
cd /etc/redis/redis-cluster/redis600$d
redis-server redis.conf
done
 
ps -ef | grep redis

5.5 クラスタの起動

redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
 
#六个实例分为三组,每组一主一从,前面的做主节点,后面的做从节点。下面交互的时候需要输入yes 才可以创建。
-replicas 1       #表示每个主节点有1个从节点。

5.6 テストクラスター

redis-cli -p 6001 -c              #加-c参数,节点之间就可以互相跳转
127.0.0.1:6001> cluster slots     #查看节点的哈希槽编号范围
1) 1) (integer) 5461
   2) (integer) 10922      #哈希槽编号范围
   3) 1) "127.0.0.1" .
      2) (integer) 6003       #主节点IP和端口号
      3) " fdca661922216dd69a 63a7c9d3c4540cd6baef44"
   4) 1) "127.0.0.1"
      2) (integer) 6004       #从节点IP和端口号
      3) "a2c0c32aff0f38980accd2b63d6d952812e44740"
2) 1) (integer) 0
   2) (integer) 5460
   3) 1) "127.0.0.1"
      2) (integer) 6001
      3) "0e5873747a2e2 6bdc935bc76c2ba fb19d0a54b11"
   4) 1) "127.0.0.1"
      2) (integer) 6006
      3) "8842ef5584a85005e135fd0ee59e5a0d67b0cf8e"
3) 1) (integer) 10923
   2) (integer) 16383
   3) 1) "127.0.0.1"
      2) (integer) 6002
      3) "81 6ddaa3d14 69540b2f fbcaaf9aa867646846b30"
   4) 1) "127.0.0.1"
      2) (integer) 6005
      3) "f847077bfe6722466e96178ae8cbb09dc8b4d5eb"
 
127.0.0.1:6001> set name zhangsan
-> Redirected to slot [5798] located at 127.0.0.1: 6003
OK
 
127.0.0.1:6001> cluster keyslot name    #查看name键的槽编号
(integer) 5798

注:これはテスト用のマシンです。  

6. インスタンスの操作: Redis クラスターのデプロイメント

6.1 ディレクトリを作成し、設定ファイルを対応するノードにコピーする

6.2 本体設定ファイルの変更とクラスタ機能の設定

 

6001 から 6002 ~ 6006 のファイルをコピーする for ループを作成すると、すべてのファイルを 1 つずつ変更する必要がなく、コピー後にポート番号を変更するだけで済みます (92 行目と 840 行目)。

6.3 Redisノードの起動

6.4 クラスタの起動

6.5 テストクラスター

他のノードで表示する

おすすめ

転載: blog.csdn.net/weixin_69148277/article/details/130799838