多くの友人がすでにマスター/スレーブ レプリケーションを構成していると思いますが、Redis のマスター/スレーブ レプリケーションのワークフローと一般的な問題については深く理解していません。今回、Kaka は 2 日間を費やして、Redis のマスター/スレーブ レプリケーションに関するすべてのナレッジ ポイントをまとめました。

#この記事を実装するために必要な環境

centos7.0

redis4.0

1. Redis のマスター/スレーブ レプリケーションとは何ですか?

マスター/スレーブ レプリケーションとは、2 つの Redis サーバーが存在し、1 つの Redis のデータがもう 1 つの Redis データベースに同期されることを意味します。前者をマスターノード、後者をスレーブノードと呼びます。データはマスターからスレーブへの一方向でのみ同期できます。

しかし、実際のプロセスでは、マスター/スレーブ レプリケーションに 2 つの Redis サーバーのみを使用することは不可能です。つまり、各 Redis サーバーはマスター ノード (マスター) と呼ばれる可能性があります。 )

#以下の場合、スレーブ 3 はマスターのスレーブ ノードであり、スレーブのマスター ノードでもあります。

まずこの概念を理解してから、以下の詳細な説明を読み続けてください。

2. Redis のマスター/スレーブ レプリケーションが必要な理由は何ですか?

現在、スタンドアロン状態の Redis サーバーがあると仮定します。

この場合に発生する最初の問題はサーバーのダウンタイムであり、これはデータ損失に直接つながります。プロジェクトが人民元に関連している場合、その結果は想像できます。

#2 番目の状況はメモリの問題です。サーバーが 1 台しかない場合、メモリは確実にピークに達します。1 台のサーバーを無限にアップグレードすることは不可能です。

そこで、上記 2 つの問題に対応して、さらにいくつかのサーバーを用意し、マスター/スレーブ レプリケーションを構成します。データを複数のサーバーに保存します。また、各サーバーのデータが同期されていることを確認します。万が一サーバーがダウンしてもユーザーの利用に影響はありません。 Redis は、データの高可用性と冗長バックアップを引き続き実現できます。

マスターとスレーブをどのように接続するか?この時点で多くの質問があるはずです。データを同期するにはどうすればよいですか?マスターサーバーがダウンしたらどうなるでしょうか?心配しないで、少しずつ問題を解決してください。

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

Redis のマスター/スレーブ レプリケーションを使用する理由については上で説明しました。そのため、マスター/スレーブ レプリケーションの役割は、それが使用される理由を説明することです。

引き続きこの図を使ってお話しします。
1. 最初のポイントは、データのホット バックアップと永続性を実現するデータの冗長性です。方法。
2. 2 番目のポイントは、単一マシンの障害についてです。マスターノードに障害が発生した場合、従属であるスレーブノードがサービスを提供することで、障害からの迅速な復旧を実現するサービスの冗長化を実現します。
3. 3 番目のポイントは読み取りと書き込みの分離で、マスター サーバーは主に書き込みに使用され、スレーブは主にデータの読み取りに使用され、サーバーの負荷容量を向上させることができます。同時に、需要の変化に応じてスレーブノードの数を追加することができます。
4. 4 番目のポイントは負荷分散であり、読み取りと書き込みの分離と併せて、マスター ノードが書き込みサービスを提供し、スレーブ ノードが読み取りサービスを提供することでサーバーの負荷を分散します。複数のスレーブ ノードを介したより多くの読み取り 読み取り負荷を共有すると、Redis サーバーの同時実行性と負荷が大幅に増加する可能性があります。
5. 5 番目のポイントは高可用性の基礎です。マスター/スレーブ レプリケーションはセンチネルとクラスターの実装の基礎であるため、マスター/スレーブ レプリケーションは高可用性の基礎であると言えます。

##4. Redis のマスター/スレーブ レプリケーションを構成する

となります。そうは言っても、まずマスター/スレーブ レプリケーションのケースを簡単に構成してから、実装の原則について説明します。

#Redis ストレージ パスは次のとおりです: usr/local/redis

ログ ファイルと構成ファイルは次の場所に保存されます。 usr/local /redis/data

最初に、redis6379.conf と redis6380.conf という 2 つの構成ファイルを構成します

構成ファイルを変更します。主にポートを変更します。表示しやすいように、ログ ファイルと永続ファイルの名前はそれぞれのポートで識別されます。

次に、2 つの Redis サービスを開きます。1 つはポート 6379 で、もう 1 つはポート 6380 です。コマンドredis-server redis6380.confを実行し、redis-cli -p 6380を使用して接続します。redis のデフォルトのポートは 6379 であるため、別の redis サーバーを起動して、直接redis-server redis6379.conf次に、redis-cliを使用して直接接続します。

現時点では、2 つの Redis サービス (1 つは 6380 用、もう 1 つは 6379 用) が正常に構成されました。これは単なるデモンストレーションです。実際の作業では、2 つの異なるサーバー上で構成する必要があります。

#1. クライアント コマンド ラインの使用を開始します

まず概念を理解する必要があります。つまり、マスター/スレーブ レプリケーションを構成する場合、すべての操作はスレーブ ノード、つまりスレーブで実行されるということです。

次に、スレーブ ノードで

slaveof 127.0.0.1 6379としてコマンドを実行します。実行後、接続されたことを意味します。

# まず、マスター/スレーブ レプリケーションが実現されるかどうかをテストしてみましょう。マスター サーバー上で 2 つの

set kaka 123 と set master 127.0.0.1を実行すると、slave6380 ポートが正常に取得できます。これは、マスター/スレーブ レプリケーションが構成されたことを意味します。ただし、運用環境の実装で終わりではなく、その後、高可用性が達成されるまでマスター/スレーブ レプリケーションがさらに最適化されます。

2. 構成ファイルを使用して

# を有効にします

##構成ファイルを使用してマスター/スレーブ レプリケーションを開始する前に!まず、クライアント コマンド ラインを使用して以前の接続を切断し、スレーブ ホストで

slaveof no oneを実行してマスター/スレーブ レプリケーションを切断する必要があります。

#スレーブ ノードがマスター ノードから切断されたことはどこで確認できますか。マスター ノードのクライアントでコマンド ライン

info

を入力して、

を表示します。

この図は、クライアント コマンド ラインを使用してスレーブ ノードを使用してマスター ノードに接続した後、マスター ノードのクライアントでinfoと入力して出力された情報を示しています。スレーブ0に関する情報。

この画像は、スレーブ ノードがslaveof no oneinfoを実行した後、マスター ノードに印刷されます。 、スレーブ ノードがマスター ノードから切断されたことを示します。

#構成ファイル

redis-server redis6380.conf

# に従って Redis サービスを開始します。

##スレーブ ノードが再起動されると、マスター ノードでスレーブ ノードの接続情報を直接表示できます。

# テスト データ、マスター ノードによって書き込まれたものは、スレーブ ノードによって自動的に同期されます。

#3. Redis サーバー起動時に開始

この設定方法も非常に簡単で、redis サーバーを起動するときにマスター/スレーブ レプリケーションを直接開始し、コマンド

redis-server --slaveof host portを実行します。

4. マスタ・スレーブレプリケーション開始後のログ情報の確認

これは、マスタ/スレーブレプリケーション開始後のログ情報です。マスターノード

#これは、マスターノードとRDBスナップショットストレージの接続情報を含むスレーブノードの情報です。

##5. マスター/スレーブ レプリケーションの動作原理

1. マスター/スレーブ レプリケーションの 3 つの段階

マスター/スレーブ レプリケーションの完全なワークフローは、次の 3 つの段階に分かれています。各セグメントには独自の内部ワークフローがあるため、3 つのプロセス プロセスについて説明します。

• 接続確立プロセス: スレーブをマスターに接続するプロセスです。
• データ同期プロセス: マスターがスレーブにデータを同期するプロセスです。
• コマンド伝播プロセス:データの同期を繰り返します
  

#2.フェーズ1：接続確立処理

##上の図は、完全なマスター/スレーブ レプリケーション接続確立ワークフローです。次に、短い言葉を使って上記のワークフローを説明します。

#マスターのアドレスとポートを設定し、マスターの情報を保存します

1. ソケット接続を確立します (この接続が何を行うかについては後述します)
2. ping コマンドの送信を続行
3. 認証
4. スレーブ ポート情報の送信

接続を確立するプロセス中に、スレーブ ノードはマスターのアドレスとポートを保存し、マスター ノード マスターはスレーブ ノード スレーブのポートを保存します。

#3. フェーズ 2: データ同期フェーズのプロセス

この図では、スレーブ ノードがマスター ノードに初めて接続するときのデータ同期プロセスを詳しく説明します。

#スレーブ ノードが初めてマスター ノードに接続すると、最初にフル コピーが実行されますが、このフル コピーは避けられません。

完全レプリケーションが完了すると、マスター ノードはレプリケーション バックログ バッファ内のデータを送信し、スレーブ ノードは bgrewriteaof を実行してデータを復元します。部分的なレプリケーションも可能です。

この段階では、完全コピー、部分コピー、およびコピー バッファ バックログという 3 つの新しい点について説明します。これらの点については、以下の FAQ で詳しく説明します。

4. 第三段階: コマンド伝播段階

マスター データベースが変更され、マスター サーバーとスレーブ サーバーのデータが不整合になった場合、マスターとスレーブのデータが同期されて一貫性が保たれます。このプロセスはコマンド伝播と呼ばれます。

#マスタは受信したデータ変更コマンドをスレーブに送信し、スレーブはコマンド受信後にコマンドを実行してマスタとスレーブのデータを整合させます。

コマンド伝播フェーズ中の部分レプリケーション

• コマンド中に発生します伝播フェーズ ネットワークが切断されたり、ネットワークがジッターした場合、接続が失われます (コネクションロスト)
• このとき、マスターノードのマスターは replbackbuffer (レプリケーションバッファのバックログ領域) にデータを書き込み続けます
• スレーブ ノードはマスターへの接続を試行し続けます
• スレーブ ノードが runid とレプリケーション オフセットをマスター ノードに送信し、pysnc コマンドを実行して同期するとき
• マスターがオフセットがコピー バッファ範囲内であると判断した場合は、Continue コマンドが返されます。そして、コピーバッファ内のデータをスレーブノードに送信します。
• スレーブ ノードからデータを受信し、bgrewriteaof を実行してデータを復元します

6. マスター/スレーブ レプリケーションの原理の詳細な紹介 (完全レプリケーションと部分レプリケーション)

このプロセスは、マスター/スレーブ レプリケーションの最も完全なプロセスの説明です。それでは、プロセスの各ステップを簡単に紹介しましょう###

1. ノードから命令を送信psync ? 1 pync runid offsetデータを要求するために対応するrunidを見つけます。ただし、ここでは、スレーブ ノードが初めて接続するとき、マスター ノードのrunid と offsetをまったく知らないと考えることができます。最初に送信されるコマンドはpsync ですか? 1は、マスターノードのすべてのデータが必要であることを意味します。
2. マスター ノードは、RDB ファイルを生成し、現在のレプリケーション オフセット オフセットを記録するために bgsave の実行を開始します。
3. この時点で、マスター ノードは、FULLRESYNC runid オフセットを通じて独自の runid とオフセットを送信します。 RDB ファイルをソケット経由でスレーブ ノードに送信するコマンド。
4. スレーブ ノードは FULLRESYNC を受信し、マスター ノードの runid とオフセットを保存した後、現在のデータをすべてクリアし、ソケット経由で RDB ファイルを受信し、RDB データの復元を開始します。
5. 完全レプリケーション後、スレーブ ノードはマスター ノードの runid とオフセットを取得し、命令の送信を開始します。psync runid offset
6. マスター ノードは命令を受信し、 runid が一致するかどうかを決定し、オフセットがコピー バッファー内にあるかどうかを決定します。
7. マスター ノードは、runid と offset のいずれかが満たされていないと判断し、ステップ2に戻って完全レプリケーションの実行を続行します。ここでの runid の不一致は、スレーブ ノードの再起動によってのみ発生する可能性があります。この問題は後で解決されます。オフセット (オフセット) の不一致は、レプリケーション バックログ バッファ オーバーフローによって発生します。 runid または offset チェックに合格し、スレーブ ノードのオフセットがマスター ノードのオフセットと同じである場合、そのオフセットは無視されます。 runid または offset チェックに合格し、スレーブ ノードのオフセットがオフセットと異なる場合、CONTINUE offset (このオフセットはマスター ノードに属します) が送信され、スレーブ ノードのオフセットからマスター ノードのオフセットへのデータが送信されます。レプリケーション バッファはソケット経由で送信されます。
8. ノードから CONTINUE を受信し、マスターのオフセットを保存し、ソケット経由で情報を受信後、bgrewriteaof を実行してデータを復元します。

1 ～ 4 は完全コピー、5 ～ 8 は部分コピー

マスター ノードのステップ 3 では、マスター ノードはマスター/スレーブ レプリケーション期間中にクライアント データを受信しており、マスター ノードのオフセットが変化しています。変更のみが各スレーブに送信されます。この送信プロセスはハートビート メカニズムと呼ばれます

7. ハートビートの仕組み

コマンド伝播段階では、マスターノードとスレーブノードは常に情報を交換する必要があります。メンテナンス用のハートビート メカニズムを切り替えて使用し、マスター ノードとスレーブ ノード間の接続をオンラインに保ちます。

• マスター ハートビート

• コマンド: ping
• デフォルトは 10 秒に 1 回ですこれは、パラメータ repl-ping-slave-period によって決定されます。
• 主な目的は、スレーブ ノードがオンラインかどうかを判断することです。
• 情報レプリケーションを使用して、間隔を確認できます。スレーブノードをレンタルしてからの接続時間、ラグが0または1であれば正常な状態です。

• スレーブ ハートビート タスク

• コマンド: replconf ack {offset}
• 1 秒に 1 回実行
• 主な動作は、独自のレプリケーション オフセットをマスター ノードに送信し、マスター ノードから最新のデータ変更コマンドを取得し、マスター ノードがオンラインかどうかを判断することです。

#ハートビート フェーズに関する注意事項

データの安定性を確保するために、マスター ノードはドロップ数または遅延が大きすぎます。すべての情報の同期は拒否されます。

構成調整には 2 つのパラメータがあります:

min-slaves-to-write 2

min-slaves-max-lag 8

これ2 つのパラメーターは、スレーブ ノードが 2 つだけ残っていること、またはスレーブ ノードの遅延が 8 秒を超える場合、マスター ノードはマスター機能を強制的にオフにしてデータ同期を停止することを示します。

#それでは、マスター ノードがハングアップしたスレーブ ノードのデータと遅延時間を知っている場合はどうなるでしょうか。ハートビート メカニズムでは、スレーブは perlconf ack コマンドを毎秒送信します。このコマンドには、オフセット、スレーブ ノードの遅延時間、およびスレーブ ノードの数が含まれます。

8. 部分レプリケーションの 3 つのコア要素

1. サーバーの実行 ID (実行 ID)

まず、この実行 ID が何であるかを見てみましょう。info コマンドを実行すると確認できます。上記の起動ログ情報を見ると、このこともわかります。

#

Redis は起動時にランダム ID を自動的に生成します (ID は起動するたびに異なることに注意してください)。これは 40 個のランダムな 16 進文字列で構成され、Redis ノードを一意に識別するために使用されます。 。

マスター/スレーブ レプリケーションが最初に開始されると、マスターはその runid をスレーブに送信し、スレーブはマスターの id を保存します。info コマンドを使用できます。表示するには

切断して再接続すると、スレーブはこの ID をマスターに送信し、スレーブによって保存された runid がマスターの現在の runid と同じである場合、マスターは部分レプリケーションの使用を試みます (このブロックを正常にコピーできるかどうかのもう 1 つの要素はオフセットです)。スレーブによって保存された runid がマスターの現在の runid と異なる場合、完全コピーが直接実行されます。

2. コピー バックログ バッファ

コピー バッファ バックログは先入れ先出しキューです。ユーザーストレージ データを収集するためのマスターコマンドレコード。コピーバッファのデフォルトのストレージ容量は 1M です。

設定ファイルのrepl-backlog-size 1mbを変更してバッファ サイズを制御できます。この比率は独自のサーバーに応じて変更できます。ここでは約 30% が予約されています。

コピー バッファには正確に何が格納されているのでしょうか?

コマンドをset name kakaとして実行すると、永続化ファイルを表示して

を表示できます。

この場合、コピー バックログ バッファーは、バイトごとに区切られた永続データが保存されたものであり、各バイトには独自のオフセットがあります。このオフセットはコピー オフセット (オフセット) でもあります。

#では、なぜコピー バッファーのバックログによって全量コピーが発生する可能性があると言われるのでしょうか。それ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

コマンド伝播フェーズでは、マスター ノードは収集したデータをレプリケーション バッファに保存し、それをスレーブ ノードに送信します。ここで問題が発生し、マスターノード上のデータ量が瞬間的に非常に多くなり、レプリケーションバッファのメモリを超えると、一部のデータが圧迫され、マスターノードとスレーブ間でデータの不整合が発生します。ノード。完全なコピーを作成するには。バッファサイズが適切に設定されていない場合、スレーブノードは常にフルコピー、データクリア、フルコピーを繰り返す無限ループを引き起こす可能性があります。

#3. オフセットのコピー

マスターノードのレプリケーションオフセットは、スレーブノードにレコードを 1 回送信し、スレーブノードはレコードを 1 回受信します。

は、情報を同期し、マスター ノードとスレーブ ノードの違いを比較し、スレーブが切断されたときにデータ使用量を復元するために使用されます。

#この値は、コピー バッファー バックログからのオフセットです。

#9. マスター/スレーブ レプリケーションに関する一般的な問題

##1. マスター ノードの再起動の問題 (内部最適化)

マスター ノードが再起動すると、runid の値が変更され、すべてのスレーブ ノードで完全なレプリケーションが実行されます。

この問題を考慮する必要はありません。システムがどのように最適化されるかを知る必要があるだけです。

マスター/スレーブ レプリケーションが確立された後、マスター ノードはマスター レプリッド変数を作成します。生成された戦略は runid と同じで、長さは 41 です。ビットと 40 ビットの runid 長を持ち、スレーブ ノードに送信されます。

マスターノードで shutdown save コマンドを実行すると、RDB 永続化が実行され、runid と offset が RDB ファイルに保存されます。コマンド redis-check-rdb を使用して、この情報を表示できます。

#マスターノードの再起動後に RDB ファイルをロードし、repl-id と repl-offset をロードします。ファイルをメモリに保存します。すべてのスレーブ ノードが以前のマスター ノードであるとみなされる場合でも。

2. スレーブ ノードのネットワーク割り込みオフセットが境界を越えたため、完全なレプリケーションが発生しました。

ネットワーク環境が悪いため、スレーブ ノード ノード ネットワークの停止。レプリケーション バックログ バッファ メモリが小さすぎるため、データ オーバーフローが発生します。スレーブ ノード オフセットが境界を越えると、完全レプリケーションが発生します。これにより、完全なコピーが繰り返される可能性があります。

解決策: レプリケーション バックログ バッファーのサイズを変更します: repl-backlog-size

セットアップの推奨事項: マスター ノードをテストします。スレーブノードの接続時間、1秒あたりにマスターノードが生成するコマンドの平均総数を取得します write_size_per_second

コピーバッファスペースの設定 = 2マスター-スレーブ接続時間マスター 1 秒あたりにノードによって生成されるデータの合計量

#3. 頻繁なネットワーク中断

メインノードのCPUが原因 占有率が高すぎるか、スレーブノードが頻繁に接続されています。この状況の結果、バッファ、帯域幅、接続などを含む (ただしこれらに限定されない)、マスター ノードのさまざまなリソースが大幅に占有されます。

マスター ノードのリソースが大幅に占有されるのはなぜですか?

#ハートビート メカニズムでは、スレーブ ノードはコマンド replconf ack コマンドをマスター ノードに毎秒送信します。

スレーブ ノードは低速なクエリを実行し、大量の CPU を占有しました。

マスター ノードはレプリケーション タイミング関数 replicationCron を 1 秒ごとに呼び出しましたが、スレーブ ノードは長時間応答しませんでした。 。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃解決：＃＃＃＃＃＃＃＃＃＃＃＃

スレーブ ノードのタイムアウト リリースを設定します

パラメータを設定します: repl-timeout

このパラメータのデフォルトは 60 秒です。 60 秒後、スレーブを解放します。

4. データの不整合の問題

ネットワーク要因により、複数のスレーブ ノードのデータが不整合になります。この要因を回避する方法はありません。

この問題には 2 つの解決策があります:

最初のデータは、高度な設定を使用して構成する必要があります。一貫性 Redis サーバーは読み取りと書き込みの両方に 1 つのサーバーを使用します。この方法は少量のデータに限定されており、データの一貫性が高い必要があります。

2 番目はマスター/スレーブ ノードのオフセットを監視し、スレーブ ノードの遅延が大きすぎる場合、クライアントのスレーブ ノードへのアクセスは一時的にブロックされます。パラメータをslave-serve-stale-data yes|noに設定します。このパラメータが設定されると、info smileof などのいくつかのコマンドにのみ応答できるようになります。

#10. 概要

この記事では主にマスター/スレーブ レプリケーションとは何か、マスターの 3 つの主要な側面について説明します。 -slave replication: ステージ、ワークフロー、および部分レプリケーションの 3 つのコア コンポーネント。コマンド伝播フェーズ中のハートビート メカニズム。最後に、マスター/スレーブ レプリケーションに関する一般的な問題について説明します。

以上がRedis のマスター/スレーブ レプリケーションの動作原理と一般的な問題の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。