Redis マスター/スレーブ レプリケーション センチネル クラスター

Redis マスター/スレーブ レプリケーション センチネル クラスター

1. Redis のマスター/スレーブ レプリケーション

1.1 Redis マスター/スレーブ レプリケーションの概要

  • マスター/スレーブ レプリケーションとは、1 つの Redis サーバーのデータを他の Redis サーバーにコピーすることを指します。前者をマスターノード(Master)、後者をスレーブノード(Slave)と呼び、データの複製はマスターノードからスレーブノードへのみの一方向です。
  • デフォルトでは、各 Redis サーバーはマスター ノードであり、マスター ノードは複数のスレーブ ノードを持つことができます (またはスレーブ ノードを持たない) が、スレーブ ノードが持つことができるマスター ノードは 1 つだけです。

1. マスター/スレーブ レプリケーション: マスター/スレーブ レプリケーションは高可用性 Redis の基礎であり、Sentinel とクラスターは高可用性を実現するためにマスター/スレーブ レプリケーションに基づいています。マスター/スレーブ レプリケーションでは、主にデータのマルチマシン バックアップ、読み取り操作の負荷分散、および単純な障害回復が実装されます。欠点: 障害回復は自動化できません。書き込み操作の負荷分散はできません。ストレージ容量は 1 台のマシンによって制限されます。
2. Sentinel: Sentinel は、マスター/スレーブ レプリケーションに基づいて、自動障害回復を実現します。欠点: 書き込み操作の負荷分散ができない; ストレージ容量が 1 台のマシンによって制限される; Sentinel がスレーブ ノードを自動的にフェイルオーバーできない 読み書き分離のシナリオでは、スレーブ ノードの障害により読み取りサービスが利用できなくなり、追加の監視が発生します。スレーブノードはスイッチ操作が必要です。
3. クラスタリング: Redis はクラスタリングを通じて、書き込み操作の負荷分散ができず、ストレージ容量が単一マシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。

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

1. データ冗長化:永続化以外のデータ冗長化方式であるマスタ・スレーブレプリケーションにより、データのホットバックアップを実現します。
2. 障害回復: マスター ノードに問題が発生した場合、スレーブ ノードは迅速な障害回復を実現するためのサービスを提供できますが、これは実際には一種のサービス冗長性です。
3. 負荷分散: マスター/スレーブ レプリケーションに基づいて、読み書き分離と組み合わせることで、マスター ノードは書き込みサービスを提供し、スレーブ ノードは読み取りサービスを提供できます (つまり、アプリケーションは書き込み時にマスター ノードに接続します) Redis データ、およびアプリケーションは Redis データを読み取るときにスレーブ ノードに接続します。ノード) を使用してサーバーの負荷を共有します。特に、書き込み量を減らし読み取り量を増やすシナリオでは、複数のスレーブ ノードで読み取り負荷を共有すると、同時実行性が大幅に向上します。 Redisサーバー。
4. 高可用性の基礎: 上記の機能に加えて、マスター/スレーブ レプリケーションはセンチネルとクラスターの実装の基礎でもあるため、マスター/スレーブ レプリケーションは Redis の高可用性の基礎となります。

1.3 マスター/スレーブ レプリケーションのプロセス

1. スレーブ マシン プロセスが開始されると、「同期コマンド」コマンドをマスター マシンに送信して同期接続を要求します。
2. 最初の接続であっても再接続であっても、マスター マシンはバックグラウンド プロセスを開始してデータ スナップショットをデータ ファイルに保存し (rdb 操作を実行)、またマスターはデータを変更するためのすべてのコマンドを記録してキャッシュします。データファイル。
3. バックグラウンド プロセスがキャッシュ操作を完了すると、マスター マシンはデータ ファイルをスレーブ マシンに送信し、スレーブ マシンはデータ ファイルをハードディスクに保存してメモリにロードし、次にマスター マシンがデータ ファイルをロードします。マシンはデータのすべての操作を変更し、一緒にスレーブ エンド マシンに送信します。スレーブに障害が発生してダウンタイムが発生した場合、通常に戻った後、自動的に再接続されます。
4. マスター マシンがスレーブ マシンからの接続を受信した後、完全なデータ ファイルをスレーブ マシンに送信します。マスターが複数のスレーブから同時に同期要求を受信した場合、マスターはバックグラウンドでプロセスを開始してデータを保存します。データ ファイルを作成し、それをすべてのスレーブ側マシンに送信して、すべてのスレーブ側マシンが正常であることを確認します。

2. Redis マスター/スレーブ レプリケーションを構築する

Master节点:192.168.80.10
Slave1节点:192.168.80.11
Slave2节点:192.168.80.12

2.1 Redis のインストール

//环境准备
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
sed -i 's/enforcing/disabled/' /etc/selinux/config

#修改内核参数
vim /etc/sysctl.conf
vm.overcommit_memory = 1
net.core.somaxconn = 2048

sysctl -p


//安装redis
yum install -y gcc gcc-c++ make

tar zxvf /opt/redis-7.0.9.tar.gz -C /opt/
cd /opt/redis-7.0.9
make
make PREFIX=/usr/local/redis install
#由于Redis源码包中直接提供了 Makefile 文件,所以在解压完软件包后,不用先执行 ./configure 进行配置,可直接执行 make 与 make install 命令进行安装。

2.2 Redis 作業ディレクトリの作成

mkdir /usr/local/redis/{conf,log,data}

cp /opt/redis-7.0.9/redis.conf /usr/local/redis/conf/

useradd -M -s /sbin/nologin redis
chown -R redis.redis /usr/local/redis/

2.3 環境変数

vim /etc/profile 
PATH=$PATH:/usr/local/redis/bin		#增加一行

source /etc/profile

2.4 systemd サービス管理スクリプトの定義

vim /usr/lib/systemd/system/redis-server.service
[Unit]
Description=Redis Server
After=network.target

[Service]
User=redis
Group=redis
Type=forking
TimeoutSec=0
PIDFile=/usr/local/redis/log/redis_6379.pid
ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

2.5 Redis設定ファイルの変更(マスターノードの操作)

vim /usr/local/redis/conf/redis.conf
bind 0.0.0.0									#87行,修改监听地址为0.0.0.0
protected-mode no								#111行,将本机访问保护模式设置no
port 6379										#138行,Redis默认的监听6379端口
daemonize yes									#309行,设置为守护进程,后台启动
pidfile /usr/local/redis/log/redis_6379.pid		#341行,指定 PID 文件
logfile "/usr/local/redis/log/redis_6379.log"	#354行,指定日志文件
dir /usr/local/redis/data						#504行,指定持久化文件所在目录
#requirepass abc123								#1037行,可选,设置redis密码
appendonly yes									#1380行,开启AOF


systemctl restart redis-server.service

2.6 Redis設定ファイルの変更(スレーブノード操作)

vim /usr/local/redis/conf/redis.conf
bind 0.0.0.0									#87行,修改监听地址为0.0.0.0
protected-mode no								#111行,将本机访问保护模式设置no
port 6379										#138行,Redis默认的监听6379端口
daemonize yes									#309行,设置为守护进程,后台启动
pidfile /usr/local/redis/log/redis_6379.pid		#341行,指定 PID 文件
logfile "/usr/local/redis/log/redis_6379.log"	#354行,指定日志文件
dir /usr/local/redis/data						#504行,指定持久化文件所在目录
#requirepass abc123								#1037行,可选,设置redis密码
appendonly yes									#1380行,开启AOF
replicaof 192.168.80.10 6379					#528行,指定要同步的Master节点IP和端口
#masterauth abc123								#535行,可选,指定Master节点的密码,仅在Master节点设置了requirepass


systemctl restart redis-server.service

2.7 マスタースレーブ効果を検証する

在Master节点上看日志:
tail -f /usr/local/redis/log/redis_6379.log 
Replica 192.168.80.11:6379 asks for synchronization
Replica 192.168.80.12:6379 asks for synchronization
Synchronization with replica 192.168.80.11:6379 succeeded
Synchronization with replica 192.168.80.12:6379 succeeded

在Master节点上验证从节点:
redis-cli info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.80.11,port=6379,state=online,offset=1246,lag=0
slave1:ip=192.168.80.12,port=6379,state=online,offset=1246,lag=1

ここに画像の説明を挿入
ここに画像の説明を挿入

ここに画像の説明を挿入
ここに画像の説明を挿入

3.Redisセンチネルモード

3.1 セントリーモードとは

  • マスター/スレーブ切り替え技術の方式は、サーバーがダウンした場合、手動でスレーブ マシンをマスター マシンに切り替える必要があり、手動による介入が必要であり、時間と労力がかかるだけでなく、サービスの停止にもつながります。一定期間利用できなくなること。マスター/スレーブ レプリケーションの欠点を解決するために、センチネル メカニズムがあります。

  • Sentinel のコア機能: Sentinel は、マスター/スレーブ レプリケーションに基づいて、マスター ノードの自動フェイルオーバーを導入します。

3.2 センチネルモードの役割

1. 監視: Sentinel はマスターノードとスレーブノードが正常に動作しているかどうかを常にチェックします。

2. 自動フェイルオーバー: マスター ノードが正常に動作しない場合、Sentinel は自動フェイルオーバー操作を開始し、障害が発生したマスター ノードのスレーブ ノードの 1 つを新しいマスター ノードにアップグレードし、他のスレーブ ノードに新しいマスターをコピーさせます。ノード、ノード。

3. 通知 (リマインダー): Sentinel はフェイルオーバーの結果をクライアントに送信できます。

3.3 センチネル構造は、センチネル ノードとデータ ノードの 2 つの部分で構成されます。

1. Sentinel ノード: Sentinel システムは、データを保存しない特別な Redis ノードである 1 つ以上の Sentinel ノードで構成されます。
2. データノード: マスターノードとスレーブノードは両方ともデータノードです。

3.4 フェイルオーバーメカニズム

1. 各センチネル ノードは、ハートビート検出のために 1 秒ごとにマスター ノード、スレーブ ノード、および他のセンチネル ノードに ping コマンドを送信します。マスター ノードが特定の時間枠内に応答しない場合、またはエラー メッセージで応答した場合、センチネルはマスター ノードが主観的に (一方的に) オフラインであるとみなします。センチネル ノードの半数以上が主観的にマスター ノードがオフラインであると考える場合、客観的にはオフラインです。

2. マスター ノードに障害が発生すると、センチネル ノードは Raft アルゴリズム (選挙アルゴリズム) を通じて選挙メカニズムを実装し、マスター ノードのフェイルオーバーと通知の処理を担当するリーダーとしてセンチネル ノードを共同で選出します。したがって、Sentinel を実行するクラスターの数は 3 ノード以上である必要があります。

3. フェールオーバーはリーダー センチネル ノードによって実行され、プロセスは次のとおりです:
(1) 特定のスレーブ ノードを新しいマスター ノードにアップグレードし、他のスレーブ ノードが新しいマスター ノードを指すようにします。
(2) 元のノードがマスター ノードが回復すると、スレーブ ノードにもなり、新しいプライマリ ノードをポイントします;
(3) プライマリ ノードが交換されたことをクライアントに通知します。

需要特别注意的是,客观下线是主节点才有的概念;如果从节点和哨兵节点发生故障,被哨兵主观下线后,不会再有后续的客观下线和故障转移操作。

3.5 マスターノードの選択

1. センチネルの ping 応答に応答しない、異常な (オフラインの) スレーブ ノードをフィルターで除外します。
2. 設定ファイル内で最も優先度の高い設定を持つスレーブ ノードを選択します。(replica-priority、デフォルト値は 100)
3. 最大のレプリケーション オフセットを持つスレーブ ノード、つまり最も完全なレプリケーションを選択します。

哨兵的启动依赖于主从模式,所以须把主从模式安装好的情况下再去做哨兵模式

4. Redis センチネル モードを構築する

Master节点:192.168.80.10
Slave1节点:192.168.80.11
Slave2节点:192.168.80.12

systemctl stop firewalld
setenforce 0

4.1 Redisセンチネルモードの設定ファイルの変更(全ノード操作)

cp /opt/redis-7.0.9/sentinel.conf /usr/local/redis/conf/
chown redis.redis /usr/local/redis/conf/sentinel.conf

vim /usr/local/redis/conf/sentinel.conf
protected-mode no									#6行,关闭保护模式
port 26379											#10行,Redis哨兵默认的监听端口
daemonize yes										#15行,指定sentinel为后台启动
pidfile /usr/local/redis/log/redis-sentinel.pid		#20行,指定 PID 文件
logfile "/usr/local/redis/log/sentinel.log"			#25行,指定日志存放路径
dir /usr/local/redis/data							#54行,指定数据库存放路径
sentinel monitor mymaster 192.168.80.10 6379 2		#73行,修改 指定该哨兵节点监控192.168.80.10:6379这个主节点,该主节点的名称是mymaster,最后的2的含义与主节点的故障判定有关:至少需要2个哨兵节点同意,才能判定主节点故障并进行故障转移
#sentinel auth-pass mymaster abc123					#76行,可选,指定Master节点的密码,仅在Master节点设置了requirepass
sentinel down-after-milliseconds mymaster 3000		#114行,判定服务器down掉的时间周期,默认30000毫秒(30秒)
sentinel failover-timeout mymaster 180000			#214行,同一个sentinel对同一个master两次failover之间的间隔时间(180秒)

4.2 セントリーモードの開始

先启master,再启slave
cd /usr/local/redis/conf/
redis-sentinel sentinel.conf &

4.3 センチネル情報の表示

redis-cli -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.80.10:6379,slaves=2,sentinels=3

4.4 故障シミュレーション

#查看redis-server进程号:
ps -ef | grep redis
root      57031      1  0 15:20 ?        00:00:07 /usr/local/bin/redis-server 0.0.0.0:6379
root      57742      1  1 16:05 ?        00:00:07 redis-sentinel *:26379 [sentinel]
root      57883  57462  0 16:17 pts/1    00:00:00 grep --color=auto redis

#杀死 Master 节点上redis-server的进程号
kill -9 57031			#Master节点上redis-server的进程号

4.5 検証結果

tail -f /usr/local/redis/log/sentinel.log
6709:X 13 Mar 2023 12:27:29.517 # +sdown master mymaster 192.168.80.10 6379
6709:X 13 Mar 2023 12:27:29.594 * Sentinel new configuration saved on disk
6709:X 13 Mar 2023 12:27:29.594 # +new-epoch 1
6709:X 13 Mar 2023 12:27:29.595 * Sentinel new configuration saved on disk
6709:X 13 Mar 2023 12:27:29.595 # +vote-for-leader c64fac46fcd98350006900c330998364d6af635d 1
6709:X 13 Mar 2023 12:27:29.620 # +odown master mymaster 192.168.80.10 6379 #quorum 2/2
6709:X 13 Mar 2023 12:27:29.621 # Next failover delay: I will not start a failover before Mon Mar 13 12:33:30 2023
6709:X 13 Mar 2023 12:27:30.378 # +config-update-from sentinel c64fac46fcd98350006900c330998364d6af635d 192.168.80.11 26379 @ mymaster 192.168.80.10 6379
6709:X 13 Mar 2023 12:27:30.378 # +switch-master mymaster 192.168.80.10 6379 192.168.80.11 6379
6709:X 13 Mar 2023 12:27:30.378 * +slave slave 192.168.80.13:6379 192.168.80.13 6379 @ mymaster 192.168.80.11 6379
6709:X 13 Mar 2023 12:27:30.378 * +slave slave 192.168.80.10:6379 192.168.80.10 6379 @ mymaster 192.168.80.11 6379
6709:X 13 Mar 2023 12:27:30.381 * Sentinel new configuration saved on disk
6709:X 13 Mar 2023 12:27:33.379 # +sdown slave 192.168.80.10:6379 192.168.80.10 6379 @ mymaster 192.168.80.11 6379


2.redis-cli -p 26379 INFO Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_tilt_since_seconds:-1
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.80.11:6379,slaves=2,sentinels=3

ここに画像の説明を挿入
ここに画像の説明を挿入
ここに画像の説明を挿入

5、Redisクラスターモード

5.1 Redis クラスター

  • クラスター、つまり Redis クラスターは、R​​edis 3.0 によって導入された分散ストレージ ソリューションです。

  • クラスターは複数のノード グループ (ノード) で構成され、Redis データはこれらのノード間に分散されます。クラスター内のノードはマスター ノードとスレーブ ノードに分割されます。マスター ノードのみが読み取りおよび書き込みリクエストとクラスター情報のメンテナンスを担当し、スレーブ ノードはマスター ノードのデータとステータス情報のみを複製します。

5.2 クラスターの役割

1. データ パーティショニング: データ パーティショニング (またはデータ シャーディング) は、クラスターの中核機能です。
クラスターはデータを複数のノードに分散します。一方で、Redis 単一マシンのメモリー サイズの制限を突破し、ストレージ容量が大幅に増加します。他方、各マスター ノードは外部の読み取りおよび書き込みサービスを提供でき、これにより、クラスターの応答性が大幅に向上します。
Redis スタンドアロンのメモリ サイズは制限されており、これは永続性とマスター/スレーブ レプリケーションの紹介で説明したとおりです。その結果、スレーブ ノードは長時間サービスを提供できなくなり、マスター ノードのレプリケーション バッファーがオーバーフローする可能性があります。完全なレプリケーションフェーズ。
2. 高可用性: クラスターは、マスター/スレーブ レプリケーションとマスター ノードの自動フェイルオーバー (Sentinel と同様) をサポートしており、いずれかのノードに障害が発生しても、クラスターは引き続き外部サービスを提供できます。

5.3 Redis クラスターのデータ断片化

1. Redis クラスターにはハッシュ スロットの概念が導入されています2. 。16384
Redis クラスターには 16384 個のハッシュ スロット (番号 0 ~ 16383) があります

  • 3 つのノードで構成されるクラスターを例に挙げます。
    ノード A にはハッシュ スロット 0 ~ 5460 が含まれます。
    ノード B にはハッシュ スロット 5461 ~ 10922 が含まれます。 ノード
    C にはハッシュ スロット 10923 ~ 16383 が含まれます。
    redis-cluster集群会用crc16算法对键进行换算,之后会得到一个数字,在用这个数字除以16384取余数,余数对应的Hash槽数值在哪个节点范围内,那么客户端输入的命令就会在哪个节点进行处理

5.4 Redis クラスターのマスター/スレーブ レプリケーション モデル

  • クラスターには 3 つのノード A、B、C があります。ノード B に障害が発生すると、5461 ~ 10922 の範囲のスロットが不足するため、クラスター全体が使用できなくなります。
  • 各ノードにスレーブ ノード A1、B1、および C1 を追加すると、クラスター全体は 3 つのマスター ノードと 3 つのスレーブ ノードで構成されます。ノード B に障害が発生した後、クラスターはサービスを継続するために B1 を持つマスター ノードを選択します。B と B1 の両方に障害が発生すると、クラスターは使用できなくなります。

6. Redisクラスターモードの構築

redis的集群一般需要6个节点,3主3从。方便起见,这里所有节点在同一台服务器上模拟:
以端口号进行区分:3个主节点端口号:6001/6002/6003,对应的从节点端口号:6004/6005/6006。
cd /usr/local/redis/
mkdir -p redis-cluster/redis600{1..6}

for i in {1..6}
do
cp /opt/redis-7.0.9/redis.conf /usr/local/redis/redis-cluster/redis600$i
cp /opt/redis-7.0.9/src/redis-cli /opt/redis-7.0.9/src/redis-server /usr/local/redis/redis-cluster/redis600$i
done

6.1 クラスタ機能をオンにする

#其他5个文件夹的配置文件以此类推修改,注意6个端口都要不一样。
cd /usr/local/redis/redis-cluster/redis6001
vim redis.conf
#bind 127.0.0.1									#87行,注释掉bind项,默认监听所有网卡
protected-mode no								#111行,关闭保护模式
port 6001										#138行,修改redis监听端口
daemonize yes									#309行,设置为守护进程,后台启动
pidfile /usr/local/redis/log/redis_6001.pid		#341行,指定 PID 文件
logfile "/usr/local/redis/log/redis_6001.log"	#354行,指定日志文件
dir ./											#504行,指定持久化文件所在目录
appendonly yes									#1379行,开启AOF
cluster-enabled yes								#1576行,取消注释,开启群集功能
cluster-config-file nodes-6001.conf				#1584行,取消注释,群集名称文件设置
cluster-node-timeout 15000						#1590行,取消注释群集超时时间设置

6.2 Redis ノードの起動

分别进入那六个文件夹,执行命令:redis-server redis.conf ,来启动redis节点
cd /usr/local/redis/redis-cluster/redis6001
redis-server redis.conf

for d in {1..6}
do
cd /usr/local/redis/redis-cluster/redis600$d
./redis-server redis.conf
done

ps -ef | grep redis

6.3 クラスタの起動

redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
#六个实例分为三组,每组一主一从,前面的做主节点,后面的做从节点。下面交互的时候 需要输入 yes 才可以创建。
--replicas 1 表示每个主节点有1个从节点。

6.4 テストクラスター

redis-cli -p 6001 -c					#加-c参数,节点之间就可以互相跳转
127.0.0.1:6001> cluster slots			#查看节点的哈希槽编号范围
1) 1) (integer) 5461
   2) (integer) 10922									#哈希槽编号范围
   3) 1) "127.0.0.1"
      2) (integer) 6003									#主节点IP和端口号
      3) "fdca661922216dd69a63a7c9d3c4540cd6baef44"
   4) 1) "127.0.0.1"
      2) (integer) 6004									#从节点IP和端口号
      3) "a2c0c32aff0f38980accd2b63d6d952812e44740"
2) 1) (integer) 0
   2) (integer) 5460
   3) 1) "127.0.0.1"
      2) (integer) 6001
      3) "0e5873747a2e26bdc935bc76c2bafb19d0a54b11"
   4) 1) "127.0.0.1"
      2) (integer) 6006
      3) "8842ef5584a85005e135fd0ee59e5a0d67b0cf8e"
3) 1) (integer) 10923
   2) (integer) 16383
   3) 1) "127.0.0.1"
      2) (integer) 6002
      3) "816ddaa3d1469540b2ffbcaaf9aa867646846b30"
   4) 1) "127.0.0.1"
      2) (integer) 6005
      3) "f847077bfe6722466e96178ae8cbb09dc8b4d5eb"

127.0.0.1:6001> set name zhangsan
-> Redirected to slot [5798] located at 127.0.0.1:6003
OK

127.0.0.1:6001> cluster keyslot name					#查看name键的槽编号

redis-cli -p 6004 -c
127.0.0.1:6004> keys *							#对应的slave节点也有这条数据,但是别的节点没有
1) "name"


redis-cli -p 6001 -c cluster nodes

ここに画像の説明を挿入

ここに画像の説明を挿入

ここに画像の説明を挿入

ここに画像の説明を挿入
ここに画像の説明を挿入
ここに画像の説明を挿入

ここに画像の説明を挿入

おすすめ

転載: blog.csdn.net/2301_76875445/article/details/131477589