習熟度（VIII）にエントリをRedisの：高可用性をRedisの - 詳細なマスタースレーブのレプリケーション

マスターコピーはじめから（A）

Redisの上で動作する前の言い方は、スタンドアローン操作を、スタンドアロン動作に属し、単純な、限られた処理能力ではなく、可用性ものの。いわゆる高可用性、達成することができないので、マスタースレーブのレプリケーションが行われているスタンドアロン動作で、サーバーを置き換えることができ、スペアがある場合、サーバーがダウンしたときにということです。

私たちは、サーバが（スレーブ）と見られているサーバーから複数のサーバに加えて、プライマリサーバ（マスター）、と見られているに言えば、主は途中でマスタからスレーブにデータをコピーするための実効率的な複製です。

 

前記マスターコピーをから：

あなただけに対応するマスタにスレーブマスター、スレーブを複数持つことができます

マスターデータ書き込みを行うための責任のデータは、変更が自動的にスレーブに同期して発生します。

スレーブがデータを読み込むための責任があるデータの禁止を書いて、

子局がダウンしたときにコピーした後、マスター・スレーブと、高可用性を実現することができ、スレーブが存在複数存在する;マスターがダウンしている場合、マスタとスレーブのデータが同じであるため、一方が選択でき新しいマスターとしてスレーブは、高可用性を実現することができます。

コピーの主な役割：

別々の読み取りと書き込み：マスタ書き込み、スレーブ読みます

ロードバランシング：マスター負荷がスレーブバランス、及び数は、スレーブの特定のニーズに応じて変えることができます

回復：マスターの問題は、マスター・スレーブに置き換えることができる、高速リカバリ

データの冗長性：複数のスレーブと、データのバックアップが容易になります

（B）マスタースレーブレプリケーションワークフロー

マスタースレーブレプリケーションのワークフローは、3つの段階に分けることができます。

接続フェーズを確立する1

2.データの同期段階

3.コマンド・普及段階（繰り返し同期）

 

接続段階を確立するために、2.1

1. マスター・アドレスとポート番号を設定します。

2. ソケット接続を確立します

3. pingコマンドを送信します（タスクタイマ）

4. 認証

 

そして、上述の処理を達成するために、私は2つのポートをオープンRedisのサービスであった、6379は、スレーブの代わりにマスター、6380を表します

それぞれの設定ファイルの2つのコピー、リネームredis6379.confとredis6380.confを、Redisの、ポート6379および6380のための設定ファイルを変更します。CMDに2つのサービスを開きます。

 そして、オープン2つのクライアントが2つのRedisのサービスに接続されている、6379は、マスター、6380がスレーブであります

redis-cli -p 6379
redis-cli -p 6380

マスター・スレーブ接続

slaveof <masterip> <masterport>

 

このとき、マスターは接続から完成されてきた、私の名前がマスター上に設けられ、スレーブから直接入手することができます

また、設定ファイルの構成で接続コマンドに加えて、外部から接続された主、redis6380.confの増加

slaveof 127.0.0.1 6379

完了したら自動的にマスター接続から再起動します

外しメイン接続

slaveof no one

2.2データ同期相

1. 同期要求データ

2. データ同期RDBを作成します。

3. 回復RDBのデータ同期

前記要求データ同期部

回復同期データ部分

このような手順では、1つのグラフで、5やや抽象的に見えることがあります。

同期データ複製は、二つの部分の複製の合計に分割されていて、命令RDB動作の同期を開始した後、コピーの総量が実行され、データはスレーブRDBによってマスタに送信されます。RDB使用bgsave命令ので、コピー動作中に全量がマスタに説明するように、バッファ回復動作の必要の終了後の総量は、部分的バッファ・コピーによってコピーされる場合、ここでAOFを用います。

データ同期の問題の一部に注意してください。

上記の説明を通じて、コピーをバッファゾーンに配置されたときに、我々は動作中に全額を知っているが、キャッシュは、マスターブロッキングにつながる小さすぎる設定されている場合は、次の方法により、バッファのサイズを設定することができます：

repl-backlog-size 1mb

可以通过配置以下参数暂时关闭slave对外服务

slave-server-stable-data yes|no

2.3 命令传播阶段

命令传播阶段就是当master数据库状态发生变化，就会通过命令传播阶段同步给slave

命令传播阶段有三个核心要素：

服务器的运行id、主服务器的复制积压缓冲区、主从服务器的复制偏移量

服务器运行id：

服务器运行id是每台服务器每次运行的身份识别码，由40个字符组成，用于在服务器之间传输时识别身份。

主服务器的复制积压缓冲区：

复制积压缓冲区又称为复制缓冲区，是一个先进先出的队列。当master数据库发生变化时，master会将要传播给slave的命令保存在复制缓冲区中，slave分别从复制缓冲区接收信息。

主从服务器的复制偏移量：

因为命令传播阶段首先由master把数据放入缓冲区中，因此master需要一个复制偏移量记录发送给slave的指令对应的位置。而slave要把缓冲区中的数据同步到自己这里，因此也需要一个复制偏移量记录接收到的位置，如果因为意外断网，等网络再次连接之后就可以直接从复制偏移量的位置继续复制。

2.4 心跳机制

进入命令传播阶段后，master和slave需要通过心跳机制保持双方连接

master心跳：

通过ping指令查询slave是否在线，可由repl-ping-slave-period设置周期，默认10秒

slave心跳：

指令：

replconf ack {offset}

周期1秒；

作用：汇报slave自己的复制偏移量；判断master是否在线

当slave多数都掉线或者slave延迟过高时，可以强制关闭master的写功能，停止数据同步：

min-slaves-to-write 2    当连接的slave小于等于2台时停止数据同步
min-slaves-max-lag 10    当连接的slave延迟大于10秒，停止数据同步