redisプライマリスレーブ同期(replication)詳細
5225 ワード
Replication
Redisは、サーバ(slave server)からプライマリサーバ(master server)への正確なレプリケーションを可能にする簡単で使いやすいプライマリ・スレーブ・レプリケーション機能をサポートします.以下はRedisレプリケーション機能に関するいくつかの重要な側面である:●Redisは非同期レプリケーションを使用する.Redis 2.8から、レプリケーションストリーム(replication stream)の処理の進捗状況は、サーバから1秒に1回の頻度でプライマリサーバに報告されます.・1つのプライマリ・サーバに複数のスレーブ・サーバを持たせることができる.●マスターサーバはスレーブサーバのみならず、スレーブサーバも独自のスレーブサーバを有し、複数のスレーブサーバ間で1つのパターン構造を構成することができる.・レプリケーション機能によってプライマリ・サーバがブロックされることはありません.プライマリ・サーバは、1つ以上のセカンダリ・サーバが初回同期中であってもコマンド要求の処理を継続できます.●コピー機能もスレーブサーバをブロックすることはない:redisであれば.confファイルでは、サーバから初回同期が行われている場合でも、サーバは古いバージョンのデータセットを使用してコマンドクエリーを処理できます.ただし、サーバから古いバージョンのデータセットを削除して新しいバージョンのデータセットをロードする間、接続要求はブロックされます.また、プライマリ・サーバとの接続が切断されたときにクライアントにエラーを送信するようにサーバから構成することもできます.・レプリケーション機能は、単純にデータ冗長性(data redundancy)に使用してもよいし、サーバから読み取り専用コマンド要求を複数処理させることで拡張性(scalability)を向上させることもできる.例えば、煩雑なSORTコマンドは、付属ノードに渡して実行することができる.●機能をコピーすることによって、プライマリ・サーバが永続化操作を実行しないようにすることができる:プライマリ・サーバの永続化機能をオフにしてから、サーバから永続化操作を実行すればよい.
レプリケーション機能の動作原理
初回接続でも再接続でも、スレーブサーバが確立されると、スレーブサーバからSYNCコマンドがプライマリサーバに送信されます.SYNCコマンドを受信したマスターサーバはBGSAVEの実行を開始し、保存操作の実行中に、新しく実行したすべての書き込みコマンドを1つのバッファに保存します.BGSAVEの実行が完了すると、マスターサーバは、保存操作を実行する.rdbファイルはスレーブサーバに送信、これをサーバから受信する.rdbファイルは、ファイル内のデータをメモリにロードします.その後、プライマリ・サーバはRedisコマンド・プロトコルの形式で、書き込みコマンド・バッファに蓄積されたすべてのコンテンツをセカンダリ・サーバに送信します.この同期プロセスをtelnetコマンドで直接検証できます.まず、コマンド要求を処理しているRedisサーバに接続し、SYNCコマンドを送信します.しばらくすると、telnetセッション(session)がサーバから送信された大きなデータ(.rdbファイル)を受信し、サーバで実行されたすべての書き込みコマンドがtelnetセッションに再送信されます.スレーブサーバからSYNCが同時に送信されている複数のスレーブサーバがあっても、スレーブサーバからの同期要求は、1回BGSAVEコマンドを実行するだけですべて処理できる.スレーブ・サーバは、プライマリ・スレーブ・サーバ間の接続が切断されたときに自動的に再接続することができ、Redis 2.8のバージョンの前に、断線後に再接続されたスレーブ・サーバは、常に完全再同期(full resynchronization)操作を実行しなければならないが、Redis 2.8のバージョンから、スレーブ・サーバは、プライマリ・サーバの状況に応じて完全再同期を実行するか、部分再同期を実行するかを選択することができる.
ぶぶんさいどうき
Redis 2.8から、ネットワーク接続が一時的に無効になった後、プライマリスレーブサーバは、完全な再同期操作を実行する必要がなく、既存のレプリケーションプロセス(process)を実行し続けることを試みることができる.この特性は、送信されたレプリケーションストリームのためにプライマリ・サーバがメモリ・バッファ(in-memory backlog)を作成し、プライマリ・サーバとすべてのセカンダリ・サーバとの間にレプリケーション・オフセット量(replication offset)とプライマリ・サーバID(master run id)を記録し、ネットワーク接続が切断されるとサーバから再接続されます.また、元のレプリケーションプロセスの継続をプライマリサーバに要求する:●サーバから記録されたプライマリサーバIDと現在接続するプライマリサーバのIDが同じであり、サーバから記録されたオフセット量で指定されたデータがプライマリサーバのレプリケーションストリームバッファに保存されている場合、プライマリサーバはサーバから断線時に欠落したデータの一部を送信し、レプリケーション作業を継続することができる.●そうでない場合は、サーバから完全な再同期を実行します.Redis 2.8のこの部分再同期特性は、新しいPSYNC内部コマンドを使用するが、Redis 2.8以前の旧バージョンはSYNCコマンドのみであったが、サーバがRedis 2.8以上であれば、プライマリサーバのバージョンに基づいてPSYNCを使用するかSYNCを使用するかを決定する.●プライマリサーバがRedis 2.8以上であれば、では、サーバからPSYNCコマンドを使用して同期を行います.・プライマリ・サーバがRedis 2.8以前のバージョンである場合、スレーブ・サーバはSYNCコマンドを使用して同期する.
コンフィギュレーション
サーバからの構成は非常に簡単です.プロファイルに次の行を追加すればいいです.
もちろん、コードの192.168.1.1と6379をプライマリサーバのIPとポート番号に置き換える必要があります.もう1つの方法は、SLAVEOFコマンドを呼び出し、プライマリサーバのIPとポートを入力して同期を開始することです.
読み取り専用サーバー
Redis 2.6からは、サーバから読み取り専用モードがサポートされ、このモードはサーバからのデフォルトモードである.読み取り専用モードはredis.confファイルのslave-read-onlyオプション制御は、CONFIGSETコマンドでこのモードをオンまたはオフにすることもできます.読み取り専用スレーブサーバは、書き込みコマンドの実行を拒否するため、操作ミスでスレーブサーバにデータが誤って書き込まれることはありません.サーバから読み取り専用であっても、DEBUGやCONFIGなどの管理命令は使用可能であるため、サーバをインターネットや信頼できないネットワークに暴露するべきではありません.ただし、redisを使用します.confのコマンド改名オプションでは、一部のコマンドの実行を禁止することで、読み取り専用サーバのセキュリティを向上させることができます.サーバからの書き込みデータが再同期データで上書きされ、サーバからの再起動時に失われる可能性がある以上、なぜサーバから書き込み可能にするのか、気になるかもしれません.なぜなら、重要でない一時的なデータは、サーバから保存できるからです.例えば、クライアントは、プライマリサーバの到達可能性情報をサーバから保存し、フェイルオーバポリシーを実現することができる.
サーバ関連の構成
プライマリ・サーバがrequirepassオプションでパスワードを設定している場合は、サーバからの同期操作を円滑に行うために、サーバからの認証設定も必要です.実行中のサーバの場合、クライアントを使用して次のコマンドを入力できます.
このパスワードを永続的に設定するには、プロファイルに追加します.
また、プライマリサーバが部分再同期を実行する際に使用するレプリケーションストリームバッファに関するいくつかのオプションがあり、詳細はRedisソースコードに付属するredisを参照することができる.confサンプルファイル.
プライマリ・サーバは、少なくともN個のスレーブ・サーバの場合に書き込みを実行する
Redis 2.8から、データのセキュリティを確保するために、プライマリ・サーバが現在接続されているサーバが少なくともN個ある場合にのみ書き込みコマンドを実行するように構成することができる.ただし、Redisは非同期レプリケーションを使用するため、プライマリサーバから送信された書き込みデータがサーバから受信されるとは限らないため、データが失われる可能性は依然として存在する.以下はこの特性の動作原理である:●サーバから毎秒1回の周波数PINGプライマリサーバで1回、レプリケーションストリームの処理状況を報告する.●プライマリサーバは、サーバから最後にPINGが送信された時刻を記録します.・ユーザは、ネットワーク遅延の最大min-slaves-max-lagを設定することによって指定し、書き込み操作を実行するために必要な少なくともサーバ数min-slaves-to-writeを指定することができる.少なくともmin-slaves-to-write個のスレーブサーバがあり、これらのサーバの遅延値がmin-slaves-max-lag秒よりも少ない場合、プライマリサーバはクライアント要求の書き込み操作を実行します.この特性をCAP理論のCの条件緩和バージョンと見なすことができます.書き込み操作の持続性は保証されませんが、少なくともデータを失ったウィンドウは指定された秒数に厳しく制限されます.一方、条件がmin-slaves-to-writeおよびmin-slaves-max-lagで指定された条件に達しない場合、書き込み操作は実行されず、プライマリサーバは書き込み操作を要求するクライアントにエラーを返します.以下はこの特性の2つのオプションとそれらに必要なパラメータである:●min-slaves-to-write●min-slaves-max-lagの詳細はRedisソースコードに付属するredisを参照することができる.confサンプルファイル.
Redisは、サーバ(slave server)からプライマリサーバ(master server)への正確なレプリケーションを可能にする簡単で使いやすいプライマリ・スレーブ・レプリケーション機能をサポートします.以下はRedisレプリケーション機能に関するいくつかの重要な側面である:●Redisは非同期レプリケーションを使用する.Redis 2.8から、レプリケーションストリーム(replication stream)の処理の進捗状況は、サーバから1秒に1回の頻度でプライマリサーバに報告されます.・1つのプライマリ・サーバに複数のスレーブ・サーバを持たせることができる.●マスターサーバはスレーブサーバのみならず、スレーブサーバも独自のスレーブサーバを有し、複数のスレーブサーバ間で1つのパターン構造を構成することができる.・レプリケーション機能によってプライマリ・サーバがブロックされることはありません.プライマリ・サーバは、1つ以上のセカンダリ・サーバが初回同期中であってもコマンド要求の処理を継続できます.●コピー機能もスレーブサーバをブロックすることはない:redisであれば.confファイルでは、サーバから初回同期が行われている場合でも、サーバは古いバージョンのデータセットを使用してコマンドクエリーを処理できます.ただし、サーバから古いバージョンのデータセットを削除して新しいバージョンのデータセットをロードする間、接続要求はブロックされます.また、プライマリ・サーバとの接続が切断されたときにクライアントにエラーを送信するようにサーバから構成することもできます.・レプリケーション機能は、単純にデータ冗長性(data redundancy)に使用してもよいし、サーバから読み取り専用コマンド要求を複数処理させることで拡張性(scalability)を向上させることもできる.例えば、煩雑なSORTコマンドは、付属ノードに渡して実行することができる.●機能をコピーすることによって、プライマリ・サーバが永続化操作を実行しないようにすることができる:プライマリ・サーバの永続化機能をオフにしてから、サーバから永続化操作を実行すればよい.
レプリケーション機能の動作原理
初回接続でも再接続でも、スレーブサーバが確立されると、スレーブサーバからSYNCコマンドがプライマリサーバに送信されます.SYNCコマンドを受信したマスターサーバはBGSAVEの実行を開始し、保存操作の実行中に、新しく実行したすべての書き込みコマンドを1つのバッファに保存します.BGSAVEの実行が完了すると、マスターサーバは、保存操作を実行する.rdbファイルはスレーブサーバに送信、これをサーバから受信する.rdbファイルは、ファイル内のデータをメモリにロードします.その後、プライマリ・サーバはRedisコマンド・プロトコルの形式で、書き込みコマンド・バッファに蓄積されたすべてのコンテンツをセカンダリ・サーバに送信します.この同期プロセスをtelnetコマンドで直接検証できます.まず、コマンド要求を処理しているRedisサーバに接続し、SYNCコマンドを送信します.しばらくすると、telnetセッション(session)がサーバから送信された大きなデータ(.rdbファイル)を受信し、サーバで実行されたすべての書き込みコマンドがtelnetセッションに再送信されます.スレーブサーバからSYNCが同時に送信されている複数のスレーブサーバがあっても、スレーブサーバからの同期要求は、1回BGSAVEコマンドを実行するだけですべて処理できる.スレーブ・サーバは、プライマリ・スレーブ・サーバ間の接続が切断されたときに自動的に再接続することができ、Redis 2.8のバージョンの前に、断線後に再接続されたスレーブ・サーバは、常に完全再同期(full resynchronization)操作を実行しなければならないが、Redis 2.8のバージョンから、スレーブ・サーバは、プライマリ・サーバの状況に応じて完全再同期を実行するか、部分再同期を実行するかを選択することができる.
ぶぶんさいどうき
Redis 2.8から、ネットワーク接続が一時的に無効になった後、プライマリスレーブサーバは、完全な再同期操作を実行する必要がなく、既存のレプリケーションプロセス(process)を実行し続けることを試みることができる.この特性は、送信されたレプリケーションストリームのためにプライマリ・サーバがメモリ・バッファ(in-memory backlog)を作成し、プライマリ・サーバとすべてのセカンダリ・サーバとの間にレプリケーション・オフセット量(replication offset)とプライマリ・サーバID(master run id)を記録し、ネットワーク接続が切断されるとサーバから再接続されます.また、元のレプリケーションプロセスの継続をプライマリサーバに要求する:●サーバから記録されたプライマリサーバIDと現在接続するプライマリサーバのIDが同じであり、サーバから記録されたオフセット量で指定されたデータがプライマリサーバのレプリケーションストリームバッファに保存されている場合、プライマリサーバはサーバから断線時に欠落したデータの一部を送信し、レプリケーション作業を継続することができる.●そうでない場合は、サーバから完全な再同期を実行します.Redis 2.8のこの部分再同期特性は、新しいPSYNC内部コマンドを使用するが、Redis 2.8以前の旧バージョンはSYNCコマンドのみであったが、サーバがRedis 2.8以上であれば、プライマリサーバのバージョンに基づいてPSYNCを使用するかSYNCを使用するかを決定する.●プライマリサーバがRedis 2.8以上であれば、では、サーバからPSYNCコマンドを使用して同期を行います.・プライマリ・サーバがRedis 2.8以前のバージョンである場合、スレーブ・サーバはSYNCコマンドを使用して同期する.
コンフィギュレーション
サーバからの構成は非常に簡単です.プロファイルに次の行を追加すればいいです.
slaveof 192.168.1.1 6379もちろん、コードの192.168.1.1と6379をプライマリサーバのIPとポート番号に置き換える必要があります.もう1つの方法は、SLAVEOFコマンドを呼び出し、プライマリサーバのIPとポートを入力して同期を開始することです.
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK読み取り専用サーバー
Redis 2.6からは、サーバから読み取り専用モードがサポートされ、このモードはサーバからのデフォルトモードである.読み取り専用モードはredis.confファイルのslave-read-onlyオプション制御は、CONFIGSETコマンドでこのモードをオンまたはオフにすることもできます.読み取り専用スレーブサーバは、書き込みコマンドの実行を拒否するため、操作ミスでスレーブサーバにデータが誤って書き込まれることはありません.サーバから読み取り専用であっても、DEBUGやCONFIGなどの管理命令は使用可能であるため、サーバをインターネットや信頼できないネットワークに暴露するべきではありません.ただし、redisを使用します.confのコマンド改名オプションでは、一部のコマンドの実行を禁止することで、読み取り専用サーバのセキュリティを向上させることができます.サーバからの書き込みデータが再同期データで上書きされ、サーバからの再起動時に失われる可能性がある以上、なぜサーバから書き込み可能にするのか、気になるかもしれません.なぜなら、重要でない一時的なデータは、サーバから保存できるからです.例えば、クライアントは、プライマリサーバの到達可能性情報をサーバから保存し、フェイルオーバポリシーを実現することができる.
サーバ関連の構成
プライマリ・サーバがrequirepassオプションでパスワードを設定している場合は、サーバからの同期操作を円滑に行うために、サーバからの認証設定も必要です.実行中のサーバの場合、クライアントを使用して次のコマンドを入力できます.
config set masterauth このパスワードを永続的に設定するには、プロファイルに追加します.
masterauth <password>また、プライマリサーバが部分再同期を実行する際に使用するレプリケーションストリームバッファに関するいくつかのオプションがあり、詳細はRedisソースコードに付属するredisを参照することができる.confサンプルファイル.
プライマリ・サーバは、少なくともN個のスレーブ・サーバの場合に書き込みを実行する
Redis 2.8から、データのセキュリティを確保するために、プライマリ・サーバが現在接続されているサーバが少なくともN個ある場合にのみ書き込みコマンドを実行するように構成することができる.ただし、Redisは非同期レプリケーションを使用するため、プライマリサーバから送信された書き込みデータがサーバから受信されるとは限らないため、データが失われる可能性は依然として存在する.以下はこの特性の動作原理である:●サーバから毎秒1回の周波数PINGプライマリサーバで1回、レプリケーションストリームの処理状況を報告する.●プライマリサーバは、サーバから最後にPINGが送信された時刻を記録します.・ユーザは、ネットワーク遅延の最大min-slaves-max-lagを設定することによって指定し、書き込み操作を実行するために必要な少なくともサーバ数min-slaves-to-writeを指定することができる.少なくともmin-slaves-to-write個のスレーブサーバがあり、これらのサーバの遅延値がmin-slaves-max-lag秒よりも少ない場合、プライマリサーバはクライアント要求の書き込み操作を実行します.この特性をCAP理論のCの条件緩和バージョンと見なすことができます.書き込み操作の持続性は保証されませんが、少なくともデータを失ったウィンドウは指定された秒数に厳しく制限されます.一方、条件がmin-slaves-to-writeおよびmin-slaves-max-lagで指定された条件に達しない場合、書き込み操作は実行されず、プライマリサーバは書き込み操作を要求するクライアントにエラーを返します.以下はこの特性の2つのオプションとそれらに必要なパラメータである:●min-slaves-to-write●min-slaves-max-lagの詳細はRedisソースコードに付属するredisを参照することができる.confサンプルファイル.