Redisマスタースレーブレプリケーションとセンチネルモードの概要

その他 2021-01-25 06:06:06 訪問数: null

記事のディレクトリ

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

1.1概要

  • Redisは、読み取りと書き込みの速度が非常に速いですが、読み取り圧力が非常に高い状況も発生します。読み取りプレッシャーを共有するために、Redisはマスター/スレーブレプリケーションをサポートして、マスターデータベースのデータコンテンツがスレーブデータベースのコンテンツと完全に一致するようにします。

1.2Redis構造の分類

  • Redisのマスタースレーブ構造は、マスターマルチスレーブまたはカスケード構造を採用できます。
  • Redisマスタースレーブレプリケーションは、フル同期とインクリメンタル同期に分けられます。

ここに画像の説明を挿入

1.2.1Redisの完全同期

  • Redisの完全なレプリケーションは通常、スレーブの初期化フェーズで発生します。このとき、スレーブはマスター上のすべてのデータをコピーする必要があります。
  • 具体的な手順は次のとおりです。
从服务器连接主服务器，发送SYNC命令；
主服务器接收到sYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令。

ここに画像の説明を挿入

1.2.2Redisインクリメンタルレプリケーション

  • Redisインクリメンタルレプリケーションとは、スレーブが初期化されて正常に動作し始めたときに、マスターサーバーからスレーブサーバーへの書き込み操作を同期するプロセスを指します。・

  • インクリメンタルレプリケーションのプロセスは、主に、マスターサーバーが書き込みコマンドを実行するたびに同じ書き込みコマンドをスレーブサーバーに送信し、スレーブサーバーが受信した書き込みコマンドを受信して​​実行することです。

1.3マスター/スレーブ同期戦略

  • マスターとスレーブが接続されたばかりの場合は、完全同期を実行します。
  • 完全同期が終了したら、増分同期を実行します。
  • もちろん、必要に応じて、スレーブはいつでも完全同期を開始できます。redis戦略は、とにかく最初に増分同期を試行することです。失敗した場合、スレーブは完全同期を実行する必要があります。

2.Redisマスタースレーブレプリケーションをビルドします

  • プロジェクト環境
一台mater主服务器
IP：192.168.140.20
两台slave备选服务器
IP：192.168.140.21
IP：192.168.140.22

2.1サーバーでredis_serverサービスを開きます

注：プライマリサーバーとスタンバイサーバーでredisサービスをオンにする必要があります

发送所有会话，关闭防火墙
systemctl stop firewalld
setenforce 0
  • 次のソフトウェアパッケージを3つのサーバーすべてにインポートし、ルートディレクトリに配置します
    ここに画像の説明を挿入

2.1.1解凍してインストールする

[root@master ~]# tar zxvf redis-5.0.4.tar.gz
[root@master ~]# cd redis-5.0.4/
[root@master redis-5.0.4]# make
[root@master redis-5.0.4]# make PREFIX=/usr/local/redis install
[root@master redis-5.0.4]# cd

2.1.2リンクファイルを作成し、サービスを開始します

[root@master ~]# ln -s /usr/local/redis/bin/* /usr/local/bin/
[root@master ~]# cd redis-5.0.4/utils/
[root@master utils]# ./	//按table 查看相关命令
create-cluster/           graphs/                   hyperloglog/              lru/                      redis_init_script.tpl     speed-regression.tcl
generate-command-help.rb  hashtable/                install_server.sh         redis_init_script         releasetools/             whatisdoing.sh
[root@master utils]# ./install_server.sh
...//弹出的信息，按回车即可
[root@master utils]# netstat -anpt | grep redis
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      60219/redis-server

ここに画像の説明を挿入

2.2構成ファイルを変更する

  • メインサーバー上
[root@master ~]# vi /etc/redis/6379.conf 
...
69	bind 0.0.0.0	//修改监听地址为 0.0.0.0 (在实验环境使用)，现网环境建议绑定从服务器IP地址
136	daemonize yes	//开启守护进程
171	logfile /var/log/redis_6379.log	//修改日志文件目录
263	dir /var/lib/redis/6379	//修改工作目录
699	appendonly yes	//开启AOF持久化功能
  • 代替サーバーで、最初にメインサーバーと同じ機能を有効にしてから、次の構成を実行します
[root@slave1 ~]# vi /etc/redis/6379.conf 
...
replicaof 192.168.140.20 6379	//开启复制功能
[root@slave1 ~]# /etc/init.d/redis_6379 restart
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped
Starting Redis server...
  • メインサーバーのログを表示する
    ここに画像の説明を挿入

2.2マスターサーバー上のスレーブノードを確認します

  • データベースに接続し、メインサーバーのコンテンツを編集します
[root@master ~]# redis-cli		//连接数据库
127.0.0.1:6379> info replication	//查看节点信息
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.140.21,port=6379,state=online,offset=448,lag=1
slave1:ip=192.168.140.22,port=6379,state=online,offset=448,lag=1
master_replid:8e6ded5a687920d545a8133c8c0093d8e962056d
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:448
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:448
127.0.0.1:6379> set cp 9	//写入内容，并验证
OK
127.0.0.1:6379> get cp
"9"

ここに画像の説明を挿入

  • サーバーからマスターサーバーで編集されたコンテンツを確認します
[root@slave1 ~]# redis-cli
127.0.0.1:6379> get cp
"9"
127.0.0.1:6379>

2.3検証結果

  • マスターノードがダウンしたとき
[root@master ~]# /etc/init.d/redis_6379 stop
Stopping ...
Redis stopped

（1）スレーブノードでログを表示します。
ここに画像の説明を挿入
（2）マスターサーバーで編集したコンテンツが存在するかどうかをサーバーで表示します。

[root@slave1 ~]# redis-cli
127.0.0.1:6379> get cp
"9"
127.0.0.1:6379>

ここに画像の説明を挿入

  • この時点で、redisマスタースレーブが正常に構築されたことを意味します

  • 結論：Redisマスタースレーブレプリケーション。マスターサーバーに障害が発生しても、スタンバイサーバーは自動的に切り替えられません。データの読み取りは正常ですが、データの書き込みは問題を引き起こします。

3.セントリーモード

注意：哨兵模式，一定是基于redis主从复制模式下做的

3.1センチネルモードの原理

  • 歩哨は、マスタースレーブ構造の各サーバーを監視するために使用される分散システムです。障害が発生すると、投票メカニズムによって新しいマスターが選択され、すべてのスレーブが新しい​​マスターに接続されます。
  • したがって、センチネルを実行しているクラスター全体の数は3ノード以上である必要があります。

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

  • 監視
    マスターとスレーブが正常に動作しているかどうかを継続的にチェックします。
    マスターサバイバル検出、マスターとスレーブの実行ステータス検出。

  • 通知（リマインダー）
    監視対象サーバーに問題が発生した場合は、他のサーバー（センチネルルーム、クライアント）に通知を送信します。

  • 自動フェイルオーバー
    マスターとスレーブを切断し、1つのスレーブをマスターとして選択し、他のスレーブを新しいマスターに接続して、クライアントに新しいサーバーアドレスを通知します

補足：Sentinelもredisサーバーですが、データサービスを提供していません

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

  • 歩哨の起動はマスタースレーブモードに依存するため、マスタースレーブモードのインストール時に歩哨モードをインストールする必要があります。歩哨モードはすべてのノードに展開する必要があります。
  • センチネルモードは、すべてのredis作業ノードが正常であるかどうかを監視します。マスターに問題がある場合、他のノードがマスターノードとの接続を失うため、投票します。投票が投票の半分になった後、マスターに問題が発生すると、歩哨室に通知されます。新しいマスターとしてスレーブの1つを選択します。

3.4センチネル構成

3.4.1構成ファイルの編集

[root@master ~]# vi redis-5.0.4/sentinel.conf
17	protected-mode no		//关闭保护模式
26	daemonize yes		//指定sentinel为后台启动（开启守护进程）
36	logfile "/var/log/sentinel.log"	//指定日志存放路径
65	dir /var/lib/redis/6379		//指定数据库存放路径
84	sentinel monitor mymaster 192.168.140.20 6379 2	
		//至少几个哨兵检测到主服务器故障了，才会进行故障迁移(当主服务器故障，切换到slave为主服务器时，会将地址改为一个ID号)
113	sentinel down-after-milliseconds mymaster 3000	//判定服务器down掉的时间周期，默认30000毫秒(30S)
146	sentinel failover-timeout mymaster 180000	//故障节点的最大超时时间为180000(180秒)

3.4.2構成ファイルをスレーブサーバーにコピーします

[root@master ~]# scp redis-5.0.4/sentinel.conf root@192.168.140.21:/root/redis-5.0.4

ここに画像の説明を挿入

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

先启动master，再启slave
[root@master ~]# redis-sentinel redis-5.0.4/sentinel.conf &	//&表示在后台启动
[1] 63649

[root@slave1 ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 62327
[root@slave2 ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 60481

3.4.4センチネル情報を表示する

  • ビュー・ログ
[root@master ~]# tail -f /var/log/sentinel.log

ここに画像の説明を挿入

  • プロセスを表示
[root@master ~]# ps aux | grep sentinel
root      63650  0.2  0.1 153836  2668 ?        Ssl  17:23   0:01 redis-sentinel *:26379 [sentinel]
root      63739  0.0  0.0 112676   980 pts/1    S+   17:31   0:00 grep --color=auto sentinel
[root@master ~]# ps aux | grep redis
root      62860  0.1  0.1 156396  2800 ?        Ssl  16:03   0:06 /usr/local/bin/redis-server 0.0.0.0:6379
root      63650  0.2  0.1 153836  2668 ?        Ssl  17:23   0:01 redis-sentinel *:26379 [sentinel]
root      63742  0.0  0.0 112676   984 pts/1    S+   17:31   0:00 grep --color=auto redis

ここに画像の説明を挿入

  • 歩哨のステータスを表示する
[root@master ~]# redis-cli -h 192.168.140.20 -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.140.20:6379,slaves=2,sentinels=3

[root@master ~]# redis-cli -h 192.168.140.20 -p 6379 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.140.21,port=6379,state=online,offset=174385,lag=0
slave1:ip=192.168.140.22,port=6379,state=online,offset=174385,lag=0
master_replid:75cd6e32461f20e72b1ae7a09bffff02803fb9f9
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:174385
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:174385

3.5失敗をシミュレートする

  • メインサーバーでredisサービスを停止します
[root@master ~]# /etc/init.d/redis_6379 stop	 //停止redis服务

也可以用 kill 命令
kill -9 进程号

3.6検証結果

  • スレーブサーバーのログを表示する
[root@slave1 ~]# tail -f /var/log/sentinel.log

ここに画像の説明を挿入

[root@slave2 ~]# tail -f /var/log/sentinel.log

ここに画像の説明を挿入

[root@slave2 ~]# redis-cli -h 192.168.140.22 -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.140.22:6379,slaves=2,sentinels=3

ここに画像の説明を挿入

  • マスターサーバーが再起動したら、
    ログとセンチネルステータスを確認し、マスターがスレーブサーバーをプリエンプトしないことを確認します。
[root@master ~]# /etc/init.d/redis_6379 start

ここに画像の説明を挿入

ここに画像の説明を挿入

おすすめ

転載: blog.csdn.net/weixin_42449832/article/details/111353841
おすすめ
ランキング
uni.request在接口状态码403等还是走success
Springboot は mybatisplus を統合しており、ページング クエリによって返される Page オブジェクトの合計は常に 0 です。
System.InvalidOperationExceptionが：「BuildWindowCoreは、子ウィンドウのハンドル搭乗を返しません。」
[Example 08] IPD system advancement: version naming rules for version management
カスタム NavigationBar -- UIView による描画
データとデータの移行を復元します（個人的なメモ、無用リーダー）
4. 2次元配列で検索する
vim的私人订制
Flutterのカスタムルーティング切り替えアニメーション
Javaコンテナの方法の簡単なアプリケーションのArrayList
アーカイブ
もっと
2024-05-12(27)
2024-05-11(31)
2024-05-10(33)
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)
2024-05-04(18)
2024-05-03(8)

コードワールド

© 2018 codetd.com