Redisのマスタースレーブレプリケーションの詳しい説明-Redis-php.cn

Redisのマスタースレーブレプリケーションの詳しい説明

この章では、Redis-マスター-スレーブレプリケーションの強力な機能を紹介します。マスターホストは複数のスレーブマシンを持つことができます。また、スレーブスレーブは複数のスレーブスレーブを持つことができます。これにより、引き続き強力なマルチレベルサーバークラスターアーキテクチャ (高い拡張性) が形成されます。 Redis の単一障害点を回避し、災害復旧効果 (高可用性) を実現できます。読み取りと書き込みを分離するアーキテクチャにより、読み取りが増加し、書き込みが減少する同時アプリケーションシナリオが満たされます。推奨: redis ビデオチュートリアル

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

マスター/スレーブレプリケーション、読み取り/書き込み分離、災害復旧、回復。 1 台のホストがデータの書き込みを担当し、複数のスレーブマシンがデータのバックアップを担当します。同時実行性が高いシナリオでは、ホストマシンがハングアップした場合でも、スレーブマシンを使用してホストマシンの代わりに動作を継続し、単一点障害によって引き起こされるシステムパフォーマンスの問題を回避できます。読み取りと書き込みを分離すると、読み取りが多く書き込みが少ないアプリケーションのパフォーマンスが向上します。

マスター/スレーブレプリケーションアーキテクチャ

Redis レプリケーションのベースには、非常に簡単に使用および構成できるマスタースレーブレプリケーションがあります。スレーブ Redis サーバーはマスターサーバーの正確なコピーです。

これは非常に簡単です。コマンド 1 つで、slaveof host ip host port でマスターとスレーブの関係を決定できます。コマンド 1 つで、./redis-sentinel Sentinel.conf Sentinel を実行できます。モニタリングをオンにすることができます。

構築は簡単ですが、メンテナンスは大変です。同時実行性が高いシナリオでは、多くの予期しない問題が発生する可能性があります。私たちが明確に理解しているのは、レプリケーションの原理、ホストマシンについての知識、およびスレーブマシンがダウンした後の変更だけです。そうすることでのみ、これらの落とし穴をうまく克服することができます。以下の各ステップは、小さな知識ポイントと小さなシーンです。ステップを完了するたびに知識が得られます。

アーキテクチャ図: 1 つのマスター、2 つのサーヴァント、および 1 つのソルジャー (複数のマスター、複数のサーヴァント、および複数のソルジャーを持つこともできます)

Redisのマスタースレーブレプリケーションの詳しい説明

構築前の準備作業

貧困のため、著者は 1 台のサーバーを使用して 3 台のホストをシミュレートすることにしました。運用環境との唯一の違いは、IP アドレスとポートです。

ステップ 1: redis.conf のコピーを 3 つコピーします。名前は redis6379.conf、redis6380.conf、redis6381.confです。

ステップ 2: 3 つのファイルのポート、pid ファイルを変更します。名前、ログファイル名、rdb ファイル名

ステップ 3: 3 つのウィンドウを開いて 3 つのサーバーをシミュレートし、redis サービスを開始します。

[root@itdragon bin]# cp redis.conf redis6379.conf
[root@itdragon bin]# cp redis.conf redis6380.conf
[root@itdragon bin]# cp redis.conf redis6381.conf
[root@itdragon bin]# vim redis6379.conf
logfile "6379.log"
dbfilename dump_6379.rdb
[root@itdragon bin]# vim redis6380.conf
pidfile /var/run/redis_6380.pid
port 6380
logfile "6380.log"
dbfilename dump_6380.rdb
[root@itdragon bin]# vim redis6381.conf
port 6381
pidfile /var/run/redis_6381.pid
logfile "6381.log"
dbfilename dump_6381.rdb
[root@itdragon bin]# ./redis-server redis6379.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
[root@itdragon bin]# ./redis-server redis6380.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6380
127.0.0.1:6380> keys *
(empty list or set)
[root@itdragon bin]# ./redis-server redis6381.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6381
127.0.0.1:6381> keys *
(empty list or set)

ログイン後にコピー

マスター/スレーブレプリケーションのセットアップ手順

基本セットアップ

ステップ 1: master レプリケーション情報から 3 つのポートをそれぞれ選択し、コマンド info replication を実行します。

# 6379 端口
[root@itdragon bin]# ./redis-server redis6379.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
......

# 6380 端口
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
......

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
......

ログイン後にコピー

3 つのポートはすべて同じ情報を出力します。 role:master 役割はマスター、connected_slaves:0 接続されているスレーブの数は 0 です。パラメータの意味の詳細については、接続にアクセスしてください: http://redisdoc.com/server/info.html

ステップ 2: ポート 6379 を選択し、コマンド set k1 v1

を実行します。

127.0.0.1:6379> set k1 v1
OK

ログイン後にコピー

ステップ 3: マスターとスレーブの関係を設定し、ポート 6380 とポート 6381 をそれぞれ選択し、コマンドを実行します: SLAVEOF 127.0.0.1 6379

# 6380 端口
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

# 6381 端口
127.0.0.1:6381> SLAVEOF 127.0.0.1 6379
OK
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

# 6379 端口
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=98,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=98,lag=1
......

ログイン後にコピー

マスターとスレーブの関係が変更されました:

6380 ポートと 6381 ポートの印刷情報: role:slave; master_host:127.0.0.1 ホストの IP アドレス; master_port:6379 ホストのポート。

ポート 6379 によって出力される情報: role:マスターホスト;connected_slaves:2 2 つのスレーブに接続;slaveX:ID、IP アドレス、ポート番号、接続ステータス、スレーブデータベース情報

いいえ。ステップ 4: 全体をコピーし、ポート 6380 とポート 6381 をそれぞれ選択し、コマンド get k1

# 6380 端口
127.0.0.1:6380> get k1
"v1"

# 6381 端口
127.0.0.1:6381> get k1
"v1"

ログイン後にコピー

を実行します。両方のポートで k1 の値を出力できます。これは、マスターとスレーブの関係を確立するときに、スレーブがマスター、データ。

ステップ 5: 増分コピー、ポート 6379 を選択し、コマンド set k2 v2 を実行します。次に、ポート 6380 とポート 6381 をそれぞれ選択し、コマンド get k2

# 6379 端口
127.0.0.1:6379> set k2 v2
OK

# 6380 端口
127.0.0.1:6380> get k2
"v2"

# 6381 端口
127.0.0.1:6381> get k2
"v2"

ログイン後にコピー

を実行します。両方のポートで k2 の値を出力できます。これは、マスターとスレーブの関係が確立された後、ホストによって新しいデータが追加されたことを示します。スレーブにコピーされます。

ステップ 6: マスターとスレーブの読み取り/書き込み分離、ポート 6380 を選択し、コマンドを実行します: set k3 v3

# 6380 端口
127.0.0.1:6380> set k3 v3
(error) READONLY You can&#39;t write against a read only slave.

# 6379 端口
127.0.0.1:6379> set k3 v3
OK

ログイン後にコピー

読み取り/書き込み分離メカニズムにより、スレーブ 6380 は書き込みに失敗しました。

ステップ 7: ホストがダウンしている場合は、ポート 6379 を選択してコマンドを実行します: shutdown

# 6379 端口
127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380 端口
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

ログイン後にコピー

出力結果から、スレーブがスタンバイ状態であることがわかります

8 つの手順: クラッシュ後のホストの回復ポート 6379 を選択し、Redis サービスを再起動して、コマンド set k4 v4 を実行します。ポート 6380 とポート 6381 をそれぞれ選択し、コマンド get k4

# 6379 端口
[root@itdragon bin]# ./redis-server redis6379.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> set k4 v4
OK

# 6380 端口
127.0.0.1:6380> get k4
"v4"

# 6381 端口
127.0.0.1:6381> get k4
"v4"

ログイン後にコピー

を実行します。ホストが再起動すると、すべてが正常になります。

ステップ 9: スレーブマシンがクラッシュした後に回復し、ポート 6380 を選択して、コマンド shutdown を実行します。ポート 6379 を選択し、コマンド set k5 v5 を実行します。ポート 6380 を選択し、Redis サービスを再起動してコマンド get k5

を実行します。

# 6380 端口
127.0.0.1:6380> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# ./redis-server redis6380.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6380
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......
127.0.0.1:6380> get k5
"v5"

# 6379 端口
127.0.0.1:6379> set k5 v5
OK

ログイン後にコピー

从机宕机后，一切正常。笔者用的是redis.4.0.2版本的。看过其他教程，从机宕机恢复后，只能同步主机新增数据，也就是k5是没有值的，可是笔者反复试过，均有值。留着备忘！

第十步：去中性化思想，选择6380端口，执行命令：SLAVEOF 127.0.0.1 6381。选择6381端口，执行命令：info replication

# 6380 端口
127.0.0.1:6380> SLAVEOF 127.0.0.1 6381
OK

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1677,lag=1
......

ログイン後にコピー

虽然6381 是6380的主机，是6379的从机。在Redis眼中，6381依旧是从机。一台主机配多台从机，一台从机在配多台从机，从而实现了庞大的集群架构。同时也减轻了一台主机的压力，缺点是增加了服务器间的延迟。

从机上位

模拟主机宕机，人为手动怂恿从机上位的场景。先将三个端口恢复成6379是主机，6380和6381是从机的架构。

从机上位步骤：

第一步：模拟主机宕机，选择6379端口，执行命令：shutdown

第二步：断开主从关系，选择6380端口，执行命令：SLAVEOF no one

第三步：重新搭建主从，选择6381端口，执行命令：info replication，SLAVEOF 127.0.0.1 6380

第四步：之前主机恢复，选择6379端口，重启Redis服务，执行命令：info replication

在6379主机宕机后，6380从机断开主从关系，6381开始还在原地待命，后来投靠6380主机后，6379主机回来了当它已是孤寡老人，空头司令。

# 6379端口

127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380端口
127.0.0.1:6380> SLAVEOF no one
OK
127.0.0.1:6380> set k6 v6
OK

# 6381端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380
OK
127.0.0.1:6381> get k6
"v6"

ログイン後にコピー

哨兵监控

从机上位是需要人为控制，在生产环境中是不可取的，不可能有人实时盯着它，也不可能大半夜起床重新搭建主从关系。在这样的需求促使下，哨兵模式来了！！！

哨兵有三大任务：

1 监控：哨兵会不断地检查你的Master和Slave是否运作正常

2 提醒：当被监控的某个Redis出现问题时, 哨兵可以通过API向管理员或者其他应用程序发送通知

3 故障迁移：若一台主机出现问题时，哨兵会自动将该主机下的某一个从机设置为新的主机，并让其他从机和新主机建立主从关系。

哨兵搭建步骤：

第一步：新开一个窗口，取名sentinel，方便观察哨兵日志信息

第二步：创建sentinel.conf文件，也可以从redis的解压文件夹中拷贝一份。

第三步：设置监控的主机和上位的规则，编辑sentinel.conf，输入 sentinel monitor itdragon-redis 127.0.0.1 6379 1 保存退出。解说：指定监控主机的ip地址，port端口，得票数。

第四步：前端启动哨兵，执行命令：./redis-sentinel sentinel.conf。

第五步：模拟主机宕机，选择6379窗口，执行命令：shutdown。

第六步：等待从机投票，在sentinel窗口中查看打印信息。

第七步：启动6379服务器，

语法结构：sentinel monitor 自定义数据库名主机ip 主机port 得票数

若从机得票数大于设置值，则成为新的主机。若之前的主机恢复后，

如果哨兵也宕机了？？？那就多配几个哨兵并且相互监控。

# sentinel窗口
[root@itdragon bin]# vim sentinel.conf
sentinel monitor itdragon-redis 127.0.0.1 6379 1
[root@itdragon bin]# ./redis-sentinel sentinel.conf
......
21401:X 29 Nov 15:39:15.052 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ itdragon-redis 127.0.0.1 6380
21401:X 29 Nov 15:39:15.052 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
21401:X 29 Nov 15:39:45.081 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380

21401:X 29 Nov 16:40:52.055 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
21401:X 29 Nov 16:41:02.028 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
......

# 6379端口
127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380端口
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=72590,lag=0
......

# 6381端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
......

ログイン後にコピー

+slave ：一个新的从服务器已经被 Sentinel 识别并关联。

+sdown ：给定的实例现在处于主观下线状态。

-sdown ：给定的实例已经不再处于主观下线状态。

Redisのマスタースレーブレプリケーションの詳しい説明