Redisのレプリケーション（Redisの多機能機の記事）

コピー

拡張読み出し要求システム容量、およびシステムの可用性を向上させ
、同じデータベース・サーバのコピーを作成

Redisのレプリケーション（複製）機能、ユーザはRedisのサーバーに基づいて、サーバの任意の数のコピーを作成することができ、サーバは、（マスターは（マスター）にコピーされ、レプリカをコピーすることによって、サーバからサーバから作成した請求スレーブ）。
主は、データベース・サーバの両方から同じデータを持っている：としては、限り、通常のネットワーク・サーバとの間の主な接続から、プライマリサーバは、サーバから同じデータの主な保証されているサーバーからデータの更新を同期させるためにそれらに起こることがあります。
ここに画像を挿入説明
左は、サーバーからマスターサーバーを持って示しています。
それは右のショープライマリサーバサーバからの3を持っています。

リクエストを処理するために、サーバからのリードコマンドを使用します

Redisのは、GET、LRANGE、SMEMBERS、HGETとして、読み取りコマンドは、サーバーからクライアントから送信されたことができますZRANGEのように。

プライマリ・データベース・サーバから同一のデータを有しているので、マスターサーバからの結果、クライアントによって送信されたリードコマンドを実行するリードコマンドにより得られた同一の実行結果を取得することと同じです。したがって、ユーザは、読み出しコマンドサーバプロセスに要求することにより、リードコマンド要求を処理する際に、プライマリサーバの負荷を軽減するマスターサーバプロセス（あるいは全て）により元の電荷の一部であっても、システム全体の容量は、コマンド要求を読み取る延びていてもよいです。
ここに画像を挿入説明

読み取り要求を処理コピーしてシステムを拡張する機能

システム全体を追加することにより直線的に拡張することができる処理能力は、サーバからのコマンド要求をお読みください。

以下の表に示す同一の条件でサーバからの主要なハードウェアの数との関係は、サーバシステムからのリードコマンドの数は、要求を処理することができます。
ここに画像を挿入説明

サーバーの作成と使用から

使用SLAVEOFコマンドまたはオプションslaveof

サーバーからのメソッドを作成します。

Redisのは、マスターサーバーからサーバーを作成する2つの方法が用意されています。

使用 SLAVEOF 命令，比如向一个服务器发送 SLAVEOF 127.0.0.1 6379 ，可以让接收到该命令的服务器变为 127.0.0.1:6379 的从服务器。在将一个服务器设置成从服务器之后，可以通过向它发送 SLAVEOF no one 来让它变回一个主服务器（数据库已有的数据会被保留）。
在启动服务器时，通过设置 slaveof 配置选项来让服务器成为指定服务器的从服务器。

举个例子，如果客户端对服务器 127.0.0.1:6380 发送命令 SLAVEOF 127.0.0.1 6379 ，那么127.0.0.1:6380 将成为 127.0.0.1:6379 的从服务器。
ここに画像を挿入説明

主从服务器操作示例

127.0.0.1:6379> SET msg “hello world”
OK
127.0.0.1:6379> INCR counter
(integer) 1
127.0.0.1:6379> INCR counter
(integer) 2
127.0.0.1:6379> RPUSH lst 1 3 5 7 9
(integer) 5

127.0.0.1:6380> GET msg
“hello world”
127.0.0.1:6380> GET counter
“2”
127.0.0.1:6380> LRANGE lst 0 -1
1)“1”
2)“3”
3)“5”
4)“7”
5)“9”

处理服务器下线

主服务器或者从服务器下线了，怎么办？！

服务器在复制时遭遇下线

在实际的世界中，因为故障而导致服务器下线的情况总是不可避免的。

在一个由主服务器和从服务器组成的系统中，主服务器或者从服务器都有可能会下线，但是不同服务器下线带来的影响并不相同：

如果下线的是从服务器，那么整个系统处理读请求的性能将有所下降，但 整个系统仍然可以继续处理写请求和读请求，所以这种下线不会导致系统停机；
另一方面，因为在整个系统里面，只有主服务器一个能够处理写请求，所以如果下线的是主服务器，那么整个系统将只能处理读请求而无法处理写请求，导致系统停机。

从服务器下线示例

ここに画像を挿入説明
从服务器 B 下线，导致客户端 C 的访问失败，但只要客户端 C 改为访问其他在线的服务器，就可以解决这个问题。

主服务器下线示例

ここに画像を挿入説明
主服务器下线导致主从服务器的连接中断，并使得整个系统无法再执行写命令。

这时从服务器还是可以继续处理读请求的，但是从服务器的数据会因为主服务器下线而没办法再得到更新。

让系统重新上线的方法（1/3）

（システムは、サーバがリクエストを読み込み、だけでなく、書き込み要求を処理することができるの両方を扱うことができるようにということ、である）通常のオンライン状態に戻るにはシステムのためには、あなたは、いずれかのサーバーからシステムにSLAVEOFにそれを誰のコマンドを送信しないする必要があります新しいマスターサーバーになり、他のISは、彼らがサーバから新しいコピーできるように、サーバーからSLAVEOFコマンドを送りました。
ここに画像を挿入説明

（2/3）システム背面のオンラインの方法をしてみましょう

ここに画像を挿入説明

（3/3）システム背面のオンラインの方法をしてみましょう

ここに画像を挿入説明
システムは、新しいプライマリサーバを持っており、サーバから、クライアントは、読み取りおよび書き込み要求を処理するためにシステムを使用し続けることができます。

なぜなら理由のオフラインサーバーは、それが再びオンラインシステムのパフォーマンスは、元のシステムのようではないかもしれないが、全体のシステムシャットダウンの回収作業を回避することができます。（あなたは、あなたが冗長サーバとして、追加のスレーブサーバーを追加することができない場合は、システムの復旧後の影響を受けたパフォーマンス。）

この方法は、手動でこれらの操作を実行するために、オンラインシステムバックを可能にするが、あまりにも面倒、この目的のために、Redisのセンチネル・プログラムを提供上述したが、ユーザが使用することができ
、自動的にマスターサーバーマスターサーバーとオフラインの状態から検出するセンチネルを自動フェイルオーバー操作（フェイルオーバー）、オンラインシステムのバック。