Redisの永続性とマスタースレーブレプリケーション

なぜ永続性が必要なのですか

RedisはメモリベースのNoSQLデータベースです。読み取りと書き込みの速度は当然高速ですが、メモリは瞬時に実行されます。redisサービスをシャットダウンまたは再起動すると、redisによってメモリに保存されているデータは失われます。この問題、redisは2種類の永続性を提供します。障害後にデータを回復する方法。

永続性オプション

Redisは、データをハードディスクに保存するための2つの異なる永続化方法を提供します。1つはスナップショット方式（RDB方式とも呼ばれます）で、redisに存在するすべてのデータをいつでもハードディスクに保存できます。もう1つは、すべてのデータを定期的にコピーする追加専用ファイル（AOF）方式です。 redisによって実行されますハードディスクへの書き込みコマンド。これらの2つの永続化方法には独自のメリットがあり、同時にまたは個別に使用でき、場合によってはどちらも使用できません。

RDBの方法

RDBメソッドはスナップショットメソッドとも呼ばれ、スナップショットを作成することにより、特定の時点でのデータ（.rdb）のコピーをハードディスクに保存します。サーバーを再起動した後、redisはRDBファイルをロードしてデータを復元します。RDBの永続性構成を見てみましょう。
vi redis.confredis構成ファイルを開き、SNAPSHOTTINGセクションを見つけて、以下を見つけます。

save 900 1
save 300 10
save 60 10000
……
dbfilename dump.rdb
dir ./

説明

1. 秒の変更を保存：秒の後に、変更キーで多くの変更がある場合、スナップショットが保存されることを示します。ご覧のとおり、rdb永続性はデフォルトで有効になっており、3つの保存オプションが構成されています。rdb永続性をオフにする場合は、すべての保存をコメントアウトするだけです。
2. dbfilename：rdbファイル名
3. dir：RDBファイルストレージパス

スナップショットを作成する

BGSAVE：
BGSAVEコマンドを使用してスナップショットを作成できます。redisがBGSAVEコマンドを受信すると、子プロセスがフォークアウトします。子プロセスはスナップショットをハードディスクに書き込む役割を果たし、親プロセスは引き続きコマンド要求を処理します。redisは子プロセスを作成するときに親プロセスをブロックし、時間の長さはredisが占めるメモリサイズに比例することに注意してください。コマンド
を手動で呼び出すことに加えて、コマンドには次の2つのトリガー条件があります。BGSAVEBGSAVE

1. ユーザーが保存オプションを構成しました。redisによって作成された最後のスナップショットから開始して、保存オプションの条件が満たされるとBGSAVEコマンドがトリガーされます。
2. マスター/スレーブレプリケーション接続中に、新しく接続されたスレーブサーバーはSYNCデータ同期を要求するコマンドをマスターサーバーに送信します。マスターサーバーはSYNCコマンドを受信した後、BGSAVEコマンドを1回実行し、生成されたrdbファイルをに送信します。データ同期用のスレーブサーバー。

保存：
SAVEコマンドはスナップショットを作成することもできBGSAVEますが、SAVEコマンドとは異なり、コマンドは子プロセスを作成しないため、コマンドを受信したSAVERedisサーバーは、スナップショットが作成されるまで他のコマンドに応答しません。スナップショットの作成プロセス中に他のプロセスがリソースを取得SAVEすることはないBGSAVEため、スナップショットを作成するコマンドは、スナップショットを作成するコマンドよりも高速になります。それでも、SAVEコマンドは一般的には使用されず、通常、十分なメモリがない場合、またはスナップショットが完了するのを待っている場合にのみ使用されます。
たとえば、redisはSHUTDOWNサービスを閉じるコマンドを受信すると、そのSAVEコマンドを1回実行し、すべてのクライアントをブロックし、SAVEコマンドの実行後に閉じます。

RDB方式の長所と短所

利点：

1. データのバックアップには1つのファイルのみを使用し、災害後に簡単に復元できます
2. aofと比較して、rdbファイルは小さく、データを復元するためのrdbファイルのロードも高速です。

短所：

1. 障害が原因でredisサービスがシャットダウンまたは再起動された場合、最新のスナップショットが作成された後に書き込まれたデータは失われます
2. データ量が多い場合、子プロセスを作成すると、redisが長時間一時停止します

AOF法

簡単に言えば、AOF永続性は、実行された書き込みコマンドをaofファイルの最後に書き込み、データの変更を記録します。したがって、aofファイルに含まれるすべての書き込みコマンドが最初から最後まで再度実行される限り、redisはデータを復元できます。

redis構成ファイルを開いて以下を確認してください。

# 是否开启aof持久化，默认为关闭（no）
appendonly yes
# 设置对aof文件的同步频率
# 每接收到一条写命令就进行一次同步，数据保障最有力，但对性能影响十分严重
appendfsync always
# 每秒进行一次同步，推荐
appendfsync everysec
# 由操作系统来决定何时进行同步
appendfsync no
# 重写aof相关
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOFファイルを書き換え/圧縮する

aofの永続性はredis書き込みコマンドを継続的に記録するため、redisが実行されると、aofファイルはますます大きくなり、ハードディスク領域を占有しすぎ、redisがデータ復元操作を実行する時間が長くなります。したがって、過度に大きなAOFファイルを回避するための制御スキームが必要です。

BGREWRITEAOFRedisは、AOFファイルを書き換えるコマンドを提供BGREWRITEAOFし、元のAOFファイルの冗長なコマンドを削除することでAOFファイルのサイズを可能な限り縮小します。BGREWRITEAOF動作原理はBGSAVE非常に似ています。Redisは子プロセスを作成し、次に子プロセスがaofファイルを書き換えます。

もちろん、BGREWRITEAOFコマンドには自動トリガーメカニズムもあり、構成auto-aof-rewrite-percentageとを介してauto-aof-rewrite-min-size自動的に実行できます。たとえば、auto-aof-rewrite-percentage 100とauto-aof-rewrite-min-size64mbが設定されていて、aofの永続性がオンになっている場合、aofファイルのサイズは64mbより大きく、現在のファイルは最後の書き換え後のファイル量が2倍（100％）を超えると、redisは自動的にBGREWRITEAOFコマンドを実行します。

AOF永続性の長所と短所

利点

1. データが失われるまでの時間枠を1秒に短縮でき、パフォーマンスに大きな影響を与えることはありません。
2. Aofはログファイルに追加モードを使用するため、書き込みプロセス中にダウンタイムが発生しても、ログファイル内の既存のコンテンツが破壊されることはありません。データの半分だけが書き込まれると、データがダウンします。次回開始redis-check-aodされると、ツールを使用してデータの一貫性の問題を解決できます

不利益

1. AOFファイルを書き換えるメカニズムがある場合でも、AOFファイルのサイズは常にAOF永続性の最大の欠陥でした。
2. データを回復するためにaofファイルをロードするプロセスは、rdbファイルをロードするよりも時間がかかります

マスタースレーブレプリケーション

redisは優れたパフォーマンスを発揮しますが、リクエストを迅速に処理できないという問題が発生します。高い同時実行性によって引き起こされるデータベースパフォーマンスの問題に対処するために、redisはリレーショナルデータベースのようにマスタースレーブレプリケーションと読み取り/書き込み分離を実行できます。つまり、以前のようにすべての読み取り要求をマスターサーバーに送信するのではなく、マスターサーバーにデータを書き込み、サーバーからリアルタイムで更新を受信し、スレーブサーバーを使用してすべての読み取り要求を処理するため、マスターサーバーに過度の負荷がかかります。 、通常は読み取り要求使用するスレーブサーバーをランダムに選択するため、負荷は各スレーブサーバーに均等に分散されます。次の図は、単純なredisマスタースレーブアーキテクチャです。

マスタースレーブレプリケーション構成

最初にredisディレクトリで実行しvi redis6380.conf、現在のディレクトリにredis構成ファイルを作成して、次のように記述します。

include /usr/local/redis-4.0.13/redis.conf
port 6380
pidfile /var/run/redis_6380.pid
logfile 6380.log
dbfilename dump6380.rdb

説明：

1. 含める：指定された構成ファイルの構成情報を現在の構成ファイルに導入します。redisのデフォルト構成ファイルがここに導入されます。リモートアクセス、パスワードなどが設定されているため、新しい構成でリセットする必要はありません。ファイル。再構成が必要な構成情報（ポート番号など）の場合、インクルード行の下の構成は、参照されている構成をオーバーライドできます。
2. ポート：ポート番号。マスターサーバーとスレーブサーバーは同じ仮想マシンで実行されているため、異なるポート番号を構成する必要があります。
3. pidfile：カスタムpidファイル。バックグラウンドプログラムのpidがこのファイルに保存されます。
4. logfile：ログファイル。
5. dbfilename：rdbファイルの名前。

上記の操作の後、新しいマスターサーバーが構成され、次にスレーブサーバーが構成され、現在のディレクトリにredis6382という名前のredis構成ファイルが作成されます。vi redis6382.conf

include /usr/local/redis-4.0.13/redis.conf
port 6382
pidfile /var/run/redis_6382.pid
logfile 6382.log
dbfilename dump6382.rdb
slaveof 127.0.0.1 6380
masterauth 主服务器的密码

サーバーからの追加の構成がいくつかあります。

1. slaveof：私が誰のスレーブサーバーであるかを示します。マスターサーバーのIPアドレスとポート番号を開発する必要があります
2. masterauth：マスターサーバーがパスワードで構成されている場合は、ここで構成する必要があります。そうしないと、スレーブサーバーがマスターサーバーに接続できなくなります。

他のスレーブサーバーの構成も同様です。ポート番号の割り当てに注意してください。ここでは6384を構成しました。
設定が成功し./redis-server ../redis6380.confたら、srcディレクトリでそれを使用してマスターサーバーを起動し、次にスレーブサーバーを起動して自動的にマスターサーバーに接続します。対応する設定ファイルの指定に注意してください。次の内容が表示されている
場合ps -ef | grep redisは、マスタースレーブサーバーが正常に起動したことを意味します。

root      2625     1  0 16:15 ?        00:00:00 ./redis-server *:6380
root      2630     1  0 16:15 ?        00:00:00 ./redis-server *:6382
root      2636     1  0 16:15 ?        00:00:00 ./redis-server *:6384

マスターサーバーとスレーブサーバーが起動したら、マスターサーバーのクライアントを入力し、次のように./redis-cli -p 6380 -a 你的密码実行info replicationしてマスターサーバーとスレーブサーバーの情報を表示します。

127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6382,state=online,offset=336,lag=1
slave1:ip=127.0.0.1,port=6384,state=online,offset=336,lag=1
master_replid:b5c68a979b28d2a9ef53476510758b5d1795418b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:336
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:336

同様に、サーバークライアントから上記のコマンドを実行すると、情報を取得することもできます

127.0.0.1:6384> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:686
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:b5c68a979b28d2a9ef53476510758b5d1795418b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:686
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:15
repl_backlog_histlen:672

この時点で、1つのマスターと2つのスレーブ、および読み取りと書き込みの分離を備えたRedisアーキテクチャが構成され、正常に開始されています。

マスタースレーブレプリケーションの起動プロセス

上の図は、古いモデレーターとスレーブRedisの起動プロセスです。特別な説明が必要な点は次のとおりです。

1. スレーブサーバーが初期接続を行うと、データベース内の元のデータはすべて失われ、マスターサーバーから送信されたデータに置き換えられます。
2. スレーブサーバーはキーの有効期限操作を担当しませんが、マスターサーバーから送信されたコマンドを受動的に受け入れます。マスターがキーを期限切れにする（またはLRUアルゴリズムのためにキーを削除する）と、DELコマンドを合成してに送信します。すべてのスレーブ
3. SYNCは非常にリソースを消費する操作です。BGSAVE中、マスターサーバーの合計スループットが低下し、マスターサーバーとスレーブサーバーのネットワークリソースを大量に消費してrdbファイルを送信します。スレーブサーバーがrdbファイルをロードすると、クライアントの要求に応答することはできませんが、SYNCの最大の欠点は、スレーブサーバーが切断されて再接続されたときに、RDBファイルを最初から再度ロードするように申請する必要がないことです。この新しいRDBファイルに含まれるデータは、切断前に書き込まれた可能性があります。サーバーから、現時点では、スレーブサーバーは切断中に書き込まれたデータを取得するだけで済みます。

部分的な再同期

古いバージョンのレプリケーションの欠点を補うために、Redisはバージョン2.8以降、SYNCコマンドの代わりにPSYNCコマンドを使用しています。PSYNCには、完全な再同期と部分的な再同期の2つのモードがあります。完全な再同期は以前のバージョンの同期と同様であり、RDBを送信する必要があります。しかし、部分的な再同期は驚くべきものです。切断期間中にマスターサーバーに書き込まれた書き込みコマンドのみをスレーブサーバーに送信できます。これにより、消費するリソースが少なくなり、はるかに高速になります。以下に示すように。

部分的な再同期の実装原理は複雑ではなく、コピーオフセット（オフセット）、コピーバックログバッファー、サーバー実行ID（runid）の3つの部分で構成されています。

レプリケーションオフセット
レプリケーションオフセットは、マスターサーバーとスレーブサーバーの同期ステータスを確認するために使用されます。マスターサーバーとスレーブサーバーはそれぞれコピーオフセットを維持します。マスターサーバーがNバイトのデータをスレーブサーバーに送信すると、独自のコピーオフセットがNに追加されます。スレーブサーバーはNバイトのデータを受信します。Nを独自のコピーオフセットに追加します。 。同期状態は、マスターとスレーブのレプリケーションオフセットを比較することで簡単に確認できます。

コピーバックログバッファ
コピーバックログバッファを先入れ先出しの固定長であるキューは、マスタサーバによって維持マスターサーバー行う伝搬を指示する場合、以下のように、コマンドは、コピーバックログバッファにキューイングされます。

起因するとコピーバックログバッファは固定長キューであるため、最新の期間に実行された書き込みコマンドのみを保存し、キュー内の各バイトに対応するコピーオフセットを記録します。サーバーからPSYNCコマンドを送信するとき、サーバーは独自のコピーオフセットを伝送します。マスターサーバーはこのオフセットを取得して、独自のコピーバックログバッファー内のオフセット+ 1（切断後に実行される次のコマンド）をチェックします。 ？まだ存在する場合は、部分的な再同期を実行でき、offset + 1からキューの最後までのすべてのデータがスレーブサーバーに送信されます。存在しない場合、スレーブサーバーは完全な再同期のみを実行できます。正直なところ。

IDを実行している
サーバーIDを実行しているサーバーは、切断前にマスターサーバーとスレーブサーバーが同じファミリにあるかどうかを確認するだけです。各redisサーバーには独自の実行IDがあります。マスタースレーブが初めて接続すると、マスターサーバーは独自のサーバー実行IDをスレーブサーバーに送信して保存します。スレーブサーバーが再接続すると、以前のサーバーが同時に送信されます。保存されたマスターサーバーのrunid。メインサーバーに対して、メインサーバーはこのrunidを独自のrunidと比較します。それらが同じである場合は、スレーブサーバーが実際に以前にそれ自体から切断されていることを意味し、オフセットを確認します。一貫性がない場合は、スレーブサーバーが以前に別のマスターサーバーのスレーブであったことを意味します。完全な再同期。

の前にinfo replicationコマンドを実行すると、サーバーの実行IDとレプリケーションオフセットを確認できます。

要約すると、新しいバージョンのredisレプリケーションの同期プロセスはおおよそ次のとおりです。