Redis のマスター/スレーブ レプリケーションの詳細については、こちらをご覧ください。

この記事では、Redis のマスター/スレーブ レプリケーションについて理解し、マスター/スレーブの基本構成、マスター/スレーブ構成の機能と原理を紹介します。

Redis は、マスター/スレーブ レプリケーション機能をサポートしています。これは、slaveof (Redis5 バージョン以降は、replicaof に変更されました) を実行するか、設定ファイルで smileof を設定することによって実行できます (Redis5 バージョン以降、replicaof に変更されました)。 Redis5版）コピー機能をオンにします。 [関連する推奨事項: Redis ビデオ チュートリアル ]

• 1 つのマスターと 2 つのクラスター

• 1 つマスター マルチスレーブ

マスター/スレーブ基本構成

マスター Redis 構成

マスター Redis設定は基本的には必要ありません 変更、重要な部分は Redis 設定からのものです

Redis 設定から

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

2. 関連する構成の変更

# salve的端口号
port 6380 

#把pid进程号写入pidfile配置的文件
pidfile /var/run/redis_6380.pid 

logfile "6380.log"  

#指定数据存放目录
dir /usr/local/redis‐5.0.3/data/6380 

#需要注释掉bind
#bind127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）

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

#从本机master6379的redis实例复制数据，Redis5.0之前使用slaveof
replicaof 192.168.0.60 6379

#配置从节点只读
replica‐read‐only yes

4.スレーブ ノード

redis‐server redis.conf

5. スレーブ ノードを接続します##

redis‐cli ‐p 6380

##6. 6379 インスタンスでのデータの書き込みをテストして、6380 インスタンスができるかどうかを確認します。新しく変更されたデータを適時に同期する

docker run  --name redis-6381 -v /Users/yujiale/docker/redis/conf/redis6381.conf:/etc/redis/redis.conf -v /Users/yujiale/docker/redis/conf/sentinel6381.conf:/etc/redis/sentine.conf -v /Users/yujiale/docker/redis/data6381:/data --network localNetwork --ip 172.172.0.14 -p 16381:6379 -d redis:6.2.6 redis-server /etc/redis/redis.conf --appendonly yes

マスター/スレーブ構成の役割

##読み取りと書き込みの分離

## 1 つのマスターと複数のスレーブ、マスターとスレーブの同期マスターは書き込みを担当し、スレーブは読み取りを担当します

Redis のパフォーマンスとスループットを向上します
• マスターとスレーブのデータ一貫性の問題
• データ障害復旧

スレーブはホストのバックアップですホストがダウンすると、スレーブは読み取りはできますが、書き込みはできません。

デフォルトでは、ホストがダウンすると、ホストはスレーブを使用できなくなります。
• Sentinel はマスター/スレーブ切り替えを実現し、高可用性を実現できます
• Redis マスター/スレーブの動作原理
• マスター/スレーブ レプリケーションの完全なレプリケーション

スレーブ Redis がメイン Redis に初めて接続するときのみ、短期間の再開の場合は、完全コピーまたは部分コピーの可能性があります。

フローチャート

1. メインとの長い Socker 接続を確立します。 Redis

スレーバーはマスターとのソケット接続を確立しますスレーバー関連ファイル イベント プロセッサ

このプロセッサは RDB ファイル (フル コピー) を受け取り、マスターを受け取りますpropagation Coming write コマンド (増分コピー)

マスターサーバーはスレーブサーバーのソケット接続を受け入れた後、対応するクライアントステータスを作成します。これは、スレーブ サーバーがマスター サーバーのクライアントであることに相当します。

#ping コマンドを送信

#スレーバーがマスターに ping コマンドを送信

• 1. ソケットの読み取りおよび書き込みステータスを確認します

  • 2. マスターが正常に処理できるかどうかを確認します

    • マスターの応答:

  1. 正常であることを示す「ポン」を送信します

  • 2. 戻るエラー、マスターが正常ではないことを示します
    3. timeout、ネットワーク タイムアウトを示します

  ##権限検証

マスターとスレーブが正常に接続されたら、権限検証を実行します

マスターがパスワードを設定していません(requirepass="")、スレーブはパスワードを設定する必要はありません (masterauth="" ”)

• マスターはパスワードを設定します (requirepass!="")、スレーブはパスワードを設定する必要があります(masterauth=マスターの requirepass の値)

または、スレーブは認証コマンド

2 を通じてマスターにパスワードを送信します。メイン Redis が PSYNC コマンドを受信します。

#メイン Redis が PSYNC コマンドを受信した後、bgsave コマンドを実行すると、最新の rdb スナップショットが生成されます。

3. マスター Redis は、 rdb スナップショットをスレーブ Redis に送信

マスター Redis が rdb スナップショットをスレーブ Redis に送信すると、マスターは引き続きクライアントのリクエストを受信し、データを変更する可能性のあるリクエスト キャッシュを送信します。セットはメモリ内の relp バッファ キャッシュに保存されます

• 同期スナップショット フェーズ: マスターはスナップショット RDB を作成してスレーブに送信し、スレーブはスナップショットをロードして解析します。マスターは、このフェーズ中に生成された新しい書き込みコマンドもバッファに保存します。

4. ノードから rdb スナップショットを受信します

ノードから rdb スナップショットを受信した後、古いデータをクリアして rdb ファイルをロードします

5. マスター Redis は、バッファ キャッシュ ファイルをスレーブ Redis に送信します。

同期書き込みバッファ ステージ: マスターは、バッファに保存されている書き込み操作コマンドをスレーブに同期します。

#6. ノードからバッファ キャッシュ ファイルを受信します#ノードからバッファ キャッシュ ファイルを受信し、バッファ キャッシュ ファイルをメモリにロードします

7. マスター Redis は、Socker ロング接続を通じてスレーブ ノードにコマンドを継続的に送信します。

#スレーブ Redis は、マスター Redis によって送信されたコマンドを受信し、現在のコマンドを実行します

概要

マスターに対してスレーブを構成すると、スレーブがマスターに初めて接続するかどうかに関係なく、マスターに PSYNC コマンドを送信してコピーを要求します。データ。マスターが PSYNC コマンドを受信した後、バックグラウンドでデータの永続化を実行し、bgsave を通じて最新の RDB スナップショット ファイルを生成します。永続化期間中、マスターはクライアント リクエストを受信し続け、これらのリクエストをキャッシュして、データを変更する可能性があります。メモリに設定されたデータ。永続化が完了すると、マスターはRDBファイルのデータセットをスレーブに送信し、スレーブは受信したデータを永続化してRDBを生成し、メモリにロードします。次に、マスターはメモリに以前にキャッシュされたコマンドをスレーブに送信します。マスターとスレーブ間の接続が何らかの理由で切断された場合、スレーブは自動的にマスターに再接続できます。マスターが複数のスレーブの同時接続要求を受信した場合、接続ごとに 1 回ではなく 1 回だけ持続され、その後送信されます。この永続データを、同時に接続されている複数のスレーブに送信します。

マスター/スレーブ コピーの部分コピー

一般的なプロセスは完全コピーと同様なので、ここでは説明しません。多くの

簡単な説明

マスターとスレーブが切断され、再接続されると、通常、データ全体がコピーされます。ただし、redis バージョン 2.8 以降、redis は部分的なデータ レプリケーションをサポートできるコマンド PSYNC を使用して、マスターとデータを同期します。スレーブとマスターは、ネットワーク接続が切断されて再接続された後にのみ、部分的なデータ レプリケーション (送信の再開) を実行できます。マスターは、メモリ内のデータをコピーするためのキャッシュ キューを作成し、最新期間のデータをキャッシュします。マスターとそのすべてのスレーブは、コピーされたデータの添字オフセットとマスターのプロセス ID を維持します。そのため、ネットワーク接続が切断されると、その後、スレーブはマスターに対して、記録されたデータ インデックスから開始して未完了のレプリケーションを続行するように要求します。マスター プロセス ID が変更された場合、またはスレーブ ノードのデータ オフセットが古すぎてマスターのキャッシュ キューに存在しない場合、完全なデータ コピーが実行されます。マスター/スレーブ レプリケーション (部分レプリケーション、ブレークポイント レジューム) フローチャート:

マスター/スレーブ レプリケーションの増分同期

Redis の増分同期スレーブが初期化を完了し、正常に動作し始めたときに、マスターで発生する書き込み操作がスレーブに同期されるプロセスを指します。

• 通常、マスターが書き込みコマンドを実行するたびに、同じ書き込みコマンドがスレーブに送信され、スレーブはそれを受信して​​実行します。
マスター/スレーブレプリケーションのハートビート検出

1. マスター/スレーブの接続状態を検出

マスターサーバーとスレーブサーバーのネットワーク接続状態を検出します。マスターサーバーにINFOレプリケーションコマンドを送信することで、スレーブサーバーを一覧表示できます。最後のコマンドをマスターサーバーに送信してから何秒経過したかを確認できます。 。ラグの値は 0 または 1 の間で変動する必要があります。1 を超える場合は、マスターとスレーブ間の接続に障害があることを意味します。

2. min-slaves の補助実装

Redis は、メイン サーバーが書き込みコマンド min-slaves-to-write 3 ( min -replicas-to-write 3) min-slaves-max-lag 10 (min-replicas-max-lag 10) 上記の設定は、スレーブ サーバーの数が 3 未満であるか、または 3 つのスレーブ サーバーの遅延 (ラグ) を意味します。 ) 値が 10 秒以上の場合、マスターサーバーは書き込みコマンドの実行を拒否します。ここでの遅延値は、上記の INForeplication コマンドの遅延値です。

3. コマンドロスの検出

マスターサーバーからスレーブサーバーに送信された書き込みコマンドがネットワーク障害により途中で失われてしまうと、スレーブサーバーがREPLCONF をマスターサーバーに送信します ACK コマンドを実行すると、マスターサーバーはスレーブサーバーの現在のレプリケーションオフセットが自身のレプリケーションオフセットよりも小さいことを検出し、マスターサーバーはレプリケーション内のスレーブサーバーの欠落データを見つけます。スレーブ サーバーによって送信されたレプリケーション オフセット データに基づいてバックログ バッファーを作成し、データをスレーブ サーバーに再送信します。 (再発行) ネットワークは継続的に段階的に同期されます。ネットワークが切断され、再度接続されると

完全レプリケーションか部分レプリケーションの判断方法

クライアントが saveof を送信した後、マスターノードは初めてレプリケーションを行うかどうかを決定します。一致する場合は、フル コピーに進みます。一貫性があるかどうかの判断に runid オフセットが使用されない場合は、一貫性がある場合は部分コピーが実行され、そうでない場合はフル コピーが実行されます。

プログラミング関連の知識について詳しくは、プログラミング ビデオをご覧ください。 ！

以上がRedis のマスター/スレーブ レプリケーションの詳細については、こちらをご覧ください。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。