Docker 経由で Redis 6.x クラスターをデプロイする方法

システム環境:

• Redis バージョン: 6.0.8
• Docker バージョン: 19.03.12
• システムバージョン: CoreOS 7.8
• カーネルバージョン: 5.8.5-1.el7.elrepo.x86_64

1. Redis クラスターモードとは

Redis クラスター モードは、Redis 3.0 バージョン以降に正式にリリースされました。このモードは、Redis の分散ソリューションです。複数の Redis ノード間でデータ共有を提供するプログラム セットです。Redis クラスターは分散化されています。各マスター ノードはデータを読み書きできます。各ノードは対等な関係にあり、各ノードは独自のデータとクラスター全体のステータスを維持します。

Redis クラスター設計の主な目的は、Redis データ ストレージを線形に拡張し、パーティショニングによって一定の可用性を提供することです。実際の環境では、ノードがダウンしたり、到達不能になったりしても、コマンドの処理を継続できます。ただし、重大な障害が発生した場合 (たとえば、マスター ステーションのほとんどが使用できない場合)、クラスターは実行を停止します。つまり、Redis クラスターはデータの強力な一貫性を保証できません。

2. Redis クラスターが必要な理由

• 高可用性: Redis クラスター モードでは、各マスターはマスター スレーブ レプリケーション モードになります。マスター ノードのデータは、スレーブ ノードにリアルタイムで同期されます。マスター ノードが使用できない場合は、対応するスレーブ ノードの ID がマスター ノードに変更され、クラスターの可用性が確保されます。
• データの水平拡張: Redis はメモリ内データベースです。すべてのデータはメモリ内に保存されます。サーバーが単一ノードで提供できるメモリには制限があります。データ量が一定レベルに達すると、メモリが不足して大量のデータの保存をサポートできなくなります。このとき、データをシャードに保存する必要があります。Redis クラスター モードでは、データをシャードに保存するため、水平方向の拡張に非常に便利です。

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

Redis クラスターは一貫性ハッシュを使用しませんが、「ハッシュ スロット」の概念を導入します。 Redis クラスターには 16384 個のハッシュ スロットがあります。各キーは CRC16 でチェックされ、16384 を法としてどのスロットに配置するかが決定されます。クラスター内の各ノードはハッシュ スロットの一部を担当します。

たとえば、現在のクラスターに 3 つのノードがある場合は、次のようになります。

• ノード A にはハッシュ スロット 0 ～ 5460 が含まれます。
• ノード B にはハッシュ スロット 5461 ～ 10922 が含まれます。
• ノード C にはハッシュ スロット 10923 から 16383 が含まれます。

この構造により、ノードの「追加」や「削除」が簡単になります。たとえば、新しいノード D を追加する場合は、ノード A、B、C からノード D にいくつかのスロットを転送する必要があります。ノード A を削除する場合は、A のスロットをノード B と C に移動し、スロットのないノード A をクラスターから削除する必要があります。ハッシュ スロットをあるノードから別のノードに移動してもサービスは停止しないため、ノード上のハッシュ スロットの数を追加、削除、または変更しても、クラスターが使用できなくなることはありません。

Redis は複数のキー操作をサポートしており、これらのキーが単一のコマンド (またはトランザクション、または Lua スクリプトの実行) で実行される限り、それらは同じハッシュ スロットに属します。ハッシュ タグ コマンドを使用して、複数のキーを同じハッシュ スロットに強制的に配置することもできます。

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

クラスター内のマスタースレーブモデル

Redis クラスター モードでは、ダウンタイムによりクラスター内の一部のノードが使用できなくなるのを防ぐために、Redis クラスターはマスター/スレーブ レプリケーション モードを使用します。このモードでは、Redis クラスターには少なくとも 6 つのノードが必要であり、そのうち 3 つは外部の読み取りと書き込みを提供できるマスター ノードです。スレーブ ノードであるノードも 3 つあり、対応するマスター ノードのデータを同期します。マスターノードに問題が発生して使用できなくなった場合、Redis は選出アルゴリズムを通じてマスターノードに対応するスレーブノードからノードを選択し (マスターノードに複数のスレーブノードがある場合)、それを新しいマスターノードに変更して、外部にサービスを提供できるようにします。

たとえば、マスター ノード A、B、C の 3 つと、それに対応するスレーブ ノード (A1、A2)、(B1、B2)、(C1、C2) の 6 つがあり、合計 9 つのノードがあるとします。ノード A に障害が発生すると、対応するスレーブ ノード A1 と A2 は選出アルゴリズムを使用して、マスター ノードに昇格するノードを 1 つ選択し、クラスターが通常のサービスを提供できるようにします。ただし、2 つのスレーブ ノード A1 と A2、またはマスター ノードの半数以上が使用できない場合は、クラスターも使用できなくなります。

Redis クラスター モードを展開する場合、クラスターの可用性を確保するために、少なくとも 6 つのノードでクラスターを形成する必要があります。

マスタースレーブレプリケーションの関連概念

（１）完全レプリケーションと増分レプリケーション

Redis マスタースレーブ レプリケーションには、「完全レプリケーション」と「増分レプリケーション」という 2 つのデータ同期方法があります。

• 完全レプリケーション:初期レプリケーションまたは部分的なレプリケーションが不可能なその他の状況で使用され、マスター ノード内のすべてのデータがスレーブ ノードに送信されます。データの量が多すぎると、ネットワークのオーバーヘッドが大きくなります。
• 増分レプリケーション:マスター スレーブ レプリケーションでネットワーク クラッシュやその他の原因によって発生するデータ損失シナリオを処理するために使用されます。スレーブ ノードがマスター ノードに再度接続すると、条件が許せば、マスター ノードは失われたデータをスレーブ ノードに再送信します。再送信されたデータは完全なデータよりもはるかに小さいため、完全なレプリケーションの過剰なオーバーヘッドを効果的に回避できます。ただし、ネットワーク中断時間が長すぎて、マスターノードが中断中に実行された書き込みコマンドを完全に保存できない場合は、部分的なレプリケーションは実行できず、完全なレプリケーションが引き続き使用されることに注意してください。

（２）コピー位置のオフセットを記録する

• レプリケーションに参加しているマスター ノードとスレーブ ノードは、独自のレプリケーション オフセットを維持します。書き込みコマンド操作を処理した後、マスター ノードはコマンドのバイト長を累積的に記録します。info info replicationコマンドを使用して、 master_repl_offsetオフセット情報を照会できます。
• スレーブ ノードは自身のレプリケーション オフセットを毎秒マスター ノードに報告するため、マスター ノードもスレーブ ノードのレプリケーション オフセットを保存します。
• マスターノードから送信されたコマンドを受信すると、スレーブノードも自身のオフセットを蓄積して記録します。info info replicationコマンドを使用して、 slave_repl_offsetオフセット情報を照会できます。

（３）バックログバッファをコピーする

レプリケーション バックログ バッファは、マスター ノードに保存される固定長のキューです。デフォルト サイズは 1MB です。マスター ノードにスレーブ ノードが接続されている場合、このキューが作成されます。マスター ノードが書き込みコマンドに応答すると、コマンドをスレーブ ノードに送信するだけでなく、書き込みコマンドのバックアップとしてレプリケーション バックログ バッファに書き込みます。

書き込みコマンドの保存に加えて、レプリケーション バックログ バッファには、バッファ内の各バイトに対応するレプリケーション オフセットも保存されます。レプリケーション バックログ バッファは固定長で先入れ先出し方式であるため、プライマリ ノードによって最後に実行された書き込みコマンドが格納され、古い書き込みコマンドはバッファから削除されます。

（4）ノード実行ID

• 各 Redis ノードが起動すると、40 ビットの 16 進文字列が実行 ID として動的に割り当てられます。実行 ID の主な機能は、Redis ノードを一意に識別することです。たとえば、スレーブ ノードはマスター ノードの実行 ID を保存して、どのマスター ノードを複製しているかを識別します。 IP + ポートのみを使用してマスターノードを識別すると、マスターノードが再起動し、データセット全体が変更されます (RDB/AOF ファイルの置き換えなど)。スレーブノードがオフセットに基づいてデータをコピーするのは安全ではありません。したがって、実行中の ID が変更されると、スレーブノードは完全なコピーを実行します。 info server コマンドを使用すると、現在のノードの実行 ID を表示できます。
• Redis をシャットダウンして再起動すると、実行 ID もそれに応じて変更されることに注意してください。

マスタースレーブレプリケーションの実行プロセス

（１）psyncコマンド

スレーブ ノードは psync を使用して、マスター ノードから runid とオフセットを取得します。

マスター ノードは、自身の状況に基づいて応答メッセージを返します。完全なレプリケーションをトリガーする場合は FULLRESYNC runid オフセット、増分レプリケーションをトリガーする場合は CONTINUE になります。

（２）psyncは完全なレプリケーションをトリガーする

スレーブ ノードは psync コマンドを使用して部分的なレプリケーションと完全なレプリケーション機能を実行します。

スレーブ ノードがマスター ノードに初めて接続すると、完全なコピーが実行されます。

①スレーブノードはpsync? - 1コマンドを送信し、マスターにデータ同期の実行を要求することを示します。

② マスターはオフセットがなく、レプリケーションを実行するのは初めてであることを検出します。フルレプリケーションを実行し、FULLRESYNC {runid} {offset}コマンドを送信して、runidとオフセットをスレーブノードに送信します。

③スレーブノードはマスターノードから送信されたrunidとオフセット情報を保存します。

④ マスターノードはbgsaveを実行してRBDスナップショットファイルを生成し、バッファを使用して今後実行されるすべてのコマンドを記録します。

⑤ マスターノードはRBDファイルをスレーブノードに送信します。

⑥マスターノードはBUFFERバッファ領域に記録された書き込みコマンドをスレーブノードに送信します。

⑦スレーブノードは古いデータをクリアします。

⑧スレーブノードはマスターノードから渡されたRBDファイルをロードします。

（２）psyncは増分レプリケーションをトリガーする

スレーブ ノードがマスター ノードから切断されると、スレーブ ノードはマスター ノードに再接続し、増分レプリケーションがトリガーされます。プロセスは次のとおりです。

①スレーブノードはpsyncを使用してrunidとオフセット値を送信します。

② マスターノードはスレーブノードから送信されたrunidが自身のものと同じかどうかを確認します。

• 同じではありません:同じでない場合は、完全なコピーを実行します。
• 同じ:対応するオフセットがキャッシュ内に存在するかどうかも確認する必要があります。存在しない場合は、完全コピーを実行します。存在する場合は、増分コピーを実行します。

③ 対応するオフセット条件が満たされた後、バッファ内のオフセット値がスレーブノードから送信されたオフセットと同じかどうかを確認します。

• 同じ:返されるオフセット値は同じであり、コピー操作は実行されません。
• 異なる: CONTINUE オフセット コマンドを送信します (注: ここでのオフセットは、マスター ノード キャッシュに記録されたオフセット値であり、スレーブ ノードによって渡されたオフセット値ではありません)。

④マスターノードは、スレーブノードから送信されたオフセットからマスターノードのバッファに記録されたオフセットまでのデータをレプリケーションバッファからコピーし、この範囲のデータをスレーブノードに渡します。

5. Redis クラスター関連の概念

Redis クラスターの一貫性

Redis の公式ドキュメントには、強力なデータ一貫性を保証できない、つまり、Redis クラスターに書き込まれたデータが特定の条件下で失われる可能性があると記載されています。主な理由は、Redis クラスターが非同期レプリケーション モードを使用していることです。書き込みプロセスは次のとおりです。

実行順序は次のとおりです。

① クライアントは任意のマスターノードにコマンドを書き込みます。

② マスターノードはコマンド実行のステータスをクライアントに応答します。

③マスターノードは書き込み操作コマンドをスレーブノードに渡します。

Redis クラスターは、パフォーマンスと一貫性のバランスをとっています。マスター ノードは、クライアントの書き込みコマンドを受信した後、実行されたコマンドを各スレーブ ノードに送信して同期するように設定されています。このプロセスは非同期操作であり、マスター ノードはスレーブ ノードの応答を待たずに、クライアント コマンドの実行ステータスにすぐに応答します。このように同期操作を減らすことで、システムの実行速度が大幅に向上し、スレーブ ノードがメッセージに応答するのを待つプロセスがシステム パフォーマンスのボトルネックになることを回避できます。

ただし、マスターノードは情報を受信した後、スレーブノードからの応答を待たずにコマンド実行ステータスをクライアントに応答するため、ノードに問題が発生するとデータ損失が発生する可能性があります。たとえば、クライアントがマスターノードにコマンドを送信し、マスターノードがデータバックアップのためにそのコマンドを非同期的にスレーブノードに送信し、その後すぐにコマンド実行ステータスをクライアントに応答します。このプロセス中に、マスターノードに問題が発生してクラッシュし、スレーブノードでもマスターノードから送信された同期データを処理する際にエラーが発生します。この時点でマスター ノードがダウンしているか使用できない場合は、スレーブ ノードが新しいマスター ノードに変換され、以前のマスター ノードで実行されたコマンドは失われます。

Redis クラスタ間通信メカニズム

Redis クラスターでは、データ ノードが 2 つの TCP ポートを提供します。ファイアウォールを構成するときは、次の 2 種類のポートを同時に開く必要があります。

• 共通ポート:デフォルトの 6379 などのクライアント アクセス ポート。
• クラスター ポート:通常のポート番号に 10000 を加えた番号 (例: 6379)。クラスター ポートは 16379 で、クラスター ノード間の通信に使用されます。

クラスター内のノード間の通信には、ゴシッププロトコルが使用されます。ノードは、一定の頻度（10回/秒）でスケジュールされたタスクに基づいて判断を行います。ノードの追加や削除、スロットステータスの変更など、クラスターの状態が変化すると、ノード間の通信を通じてクラスターの状態が同期され、クラスターが収束します。クラスター間で送信されるゴシップ メッセージには 5 つの種類があります。

• MEET:ノード ハンドシェイク フェーズ中に、新しく参加したノードに meet メッセージが送信され、新しいノードに現在のクラスターに参加するように要求します。新しいノードは、メッセージを受信した後、pong メッセージで応答します。
• PING:ノードは互いに ping メッセージを送信し、メッセージを受信したノードは pong メッセージで応答します。 Ping メッセージの内容には、このノードと他のノードのステータス情報が含まれており、ステータスの同期を実現します。
• PONG: pong メッセージには独自のステータス データが含まれます。ping または meet メッセージを受信すると、pong メッセージで応答し、クラスターに pong メッセージをアクティブにブロードキャストします。
• FAIL:マスター ノードは、別のマスター ノードが障害状態になったと判断すると、このメッセージをクラスターにブロードキャストします。受信ノードはメッセージを保存し、障害が発生したノードのステータスを判断します。
• PUBLISH:ノードがパブリッシュ コマンドを受信すると、まずコマンドを実行し、次にパブリッシュ メッセージをクラスターにブロードキャストします。メッセージを受信したノードもパブリッシュ コマンドを実行します。

Redis クラスターの障害ステータス

また、Redis クラスター モードでは、クラスターの可用性を 100% 保証することはできません。予期しないイベントが発生すると、Redis クラスターは障害状態になり、その場合、Redis クラスターは正常にサービスを提供できなくなります。障害状態に入る条件は主に次のとおりです。

① すべてのノードがダウンした場合、クラスターは障害状態になります。

② マスターノードの半数以上が利用できない場合、クラスターは障害状態になります。

③ いずれかのマスターノードに障害が発生し、そのマスターノードに対応するスレーブノードがない場合、またはすべてのスレーブノードに障害が発生した場合、クラスターは障害状態になります。

Redis クラスターの再シャーディングメカニズム

Redis クラスターの再シャーディング (ノードの追加/削除) メカニズム:

新しいノードを追加する: 他のノードからいくつかのスロットを新しいノードに割り当てます

ノードの削除: ノードのスロットを削除し、別のノードに割り当てます

ただし、これらの操作は手動で行う必要があり、サーバーを停止せずに実行できます。

Redis クラスターの欠点

レプリケーション構造はツリー構造ではなく、単層構造のみをサポートします。

複数のデータベースはサポートされていません。データベース 0 のみを使用して、select 0 コマンドを実行することができます。

キーは、データ パーティションの最小粒度です。大きなキーと値のペアを異なるノードにマップすることはできません。

キー トランザクションのサポートは制限されています。複数のキーが異なるノードに分散されている場合、トランザクションは使用できません。トランザクションは同じノードでのみサポートされます。

mset コマンドや mget コマンドなどのバッチ キー操作のサポートは制限されています。複数のキーが異なるスロットにマップされている場合、これらのコマンドは正常に使用できません。

Redis クラスター構成パラメータ

サンプル クラスターのデプロイメントを作成します。先に進む前に、Redis Cluster が redis.conf ファイルに導入する構成パラメータについて説明します。

cluster-config-file: Redis クラスターの構成情報とステータスの保存場所を設定します。このファイルは Redis クラスターによって生成され、保存場所のみを指定できます。

cluster-node-timeout: Redis クラスター ノードの通信タイムアウトを設定します。

cluster-migration-barrier:マスターノードに必要なスレーブノードの最小数。この数に達した場合にのみ、マスターノードに障害が発生したときにスレーブノードが移行します。

cluster-enabled: Redis クラスター モードを有効にするかどうか。

yes: Redis クラスターを有効にします。

no: クラスター モードを有効にしません。

cluster-require-full-coverage:クラスターの可用性を設定します。

yes: スロットを担当するマスター ライブラリがオフラインになり、障害回復を実行するための対応するスレーブ ライブラリがない場合、クラスターは使用できないことを示します。この状況は以下に示されます。

no: スロットを担当するマスター ライブラリがオフラインになり、障害回復を実行するための対応するスレーブ ライブラリがない場合でも、クラスターは引き続き使用可能であることを示します。この状況は、以下に示されます。

クラスタースレーブの有効係数:

0: スレーブ ノードがマスター ノードとの接続をどれだけ長く失っても、スレーブ ノードはマスター ノードへのアップグレードを試みます。

正の数: cluster-node-timeout * cluster-slave-validity-factorで取得される時間は、スレーブ ノードがマスター ノードとの接続を失った後、スレーブ ノードのデータが有効である最大時間です。この時間を超えると、スレーブ ノードはフェイルオーバーを開始しません。 cluster-node-timeout=5 、 cluster-slave-validity-factor=10と仮定すると、スレーブノードがマスターノードとの接続を 50 秒以上失った場合、スレーブノードはマスターノードになることができません。

6. DockerでRedisクラスタをデプロイする

1. Redis デプロイメントマシンの割り当て

ここでは、デプロイする Redis クラスターのノードを割り当て、それらを異なるマシンにデプロイします。配置は次のようになります。

2. データ保存ディレクトリを作成する

Redis 設定ファイルと永続データを保存するためのディレクトリを事前に作成します。

最初のサーバー192.168.2.11にストレージ ディレクトリを作成するコマンドを実行します。

$ mkdir -p /var/lib/redis/7000 および mkdir -p /var/lib/redis/7003

2 番目のサーバー192.168.2.12にストレージ ディレクトリを作成するコマンドを実行します。

$ mkdir -p /var/lib/redis/7001 および mkdir -p /var/lib/redis/7004

3 番目のサーバー192.168.2.13にストレージ ディレクトリを作成するコマンドを実行します。

$ mkdir -p /var/lib/redis/7002 および mkdir -p /var/lib/redis/7005

3. Redis設定ファイルを作成する

最初のサーバー192.168.2.11構成ファイル:

## 7000 ポート設定ファイル $ cat > /var/lib/redis/7000/redis.conf << EOF
ポート 7000
クラスタ対応 はい
クラスター構成ファイル nodes.conf
クラスターノードタイムアウト 5000
追加のみ はい
悪魔化する
保護モードなし
pidファイル /data/redis.pid
終了
 
## 7003 ポート設定ファイル $ cat > /var/lib/redis/7003/redis.conf << EOF
ポート 7003
クラスタ対応 はい
クラスター構成ファイル nodes.conf
クラスターノードタイムアウト 5000
追加のみ はい
悪魔化する
保護モードなし
pidファイル /data/redis.pid
終了

2番目のサーバー192.168.2.12構成ファイル

## 7001 ポートの設定: redis.conf
$ cat > /var/lib/redis/7001/redis.conf << EOF
ポート 7001
クラスタ対応 はい
クラスター構成ファイル nodes.conf
クラスターノードタイムアウト 5000
追加のみ はい
悪魔化する
保護モードなし
pidファイル /data/redis.pid
終了
 
## 7004 ポートの設定: redis-7004.conf
$ cat > /var/lib/redis/7004/redis.conf << EOF
ポート 7004
クラスタ対応 はい
クラスター構成ファイル nodes.conf
クラスターノードタイムアウト 5000
追加のみ はい
悪魔化する
保護モードなし
pidファイル /data/redis.pid
終了

3番目のサーバー192.168.2.13設定ファイル

## 7002 ポートの設定: redis-7002.conf
$ cat > /var/lib/redis/7002/redis.conf << EOF
ポート 7002
クラスタ対応 はい
クラスター構成ファイル nodes.conf
クラスターノードタイムアウト 5000
追加のみ はい
悪魔化する
保護モードなし
pidファイル /data/redis.pid
終了
 
## 7005 ポートの設定: redis-7005.conf
$ cat > /var/lib/redis/7005/redis.conf << EOF
ポート 7005
クラスタ対応 はい
クラスター構成ファイル nodes.conf
クラスターノードタイムアウト 5000
追加のみ はい
悪魔化する
保護モードなし
pidファイル /data/redis.pid
終了

4. 事前にRedisイメージをプルする

実行中にイメージをプルする必要がないよう、3 つのサーバーから事前に Redis イメージをプルして、操作が遅くならないようにしておきます。

$ docker pull redis:6.0.8

5. Redisイメージを実行して起動する

3 つのサーバーは Docker run コマンドを実行して Redis イメージを起動します。ここで注意すべき点は、異なるサーバー上の Docker は相互に通信できないため、ここでは起動したコンテナーのネットワーク モードをホスト モードに設定し、コンテナーが仮想ネットワーク カードを作成せず、ホストのネットワークを使用するようにします。

• -d: コンテナをバックグラウンドで実行するように設定します。
• -v: マウントされたホストストレージディレクトリを指定します。
• --name: 実行後のコンテナの名前を指定します。
• --cpus: コンテナが使用する CPU の数を指定します。
• --memory: コンテナが使用するメモリの量を制限します。
• --memory-swap: スワップ メモリのサイズを指定します。ここでは 0 に設定されており、スワップ メモリは使用されないことを意味します。
• --net: Docker が使用するネットワーク モードを指定します。
• --restart: Docker が再起動するときのコンテナの再起動戦略を指定します。
• --privileged: コンテナに特権を与え、ホスト マシンのルート権限を取得できるようにします。

最初のサーバー192.168.2.11次のコマンドを実行します。

## ポート7000でRedisイメージを実行する
 $ docker run -d -v /var/lib/redis/7000:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privileged=true \
--restart=常に\
--net ホスト \
--name redis-7000 \
redis:6.0.8 redis-server /data/redis.conf
 
## ポート7003でRedisイメージを実行する
 $ docker run -d -v /var/lib/redis/7003:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privileged=true \
--restart=常に\
--net ホスト \
--name redis-7003 \
redis:6.0.8 redis-server /data/redis.conf

2番目のサーバー192.168.2.12次のコマンドを実行します。

## ポート7001でRedisイメージを実行する
 $ docker run -d -v /var/lib/redis/7001:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privileged=true \
--restart=常に\
--net ホスト \
--name redis-7001 \
redis:6.0.8 redis-server /data/redis.conf
 
## ポート7004でRedisイメージを実行する
 $ docker run -d -v /var/lib/redis/7004:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privileged=true \
--restart=常に\
--net ホスト \
--name redis-7004 \
redis:6.0.8 redis-server /data/redis.conf

3 番目のサーバー192.168.2.13次のコマンドを実行します。

## ポート7002でRedisイメージを実行する
 $ docker run -d -v /var/lib/redis/7002:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privileged=true \
--restart=常に\
--net ホスト \
--name redis-7002 \
redis:6.0.8 redis-server /data/redis.conf
 
## ポート7005でRedisイメージを実行する
 $ docker run -d -v /var/lib/redis/7005:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privileged=true \
--restart=常に\
--net ホスト \
--name redis-7005 \
redis:6.0.8 redis-server /data/redis.conf

6. Redisクラスターを作成する

任意のサーバーをランダムに入力し、Redis イメージの redis-cli ツールを使用して create cluster コマンドを実行し、各 Redis をクラスターにします。ここでは、最初のサーバー192.168.2.11を入力し、ポート7000のRedisエンド イメージを使用して、次のコマンドを実行します。

-p: Redis に接続するポートを指定します。

create: Redis クラスターを作成します。

--cluster: Redis クラスター モード コマンドを使用します。

--cluster-replicas: レプリカの数 (スレーブ数) を指定します。

$ docker exec -it redis-7000 \
redis-cli -p 7000 --cluster を作成 \
192.168.2.11:7000 192.168.2.12:7001 192.168.2.13:7002 \
192.168.2.11:7003 192.168.2.12:7004 192.168.2.13:7005 \
--クラスタレプリカ1

すると、次の情報が表示されます。

>>> 6 つのノードでハッシュ スロットの割り当てを実行しています...
マスター[0] -> スロット0 - 5460
マスター[1] -> スロット5461 - 10922
マスター[2] -> スロット 10923 - 16383
レプリカ 192.168.2.12:7004 を 192.168.2.11:7000 に追加
レプリカ 192.168.2.13:7005 を 192.168.2.12:7001 に追加
レプリカ 192.168.2.11:7003 を 192.168.2.13:7002 に追加
5e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000
   スロット:[0-5460] (5461スロット) マスター
36565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001
   スロット:[5461-10922] (5462スロット) マスター
0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002 です
   スロット:[10923-16383] (5461 スロット) マスター
42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003
   0cc1aaf960defae7332e9256dd25ee5e5c99e65f を複製します
ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004
   5e50824c55d4df42db4d2987796f0c0b468c273f を複製します
470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005
   36565e0273fd62921aa1f2d85c5f7ac98a5b9466 を複製する
上記の設定を行えますか? (同意する場合は「はい」と入力してください): はい
>>> ノード構成が更新されました
>>> 各ノードに異なる構成エポックを割り当てる
>>> クラスターに参加するためにCLUSTER MEETメッセージを送信する
クラスターの参加を待機中
。
>>> クラスター チェックを実行しています (ノード 192.168.2.11:7000 を使用)
5e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000
   スロット:[0-5460] (5461スロット) マスター
   追加のレプリカ 1 個
470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005
   スロット: (0 スロット) スレーブ
   36565e0273fd62921aa1f2d85c5f7ac98a5b9466 を複製する
42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003
   スロット: (0 スロット) スレーブ
   0cc1aaf960defae7332e9256dd25ee5e5c99e65f を複製します
ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004
   スロット: (0 スロット) スレーブ
   5e50824c55d4df42db4d2987796f0c0b468c273f を複製します
0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002 です
   スロット:[10923-16383] (5461 スロット) マスター
   追加のレプリカ 1 個
36565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001
   スロット:[5461-10922] (5462スロット) マスター
   追加のレプリカ 1 個
[OK] すべてのノードがスロット構成に同意します。
>>> 空きスロットがあるか確認します...
>>> スロットのカバレッジを確認してください...
[OK] 16384 スロットすべてがカバーされました。

7. クラスター情報を表示する

Redis イメージを入力し、redis-cli コマンドを実行します。

-p: Redis に接続するエンドポイントを指定します。

-c: クラスター モードを使用します。

$ docker exec -it redis-7000 redis-cli -p 7000 -c

クラスター情報を表示します。

> クラスター情報
 
クラスター状態:正常
割り当てられたクラスタースロット:16384
クラスタースロットOK:16384
クラスタースロットp失敗:0
クラスタースロット失敗:0
クラスターの既知のノード:6
クラスターサイズ:3
クラスター現在のエポック:6
クラスター_マイ_エポック:1
クラスター統計メッセージping送信:866
クラスター統計メッセージ送信:854
クラスター統計メッセージ送信数:1720
クラスター統計メッセージping受信:849
クラスター統計メッセージ受信数:866
クラスター統計メッセージ会議受信数:5
クラスター統計受信メッセージ:1720

クラスター ノード情報を表示します。

> クラスターノード
 
470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005@17005 スレーブ 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 0 1600267217000 2 台接続
42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003@17003 スレーブ 0cc1aaf960defae7332e9256dd25ee5e5c99e65f 0 1600267218171 3 台接続
ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004@17004 スレーブ 5e50824c55d4df42db4d2987796f0c0b468c273f 0 1600267216161 1 接続済み
0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002@17002 マスター - 0 1600267218070 3 接続 10923-16383
36565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001@17001 マスター - 0 1600267217163 2 接続 5461-10922
5e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000@17000 自分、マスター - 0 1600267217000 1 接続 0-5460

参照アドレス:

http://www.redis.cn/topics/cluster-tutorial.html

http://www.redis.cn/topics/cluster-spec.html

https://jasonkayzk.github.io

https://www.cnblogs.com/kevingrace/p/5685332.html

これで、Docker 経由で Redis 6.x クラスターをデプロイする方法に関するこの記事は終了です。Docker を使用した Redis 6.x クラスターのデプロイの詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。