Redis中主、从库宕机如何恢复?

Redis中主、从库宕机如何恢复?

大家好,又见面了,我是全栈君。

1、什么是哨兵

哨兵是对Redis的系统的运行情况的监控,它是一个独立进程,功能有二个:

  • 监控主数据库和从数据库是否运行正常;

  • 主数据出现故障后自动将从数据库转化为主数据库;

2、原理

单个哨兵的架构:

Redis中主、从库宕机如何恢复?

多个哨兵的架构:

Redis中主、从库宕机如何恢复?

多个哨兵,不仅同时监控主从数据库,而且哨兵之间互为监控。

多个哨兵,防止哨兵单点故障。

3、环境

当前处于一主多从的环境中:

Redis中主、从库宕机如何恢复?

4、设置哨兵

启动哨兵进程首先需要创建哨兵配置文件:

vim sentinel.conf

输入内容:

sentinel monitor taotaoMaster 127.0.0.1 6379 1

说明:

  • taotaoMaster:监控主数据的名称,自定义即可,可以使用大小写字母和“.-_”符号

  • 127.0.0.1:监控的主数据库的IP

  • 6379:监控的主数据库的端口

  • 1:最低通过票数

启动哨兵进程:

redis-sentinel ./sentinel.conf

Redis中主、从库宕机如何恢复?

由上图可以看到:

  • 哨兵已经启动,它的id为9059917216012421e8e89a4aa02f15b75346d2b7

  • 为master数据库添加了一个监控

  • 发现了2个slave(由此可以看出,哨兵无需配置slave,只需要指定master,哨兵会自动发现slave)

5、从宕机及恢复

Redis中主、从库宕机如何恢复?

kill掉2826进程后,30秒后哨兵的控制台输出:

2989:X 05 Jun 20:09:33.509 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379

说明已经监控到slave宕机了,那么,如果我们将3380端口的redis实例启动后,会自动加入到主从复制吗?

2989:X 05 Jun 20:13:22.716 * +reboot slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379

2989:X 05 Jun 20:13:22.788 # -sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379

可以看出,slave从新加入到了主从复制中。-sdown:说明是恢复服务。

Redis中主、从库宕机如何恢复?

6、主宕机及恢复

哨兵控制台打印出如下信息:

2989:X 05 Jun 20:16:50.300 # +sdown master taotaoMaster 127.0.0.1 6379  说明master服务已经宕机

2989:X 05 Jun 20:16:50.300 # +odown master taotaoMaster 127.0.0.1 6379 #quorum 1/1 

2989:X 05 Jun 20:16:50.300 # +new-epoch 1

2989:X 05 Jun 20:16:50.300 # +try-failover master taotaoMaster 127.0.0.1 6379  开始恢复故障

2989:X 05 Jun 20:16:50.304 # +vote-for-leader 9059917216012421e8e89a4aa02f15b75346d2b7 1  投票选举哨兵leader,现在就一个哨兵所以leader就自己

2989:X 05 Jun 20:16:50.304 # +elected-leader master taotaoMaster 127.0.0.1 6379  选中leader

2989:X 05 Jun 20:16:50.304 # +failover-state-select-slave master taotaoMaster 127.0.0.1 6379 选中其中的一个slave当做master

2989:X 05 Jun 20:16:50.357 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ taotaoMaster 127.0.0.1 6379  选中6381

2989:X 05 Jun 20:16:50.357 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ taotaoMaster 127.0.0.1 6379  发送slaveof no one命令

2989:X 05 Jun 20:16:50.420 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ taotaoMaster 127.0.0.1 6379   等待升级master

2989:X 05 Jun 20:16:50.515 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ taotaoMaster 127.0.0.1 6379  升级6381为master

2989:X 05 Jun 20:16:50.515 # +failover-state-reconf-slaves master taotaoMaster 127.0.0.1 6379

2989:X 05 Jun 20:16:50.566 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379

2989:X 05 Jun 20:16:51.333 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379

2989:X 05 Jun 20:16:52.382 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379

2989:X 05 Jun 20:16:52.438 # +failover-end master taotaoMaster 127.0.0.1 6379 故障恢复完成

2989:X 05 Jun 20:16:52.438 # +switch-master taotaoMaster 127.0.0.1 6379 127.0.0.1 6381  主数据库从6379转变为6381

2989:X 05 Jun 20:16:52.438 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6381  添加6380为6381的从库

2989:X 05 Jun 20:16:52.438 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster 127.0.0.1 6381  添加6379为6381的从库

2989:X 05 Jun 20:17:22.463 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster 127.0.0.1 6381 发现6379已经宕机,等待6379的恢复

Redis中主、从库宕机如何恢复?

可以看出,目前,6381位master,拥有一个slave为6380.

接下来,我们恢复6379查看状态:

2989:X 05 Jun 20:35:32.172 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster 127.0.0.1 6381  6379已经恢复服务

2989:X 05 Jun 20:35:42.137 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster 127.0.0.1 6381  将6379设置为6381的slave

Redis中主、从库宕机如何恢复?

7、配置多个哨兵

vim sentinel.conf

输入内容:

sentinel monitor taotaoMaster1 127.0.0.1 6381 1

sentinel monitor taotaoMaster2 127.0.0.1 6381 2

Redis中主、从库宕机如何恢复?

blog.csdn.net/py_tamir/article/details/82555338

Redis中主、从库宕机如何恢复?

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/111455.html原文链接:https://javaforall.net

(0)
全栈程序员-站长的头像全栈程序员-站长


相关推荐

  • pycharm环境变量配置Anaconda_phpstorm怎么配置环境

    pycharm环境变量配置Anaconda_phpstorm怎么配置环境在Windows7系统中,安装并配置Spyder与Pycharm的Anaconda环境Python解释器方法

    2022年8月26日
    8
  • windows cmd切换盘符_cmd无法切换到d盘

    windows cmd切换盘符_cmd无法切换到d盘在win10中使用cmd命令行进行切换盘符操作时,碰到无反应的情况:解决方法:1.输入路径回车后,再次输入该盘符2.在cd与E:\之间加上/d:原因:windows命令行切换不同盘符时要加强制转换参数/d…

    2022年9月28日
    6
  • Pyinstaller打包exe完整教程

    Pyinstaller打包exe完整教程原创文|Space9Python文件打包成可安装、无需Python依赖的高效可执行exe程序工具及环境PyInstallerInnoSetupWindows和PythonPyInstaller打包Python应用程序为独立的可执行文件安装PyInstallerpypi镜像使用帮助https://mirrors.tuna.tsinghua.edu.cn/help/pypi/pipinstall-ihttps://pypi.tuna.tsinghua.edu.cn/simple

    2022年6月25日
    33
  • 计算机硬件基础知识试题[通俗易懂]

    计算机硬件基础知识试题1、通常计算机的存储器是由一个Cache、主存和辅存构成的三级存储体系。辅助存储器一般可由磁盘、磁带和光盘等存储设备组成。Cache和主存一般是一种__A__存储器,磁带则是一种__B__存储设备。在各种辅存中,除去__C__外,大多是便于脱卸和携带的。Cache存储器一般采用__D__半导体芯片,主存现在主要由__E__半导体芯片组成。A、B:①随机存取   ②

    2022年4月7日
    61
  • SAE J1939介绍

    SAE J1939介绍CAN协议最初由美国博世公司提出,后来SAE在CAN2.0B的基础之上提出J1939协议,该协议主要面向客车和载重货车。J1939协议对应ISO提出的七层OSI模型中的物理层、数据链路层、网络层和应用层,除了这四层,为了保证数据的准确传输和故障诊断,J1939还具有网络管理和应用层诊断。物理层对应J1939-11、J1939-15;数据链路层对应协议中的J1939-21;网络层对应协议中的

    2022年5月1日
    113
  • 木马GOP——盗QQ密码

    木马GOP——盗QQ密码 GOP是什么?GOP是GetOICQPassword的缩写,从这个名字我们就可以看出这是一个获取别人OICQ(现在应该称为QQ了)密码的木马软件!如果你还没有受到它的攻击,那可是幸运了,我认识它的过程可是代价惨重啊!  一天,我打开QQ,输入自己熟悉的密码后,静等着小企鹅的出现,谁知左等右等却等到了一个密码错误的提示窗口!再三确认自己的密码没有记错,当然也不会输错,那最大、最令人担心的可能

    2022年7月20日
    35

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号