1.
Redis の高可用性 1.1 Redis の高可用性の概念
Web サーバーにおいて、高可用性とは、サーバーに正常にアクセスできる時間などを指します。
高可用性の計算式は 1-(ダウンタイム)/(ダウンタイム+実行時間) で、これはネットワーク送信パラメータのビット誤り率に似ています。可用性を表すには 9 という数字を使用します。
2 ナイン: 99%、1 年以内のダウンタイム: 1% x 365 日 = 3.6524 日 = 87.6 時間
フォーナイン：99.99%、1年以内のダウンタイム：0.01%×365日=52.56分
ファイブナイン: 99.999%、1 年以内のダウンタイム: 0.001%*365 日 = 5.265 分
イレブンナイン: ほぼ 1 年間のダウンタイムが秒単位で発生
ただし、Redis の文脈での高可用性の意味はもっと広いと思われ、通常のサービス (マスター/スレーブ分離、迅速な災害復旧技術など) の提供の確保に加えて、高可用性の拡張も考慮する必要があります。データ容量と損失のないデータセキュリティなど。
1.2 Redis の高可用性テクノロジー
Redisにおいて高可用性を実現する技術としては、主に永続化、マスタースレーブレプリケーション、セントリー、クラスタークラスターがあり、それぞれの機能とどのような問題を解決できるかについて説明します。
永続性: 永続性は最も単純な高可用性方法です (高可用性方法として分類されていない場合もあります)。その主な機能はデータのバックアップ、つまり、プロセスによってデータが失われないようにデータをハードディスクに保存することです。出口。
マスター/スレーブ レプリケーション: マスター/スレーブ レプリケーションは高可用性 Redis の基礎であり、Sentinel とクラスターは高可用性を実現するためにマスター/スレーブ レプリケーションに基づいています。マスター/スレーブ レプリケーションは主に、データの複数マシンのバックアップ (および同期) を実現するだけでなく、読み取り操作の負荷分散と単純な障害回復も実現します。
欠点: 障害回復は自動化できません。書き込み操作の負荷分散はできません。ストレージ容量は 1 台のマシンによって制限されます。
Sentinel: Sentinel は、マスター/スレーブ レプリケーションに基づいて、自動障害回復を実装します。(マスターがダウンしているため、新しいマスターとなるスレーブを見つけます。センチネル ノードがそれを監視します)
欠点: 書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。
クラスター クラスター: Redis は、クラスター化を通じて、書き込み操作の負荷分散ができず、ストレージ容量が 1 台のマシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。(マスター 3 台、スレーブ 3 台のペアで 6 セット開始)
クラスター クラスター: Redis は、クラスター化を通じて、書き込み操作の負荷分散ができず、ストレージ容量が 1 台のマシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。(マスター 3 台、スレーブ 3 台のペアで 6 セット開始)
2. Redis のマスター/スレーブ レプリケーション
マスター/スレーブ レプリケーションとは、1 つの Redis サーバーのデータを他の Redis サーバーにコピーすることを指します。前者をマスターノード(Master)、後者をスレーブノード(slave)と呼び、データの複製はマスターノードからスレーブノードへの一方向のみとなります。
デフォルトでは、各 Redis サーバーはマスター ノードであり、マスター ノードは複数のスレーブ ノードを持つことができます (またはスレーブ ノードを持たない) が、スレーブ ノードが持つことができるマスター ノードは 1 つだけです。
2.1 マスター/スレーブ レプリケーションの役割
データ冗長性: マスター/スレーブ レプリケーションは、永続化以外のデータ冗長化方法であるデータのホット バックアップを実装します。
障害回復: マスター ノードに問題が発生した場合、スレーブ ノードはサービスを提供して迅速な障害回復を実現できます。これは実際には一種のサービス冗長性です。
負荷分散: 読み取り/書き込み分離と組み合わせたマスター/スレーブ レプリケーションに基づいて、マスター ノードは書き込みサービスを提供し、スレーブ ノードは読み取りサービスを提供できます (つまり、アプリケーションは Redis データの書き込み時にマスター ノードに接続します) 、アプリケーションは Redis データの読み取り時にスレーブ ノードに接続します)、サーバーの負荷を共有するため、特に書き込みを減らし読み取りを増やすシナリオでは、複数のスレーブ ノードで読み取り負荷を共有すると、Redis サーバーの同時実行性が大幅に向上します。
高可用性の基礎: 上記の機能に加えて、マスター/スレーブ レプリケーションもセンチネルとクラスターの実装の基礎となるため、マスター/スレーブ レプリケーションは Redis の高可用性の基礎となります。
1.2 マスター/スレーブ レプリケーション プロセス
(1) スレーブ マシンのプロセスが開始されると、マスター マシンに同期コマンドを送信して同期接続を要求します。
(2) 最初の接続であっても再接続であっても、マスター マシンはバックグラウンド プロセスを開始してデータ ファイルにデータ スナップショットを保存し (rdb 操作を実行)、マスターはデータとキャッシュを変更するためのすべてのコマンドも記録します。データファイルの途中にあります。
(3) バックグラウンド プロセスがキャッシュ操作を完了した後、マスター マシンはデータ ファイルをスレーブ マシンに送信し、スレーブ マシンはデータ ファイルをハードディスクに保存してからメモリにロードし、次にマスター マシンがデータ ファイルをスレーブ マシンに送信します。マシンはすべてのデータ ファイルを変更します。操作はスレーブ マシンにも送信されます。スレーブに障害が発生してダウンタイムが発生した場合、通常に戻った後、自動的に再接続されます。
(4) マスター マシンがスレーブ マシンからの接続を受信した後、完全なデータ ファイルをスレーブ マシンに送信します。マスターが複数のスレーブから同時に同期要求を受信した場合、マスター マシンはバックグラウンドでプロセスを開始し、同期要求をスレーブ マシンに送信します。データファイルを保存してすべてのスレーブマシンに送信し、すべてのスレーブマシンが正常であることを確認します。
3. Redis マスター/スレーブ (1 つのマスターと 2 つのスレーブ) の
デプロイ実験の具体的な手順
1 redis を 1 つのマスター サーバーと 2 つのスレーブ サーバーをインストールします
//環境の準備
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
sed -i 's/enforcing/disabled/' /etc/selinux/config
#カーネルパラメータを変更する
vim /etc/sysctl.conf
vm.overcommit_memory = 1
net.core.somaxconn = 2048
sysctl -p
//redis をインストール
yum install -y gcc gcc-c++ make
tar zxvf /opt/redis-7.0.9.tar.gz -C /opt/
cd /opt/redis-7.0.9
make
make PREFIX=/usr/local/redis install
#Makefile は Redis ソースで直接提供されるためpackage なので、ソフトウェア パッケージを解凍した後、最初に ./configure を実行して構成する必要はなく、make および make install コマンドを直接実行してインストールできます。
#redis 作業ディレクトリの作成
mkdir /usr/local/redis/{conf,log,data}
cp /opt/redis-7.0.9/redis.conf /usr/local/redis/conf/
useradd -M -s /sbin/nologin redis
chown -R redis.redis /usr/local/redis/
#環境変数
vim /etc/profile
PATH=$PATH:/usr/local/redis/bin #行を追加
ソース/etc/profile
//systemd サービス管理スクリプトを定義します
vim /usr/lib/systemd/system/redis-server.service
[Unit]
description=Redis Server
After=network.target
[サービス]
User=redis
Group=redis
Type=forking
TimeoutSec=0
PIDFile=/usr/local/redis/log/redis_6379.pid
ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/ conf/redis.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true
[インストール]
WantedBy=multi-user.target
2 マスター・スレーブマスター設定ファイルの変更
----- Redis 設定ファイルの変更（マスターノードの操作） -----
vim /usr/local/redis/conf/redis.conf
binding 0.0.0.0
#87 行、リスニング アドレスを 0.0.0.0
protected-mode no
#111 行に変更、ローカル アクセス保護モードを no
port 6379 に設定
#138行、Redis はデフォルトでポート 6379 をリッスンします
daemonize yes
#309 行、デーモンプロセスとして設定、
pidfile /usr/local/redis/log/redis_6379.pid を開始
#341 行、PID ファイル
logfile "/usr/local/redisを指定します/log/ redis_6379.log"
#354 行、ログ ファイルのディレクトリを指定します
/usr/local/redis/data
#504 行、永続ファイルが配置されているディレクトリを指定します
#requirepass abc123
#1037 行、オプション、redis パスワードを設定します
appendonly はい
#1380 行、open AOF
systemctl restart redis-server.service
start redis サービス
----- Redis 設定ファイルの変更 (スレーブノード操作) -----
vim /usr/local/redis/conf/redis.conf
binding 0.0.0.0
#87 行、リスニングアドレスを 0.0.0.0 に変更
protected- mode no
#111 行、ローカル アクセス保護モードを設定します no
port 6379
#138 行、Redis はデフォルトでポート 6379 をリッスンします
daemonize yes
#309 行、デーモン プロセスとして設定します、
pidfile /usr/local/redis/log/を開始しますpid
#341 行、PID ファイルを指定
logfile "/usr/local/redis/log/redis_6379.log"
#354 行、ログ ファイル
dir /usr/local/redis/data
#504 行、永続ファイルが配置されているディレクトリを指定します
# requirepass abc123
#1037 行、オプション、redis パスワードを設定します
appendonly yes
#1380 行、
192.168.80.10 6379 の AOF レプリカ を開きます
#528 行、同期するマスター ノードの IP とポートを指定します
#masterauth abc123
#535 行、オプション、マスター ノードのパスワードを指定します
。マスターノードがredis-server.service を再起動して
サービスを開始します
実験テスト
マスター書き込みデータ
127.0.0.1:6379> キー *
127.0.0.1:6379> 名前を設定 zhangsan
127.0.0.1:6379>
データベースを表示するためにライブラリから名前 2 を 取得します
4. Redis センチネルモード マスター
/スレーブ切り替え技術の方式は、サーバーがダウンした場合、スレーブを手動でマスターに切り替える必要があり、これには手動介入が必要であり、時間と手間がかかるだけでなく、次のような問題が発生します。サービスが一定期間利用できなくなること。マスター/スレーブ レプリケーションの欠点を解決するために、センチネル メカニズムがあります。
Sentinel のコア機能: Sentinel は、マスター/スレーブ レプリケーションに基づいて、マスター ノードの自動フェイルオーバーを導入します。
センチネルモードの構成:
Sentinel ノード: Sentinel システムは、データを保存しない特別な Redis ノードである 1 つ以上の Sentinel ノードで構成されます。
データ ノード: マスター ノードとスレーブ ノードは両方ともデータ ノードです。
4.1 センチネルモードの役割
監視: Sentry は、マスター ノードとスレーブ ノードが適切に機能していることを常にチェックします。
自動フェイルオーバー: マスター ノードが正常に動作しない場合、Sentinel は自動フェイルオーバー操作を開始します。障害が発生したマスター ノードのスレーブ ノードの 1 つを新しいマスター ノードにアップグレードし、代わりに他のスレーブ ノードに新しいマスター ノードをコピーさせます。 。
通知 (リマインダー): Sentinel はフェイルオーバー結果をクライアントに送信できます。
さらに、センチネル ノードは他のホストから独立させることもでき、Redis のマスター/スレーブ レプリケーションのためにノード サーバーにインストールする必要はありません。
4.2 フェイルオーバーの仕組み
1. センチネルノードはマスターノードに障害が発生していないか定期的に監視しており、
各センチネルノードはマスターノード、スレーブノード、その他のセンチネルノードに対して1秒ごとにハートチェックのためpingコマンドを送信するよう依頼します。マスター ノードが特定の時間枠内に応答しない場合、またはエラー メッセージで応答した場合、センチネルはマスター ノードが主観的に (一方的に) オフラインであるとみなします。センチネル ノードの半数以上が主観的にマスター ノードがオフラインであると考える場合、客観的にはオフラインです。
2. マスター ノードに障害が発生すると、センチネル ノードは Raft アルゴリズム (選挙アルゴリズム) を通じて選挙メカニズムを実装し、マスター ノードのフェイルオーバーと通知の処理を担当するリーダーとしてセンチネル ノードを共同で選出します。したがって、Sentinel を実行するクラスターの数は 3 ノード以上である必要があります。
3. リーダーセンチネルノードはフェイルオーバーを実行します。プロセスは次のとおりです。
スレーブ ノードを新しいマスター ノードにアップグレードし、他のスレーブ ノードが新しいマスター ノードを指すようにします。元のマスター ノードが
回復すると、そのノードもスレーブ ノードになり、新しいマスター ノードを指すようになります。マスター ノードが回復したことを
クライアントに通知します。ノードが交換されました。
客観的オフラインはマスター ノードに固有の概念であることに注意することが重要です。スレーブ ノードとセンチネル ノードに障害が発生した場合、センチネルによって主観的にオフラインになった後は、その後の客観的オフラインおよびフェイルオーバー操作は行われません。
4.3 センチネル モードでのマスター ノードの選択
1. センチネル ping 応答に応答していない異常な (オフライン) スレーブ ノードを除外します。
2. 設定ファイル内で最も優先度の高い設定を持つスレーブ ノードを選択します。(レプリカの優先順位、デフォルト値は 100)
3. 最大のレプリケーション オフセットを持つスレーブ ノード、つまり最も完全なレプリケーションを選択します。
Sentinel の起動はマスター/スレーブ モードに依存するため、マスター/スレーブ モードをインストールした後に Sentry モードをインストールする必要があります。
5. Redis Sentinel モードの
デプロイ 実験的なコンポーネントのデプロイ
実験の具体的な操作手順は、
Redis マスター/スレーブ レプリケーションに基づいてセンチネル モードをデプロイすることです (上記の 1 マスター/2 スレーブ レプリケーションに基づいて実行するだけです)。
ステップ 1: センチネル ノードの構成ファイルを変更する (すべてのセンチネル ノードで同じ操作)
センチネルの構成ファイルは、redis ソフトウェアに付属する構成です。
cp /opt/redis-7.0.9/sentinel.conf /usr/local/redis/conf/
chown redis.redis /usr/local/redis/conf/sentinel.conf
vim /usr/local/redis/conf/sentinel。 conf
protected-mode no
#6 行、保護モード
ポート 26379 を閉じます
。 #10 行、Redis Sentinel daemonize のデフォルトのリスニング ポート、
yes
#15 行、バックグラウンドとして Sentinel を指定します。 start
pidfile /usr/local/redis/log/redis- Sentinel.pid
#20 行目、PID ファイル
logfile "/usr/local/redis/log/sentinel.log" を指定します
。 #25 行目、ログ ストレージ パス
dir /usr/local/redis/data を指定します
。 #54 行目、データベース ストレージ パス
センチネル モニター mymaster 192.168.80.10 6379 2
73 行目、センチネル ノードがマスター ノード 192.168.80.10:6379 を監視するように変更して指定します。
マスター ノードの名前は mymaster です。最後の 2 の意味は、マスター ノードの障害判定に関連しています。少なくとも 2 つです。マスターノード
の障害とフェイルオーバー
#sentinel auth-pass mymaster abc123
#76 行、オプション、マスター ノードのパスワードを指定、requirepass
Sentinel down-after-milliseconds mymaster 3000
#114 行のみを設定サーバーがダウンしている 期間、デフォルトは 30000 ミリ秒 (30 秒)
Sentinel fadeover-timeout mymaster 180000
#214 行、同じ Sentinel から同じマスターへの 2 つのフェイルオーバー間の間隔 (180 秒)
ステップ 2: Sentinel モードを開始する
まずマスターを開始し、次にスレーブを開始します。
cd /usr/local/redis/conf/
redis-sentinel Sentinel.conf &
-----查看警戒兵信息-----
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.5023:6379、スレーブ=2、センチネル=3
-----障害シミュレーション-----
#redis-server プロセス番号の表示:
ps -ef | grep redis
root 57031 1 0 15:20 ? 00:00:07 /usr/local/bin/redis-server 0.0 .0.0:6379
root 57742 1 1 16:05 ? 00:00:07 redis-sentinel *:26379 [センチネル]
root 57883 57462 0 16:17 pts/1 00:00:00 grep --color=auto redis
#マスターノード上のredis-serverのプロセス番号をkillします
kill -9 57031 #マスターノード上のredis-serverのプロセス番号
実験結果
[root@localhost redis-5.0.7]# tail -f /var/log/sentinel.log #
新しいマスターはキーと値のペアを作成します
[root@localhost redis-5.0.7]# redis-cli
127.0.0.1 : 6379> 新しい名前 lisi を設定
OK
127.0.0.1:6379> 新しい名前
"lisi"を取得
127.0.0.1:6379>
試験結果：
6. Redis クラスターモード
クラスター、つまり Redis Cluster は、Redis3.0 によって導入された分散ストレージ ソリューションです。
クラスターは複数のノード (Node) で構成され、Redis データはこれらのノード間に分散されます。クラスター内のノードはマスター ノードとスレーブ ノードに分割されます。マスター ノードのみが読み取りおよび書き込みリクエストとクラスター情報のメンテナンスを担当し、スレーブ ノードはマスター ノードのデータとステータス情報のみを複製します。
6.1 クラスターの役割
(1) データ パーティショニング: データ パーティショニング (またはデータ シャーディング) は、クラスターの中核機能です。
クラスターはデータを複数のノードに分散します。一方で、Redis 単一マシンのメモリー サイズの制限を突破し、ストレージ容量が大幅に増加します。他方、各マスター ノードは外部の読み取りおよび書き込みサービスを提供でき、これにより、クラスターの応答性が大幅に向上します。
Redis スタンドアロンのメモリ サイズは制限されており、これは永続性とマスター/スレーブ レプリケーションの紹介で説明したとおりです。その結果、スレーブ ノードは長時間サービスを提供できなくなり、マスター ノードのレプリケーション バッファーがオーバーフローする可能性があります。完全なレプリケーションフェーズ。
(2) 高可用性: クラスターはマスター/スレーブ レプリケーションとマスター ノードの自動フェイルオーバー (Sentinel と同様) をサポートしており、いずれかのノードに障害が発生しても、クラスターは引き続き外部サービスを提供できます。
Redis はクラスターを通じて、書き込み操作の負荷分散ができず、ストレージ容量が単一マシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。
6.2 Redis クラスターのデータ断片化
Redis Cluster では、ハッシュ スロットの概念が導入されています。
Redis クラスターには 16384 個のハッシュ スロット (0 ～ 16383 の番号が付けられます) があります。
クラスターの各ノードは、ハッシュ スロットの一部を担当します。
各キーが CRC16 チェックに合格した後、16384 の残りを取得して、どのハッシュ スロットに配置するかを決定します。この値を通じて、対応するスロットに対応するノードを見つけ、アクセス操作のために対応するノードに直接かつ自動的にジャンプします。
例として 3 つのノードで構成されるクラスターを取り上げます。
ノード A には 0 ～ 5460 のハッシュ スロットが含まれます。
ノード B には 5461 ～ 10922 のハッシュ スロットが含まれます。 ノード
c には 10923 ～ 16383 のハッシュ スロットが含まれます。
7. Redis クラスターのデプロイ
実際の運用環境では、Redis のクラスター クラスターには少なくとも 6 つのサーバーが必要です。コンピュータのパフォーマンスの問題が原因である場合にのみ実現できます
Redis マルチインスタンスのデプロイメントを試すことができます
実験用コンポーネントの展開
実験の具体的な手順
ステップ 1
cd /usr/local/redis/
mkdir -p redis-cluster/redis600{1..6}
for i in {1..6}
do
cp /opt/redis-7.0.9/ redis.conf /usr/local/redis/redis-cluster/redis600$i
cp /opt/redis-7.0.9/src/redis-cli /opt/redis-7.0.9/src/redis-server
/usr/local /redis /redis-cluster/redis600$i
完了
ステップ 2 #クラスター機能を有効にします。
#他の 5 つのフォルダーの構成ファイルは同様に変更されており、6 つのポートは異なる必要があります。
cd /usr/local/redis/redis-cluster/redis6001
vim redis.conf
#bind 127.0.0.1
#87 行、バインド項目をコメントアウト、デフォルトですべてのネットワーク カードを監視
protected-mode no
#111 行、保護モードを閉じる
ポート 6001
#138 OK、Redis リスニング ポートを変更します
daemonize yes
#309 行、デーモンプロセスとして設定、
pidfile /usr/local/redis/log/redis_6001.pid を開始
#341 行、PID ファイルの指定
logfile "/usr/local/redis/log/redis_6001.log"
#354行、ログ ファイル
dir ./ を指定します
。 #504 行、永続ファイルが
保存されて いるディレクトリを指定します。 appendonly Yes #1379 行、
AOF を有効化します。 .conf #1584 行、コメントを解除、クラスター名ファイルセットクラスターノードタイムアウト 15000 #1590 行、クラスタータイムアウト設定のコメントを解除
6001 が構成されている場合、構成ファイルを 6002 ～ 6006 に直接コピーし、sed -i を使用して直接変更できます。
ホーム : sed -i 's/6001/6002/g' usr/local/redis/redis-cluster/redis6002
sed -i 's/6001/6003/g' usr/local/redis/redis-cluster/redis6003
sed -i 's/6001/6004/g' usr/local/redis/redis-cluster/redis6004
sed -i 's/6001/6005/g' usr/local/redis/redis-cluster/redis6005
sed -i 's/6001/6006/g' usr/local/redis/redis-cluster/redis6006
ステップ 3 Redis ノードを起動します。
6 つのフォルダーをそれぞれ入力し、コマンド redis-server redis.conf を実行して、redis ノードを起動します。
cd /usr/local/redis/redis-cluster/redis-cluster/redis-cluster/redis6001
redis- server redis.conf
または
for d in {1..6}
do
cd /usr/local/redis/redis-cluster/redis600$d
./redis-server redis.confned ps -ef | grep
redis
ステップ 4#クラスターの開始
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
#6 つのインスタンスは 3 つのグループに分割され、各グループに 1 つのマスターと 1 つのスレーブが含まれます。前者がマスター ノード、後者がスレーブ ノードです。
以下の操作を行う場合、作成するには「yes」と入力する必要があります。
--replicas 1 は、各マスター ノードに 1 つのスレーブ ノードがあることを意味します。
クラスターのテスト
redis-cli -p 6001 -c # -c パラメーターを追加します。ノードは相互にジャンプできます
127.0.0.1:6001> クラスター スロット # ノードのハッシュ スロット番号範囲を表示します
1) 1) (整数) 5461
2 ) (整数) 10922 #ハッシュ スロット番号の範囲
3) 1) "127.0.0.1"
2) (整数) 6003 #プライマリ ノードの IP およびポート番号
3) "fdca661922216dd69a63a7c9d3c4540cd6baef44"
4) 1) "127.0.0.1"
2) (整数) 6 004 #スレーブノードのIPとポート番号
3) "a2c0c32aff0f38980accd2b63d6d952812e44740"
2) 1) (整数) 0
2) (整数) 5460
3) 1) "127.0.0.1"
2) (整数) 6001
3) "0e5873747a2e26bdc935bc76c2bafb19d0a54b11"
4) 1) "127.0.0.1"
2) (整数) 6006
3) "8842ef5584a85005e135fd0ee59e5a0d67b0cf8e"
3) 1) (整数) 10923
2) (整数) 16383
3) 1) "127.0.0.1"
2 ) (整数) 6002
3 ) "816ddaa3d1469540b2ffbcaaf9aa867646846b30"
4) 1) "127.0.0.1"
2) (整数) 6005
3) "f847077bfe6722466e96178ae8cbb09dc8b4d5eb"
127.0.0.1 :60 01> 名前を設定 zhangsan -> 127.0.0.1:6003 OK 127.0
にあるスロット [5798] にリダイレクトされました.0.1:6001> クラスター キースロット名 #名前キーのスロット番号を表示しますredis-cli -p 6004 -c 127.0.0.1: 6004> key * #対応するスレーブ ノードにもこのデータがありますが、他のノードにはありません
1) "名前"
redis-cli -p 6001 -c クラスターノード
ステップ 5: 動的拡張のためにクラスターにノードを追加する.
Redis 5 クラスターは、負荷がかかっているノードの動的拡張をサポートしています。
既存のクラスターには 6 つのノード 127.0.0.1:6001 ～ 127.0.0.1:6006 と、マスター ノードとスレーブ ノードの 3 つのグループがあります。次に、マスター/スレーブ ノードの 4 番目のグループ 127.0.0.1:6007、127.0.0.1:6008 を追加します。
1) まずクラスターノードを作成し、ポート番号を 6007、6008 に変更してクラスタークラスターに追加し
ます。 2) 新しいマスターノードを作成します 127.0.0.1:6007
redis-cli -p 6001 --cluster add-node 127.0.0.1 : 6007 127.0.0.1:6001
または
redis-cli -p 6001
クラスターが 127.0.0.1 に適合 6007
クラスターが 127.0.0.1 に適合 6008
3) 127.0.0.1:6007 redis-cli --cluster add-node 127.0.0.1:6008 127.0.0.1:6001 --cluster- slave のスレーブノードとして 127.0.0.1:6008 を作成します(以下のマスターは省略可能です、マスター ノードは 1 つだけあり、スレーブ ノードは存在しません)
redis-cli -p 6001 --cluster add-node 127.0.0.1:6008 127.0.0.1:6001 --cluster-slave --cluster-master-id e44678abed249e22482559136bf45280fd3ac281
クラスタ情報とマスターノードのノードIDを取得するには、コマンドで既存のノードを指定する必要があります
4) 新しく追加されたマスター ノードにはスロット番号がありません。クラスターが初期化されるときのみ、マスターのデータに従って割り当てられます。たとえば、新しく追加されたマスター ノードは手動で割り当てる必要があります。まず、クラスター ノードを使用します。
クラスター内の各ノードのノード ID 番号を取得します。
スロットの再シャード: Redis 5 はスロットの自動バランシングをまだサポートしていないため、移動する必要があるスロットの数を計算し、コマンドを手動で実行する必要があります。この例では、バランスを保つために、既存のマスター ノードの 3 つのグループから 1365 個のスロットを新しいマスター ノード 127.0.0.1:6007 に移動する必要があります。
redis-cli -p 6007 --cluster reshard 127.0.0.1:6001 --cluster-from \ e1a033e07f0064e6400825b4ddbcd6680c032d10 --cluster-to \ e44678abed249e22482559136bf45280fd3ac281 --クラスタースロット 1365 --cluster-yes
同様に、マスター ノード 6002 と 6003 も 1365 スロットをマスター ノード 6007 に移動する必要があります。
または、ハッシュ スロットを対話的に転送する
か、
redis-cli -p 6007 --cluster reshard 127.0.0.1:6001移動
するスロットの数 (1 ～ 16384)? 1000 #
転送スロットの数を指定します
ノード ID? e44678abed249e22482559136bf45280fd3ac281
#受信スロットの数のマスター ノード ID を指定してください
すべてのソース ノード ID を入力してください。すべて
のノードをハッシュ スロットのソース ノードとして使用するには、「all」と入力します。すべてを入力したら、
「done」と入力します。ソース ノード ID。
ソース ノード #1: e1a033e07f0064e6400825b4ddbcd6680c032d10
#割り当てられたマスター ノード ID を指定します
ソース ノード #2:done #
入力を入力して転送を開始します