Redisの高可用性-マスター/スレーブレプリケーションの詳細な説明

 

(1)マスタースレーブレプリケーションの概要

上記のredis操作はすべてスタンドアロン操作です。スタンドアロン操作は操作が簡単ですが、処理機能が制限されているため、高可用性を実現できません。いわゆる高可用性とは、サーバーがダウンしたときに、サーバーを置き換えることができるバックアップサーバーが存在することを意味します。これはスタンドアロン操作では不可能であるため、マスタースレーブレプリケーションが発生します。

1台のサーバーをマスターサーバーと見なし、他のサーバーをスレーブサーバーと見なします。マスタースレーブレプリケーションは、マスター内のデータをスレーブに即座に効果的にコピーすることです。

 

マスタースレーブレプリケーションの特性:

マスターは複数のスレーブを持つことができ、スレーブは1つのマスターにのみ対応します

マスターはデータの書き込みを担当し、変更されたデータをスレーブに自動的に同期します

スレーブはデータの読み取りを担当し、データの書き込みは禁止されています

マスタースレーブレプリケーションを使用すると、高可用性を実現できます.1つのスレーブがダウンしても、複数のスレーブが存在します。マスターがダウンしても、スレーブのデータはマスターと同じであるため、1つを選択できます。新しいマスターであり、可用性が高くなります。

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

読み取りと書き込みの分離:マスター書き込み、スレーブ読み取り

負荷分散:スレーブはマスターの負荷を共有し、特定のニーズに応じてスレーブの数を変更できます

障害回復:マスターに問題がある場合、スレーブを使用してマスターを交換し、迅速な回復を実現できます。

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

(2)マスタースレーブレプリケーション環境の構成

環境構成

マスタースレーブ構成は、infoコマンドで表示できます。

>info replication  # 查看当前库的信息
# Replication
role:master #角色 master
connected_slaves:0  # 从机个数
master_replid:8ff09770a496e8472fffef9f35ebdd1bc0b15ecb
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

redis6379.conf、redis6380.conf、redis6381.confという名前の3つの構成ファイルをコピーしてから、対応する情報を変更します。

#端口
port 6379  #复制多个改为6380、6381
#pid名字  
pidfile /var/run/redis_6379.pid #复制多个改为6380、6381
#log文件名字
logfile "6379.log" #复制多个改为6380、6381
#dump.rdb名字
dbfilename dump6379.rdb #复制多个改为6380、6381

それぞれ構成ファイルからredis-serverを起動します

./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf

 

1マスター2スレーブ構成

デフォルトでは、各Redisサーバーがマスターノードです。通常の状況では、スレーブを構成するだけで済みます。

ここでは、79をマスター、80と81をスレーブとして設定します。

redis-cli -p 6380
127.0.0.1:6380> slaveof 127.0.0.1 6379  #设置6379为主机
#在从机中查看信息
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:28
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:f669a0ed63ed7f23841baa0c708b3d757d7ccc54
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:28
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:28
 
在主机中查看信息
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=112,lag=0
master_replid:f669a0ed63ed7f23841baa0c708b3d757d7ccc54
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:112
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:112

同様に、6381のホストを6379に設定します。このように構成されているのは一時的なマスタースレーブ構成であり、永続的なマスタースレーブ構成は構成ファイルで構成されます。

replicaof <masterip> <masterport>  #设置主机的ip和端口
masterauth <master-password> #如果主机有密码则设置密码

マスタースレーブ構成を設定した後、マスターノードが書き込んだ後、スレーブノードで読み取ることはできますが、スレーブノードで書き込むことはできません。

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6380> get k1
"v1"
127.0.0.1:6380> set k2 v2
(error) READONLY You can't write against a read only replica. 

ただし、マスターが接続された後もスレーブが元のマスターに接続されている場合は、この問題を解決するためにセンチネルを導入する必要があります。

スレーブが初めてマスターに接続すると、フルコピーがトリガーされ、マスターからの後続の書き込みがインクリメンタルレプリケーションをトリガーすることに注意してください。

 

(3)マスタースレーブレプリケーションワークフロー

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

1.接続フェーズの確立

2.データ同期段階

3.コマンド伝播フェーズ(同期の繰り返し)

 

2.1接続フェーズの確立

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

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

3. pingコマンドを送信します(タイマータスク)

4.本人確認

 

2.2データ同期段階

1.データの同期をリクエストする

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

3.RDB同期データを回復します

4.部分同期データを要求します

5.同期されたデータの一部を回復します

このような5つのステップを見るだけでは少し抽象的かもしれませんが、それは図で表すことができます。

データ同期は、完全レプリケーションと部分レプリケーションに分けられます。完全レプリケーションは、同期コマンドを開始した後に実行されるRDB操作であり、マスター内のデータはRDBを介してスレーブに送信されます。RDBはbgsave命令を使用するため、フルコピー中にマスターによって実行された操作はバッファーに入ります。フルコピーが終了すると、部分コピーを使用して、AOFが使用されるバッファー内の操作を復元する必要があります。

部分的なデータ同期に関する注意:

上記の紹介により、フルレプリケーション中に実行された操作がキャッシュ領域に配置されることがわかりますが、キャッシュ領域の設定が小さすぎると、マスターがブロックされます。キャッシュ領域のサイズは次のように設定できます。仕方:

repl-backlog-size 1mb

以下のパラメータを設定することにより、スレーブ外部サービスを一時的にオフにすることができます

slave-server-stable-data yes|no

2.3コマンド伝搬フェーズ

コマンド伝播フェーズでは、マスターデータベースのステータスが変更されると、コマンド伝播フェーズを通じてスレーブに同期されます。

コマンド伝播フェーズには、次の3つのコア要素があります。

サーバーの実行ID、マスターサーバーのレプリケーションバックログバッファー、およびマスタースレーブサーバーのレプリケーションオフセット

サーバー実行ID:

サーバー実行IDは、毎回実行される各サーバーの識別コードあり、40文字で構成され、サーバー間で送信するときにIDを識別するために使用されます。

プライマリサーバーのレプリケーションバックログバッファ:

コピーバックログバッファは、コピーバッファとも呼ばれ、先入れ先出しキューです。マスターデータベースが変更されると、マスターはスレーブに伝達されるコマンドをレプリケーションバッファーに保存し、スレーブはそれぞれレプリケーションバッファーから情報を受信します。

マスターサーバーとスレーブサーバーのレプリケーションオフセット:

マスターはコマンド伝播フェーズ中に最初にデータをバッファーに入れるため、マスターはスレーブに送信された命令に対応する位置を記録するためにコピーオフセットを必要とします。スレーブはバッファ内のデータを自身に同期させる必要があるため、受信位置を記録するためにコピーオフセットも必要です。ネットワークが誤って切断された場合、ネットワークが再接続された後、コピーオフセット位置から直接続行できます。copy 。

2.4ハートビートメカニズム

コマンド伝播フェーズに入った後、マスターとスレーブはハートビートメカニズムを介して2つのパーティ間の接続を維持する必要があります

マスターハートビート:

pingコマンドを使用してスレーブがオンラインであるかどうかを照会します。期間はrepl-ping-slave-periodで設定できます。デフォルトは10秒です。

スレーブハートビート:

命令:

replconf ack {offset}

サイクル1秒;

役割:スレーブ自身のレプリケーションオフセットを報告し、マスターがオンラインかどうかを判断します

ほとんどのスレーブがオフラインの場合、またはスレーブの遅延が長すぎる場合は、マスターの書き込み機能を強制的にオフにして、データの同期を停止できます。

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

 

おすすめ

転載: blog.csdn.net/qq_33762302/article/details/114682599