1. 程式人生 > >主從 + sentinel 實現redis的高可用

主從 + sentinel 實現redis的高可用

redis提供主從模式(也就是複製replication), 如果不太清楚主從搭建過程的請參考之前部落格, 一主多從這種模式只是將讀寫進行了分類,如果主發生了故障,整個redis系統都將變的不可用. 然而redis 引進了哨兵, 哨兵可以獨立與redis執行的分散式服務. 提供redis實時監控和故障檢測恢復的功能. 不瞭解哨兵特性的可參考之前關於哨兵的部落格.

這裡記錄主從搭配合作實現redis的高可用(HA).

實戰圖解

       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |
+----+ | R2 |----+----| R3 | | S2 | | S3 | +----+ +----+ Configuration: quorum = 2

我們都知道哨兵的啟動方式:

redis-sentinel /path/to/sentinel_6379.conf --sentinel 

redis 版本

使用版本是3.2.1

27.0.0.1:6381> 
127.0.0.1:6381> info server
# Server
redis_version:3.2.1
redis_git_sha1:00000000
redis_git_dirty
:0 redis_build_id:b3132c8ce7b475fa redis_mode:standalone os:Linux 3.13.0-32-generic x86_64 arch_bits:64 multiplexing_api:epoll

配置哨兵

自定義建立三個哨兵配置檔案,這裡使用

sentinel_26379.conf

sentinel_26380.conf

sentinel_26381.conf

配置內容如下:

port 26379

sentinel monitor mymaster 127.0.0.1 6381 2

sentinel down-after
-milliseconds mymaster 5000 # master 有密碼就要使用, sentinel auth-pass mymaster **** sentinel failover-timeout resque 180000. sentinel parallel-syncs resque 5

其他兩個,埠換下就好.

配置啟動指令碼檔案

建立哨兵啟動指令碼,sentinel_26379; sentinel_26380; sentinel_26381;

詳細內容如下:

#!/bin/sh
#
# Simple Redis init.d script conceived to work on Linux systems
# as it does use of the /proc filesystem.


 redis-sentinel /path/to/sentinel_26379.conf --sentinel &


esac

驗證執行狀態

分別啟動三個哨兵.

登陸6381(master),關閉 shutdown redis

宕機前的redis 主從狀態:

[email protected]:~/programs# redis-cli -p 6381
127.0.0.1:6381> 
127.0.0.1:6381> auth *****
OK
127.0.0.1:6381> 
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6379,state=online,offset=1446113,lag=1
slave1:ip=127.0.0.1,port=6380,state=online,offset=1446113,lag=1
master_repl_offset:1446262
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:397687
repl_backlog_histlen:1048576
127.0.0.1:6381> 

執行關閉

127.0.0.1:6381> 
127.0.0.1:6381> 
127.0.0.1:6381> shutdown save
not connected> 
not connected> 

監控哨兵的列印狀態:

2078:X 28 Jul 19:50:11.967 # +sdown master mymaster 127.0.0.1 6381
2078:X 28 Jul 19:50:12.108 # +new-epoch 28
2078:X 28 Jul 19:50:12.175 # +vote-for-leader 1d9a0fc928f84a79b2e2aaa686db2ae735b6958d 28
2078:X 28 Jul 19:50:13.026 # +odown master mymaster 127.0.0.1 6381 #quorum 3/2
2078:X 28 Jul 19:50:13.026 # Next failover delay: I will not start a failover before Thu Jul 28 19:56:13 2016
2078:X 28 Jul 19:50:13.261 # +config-update-from sentinel 1d9a0fc928f84a79b2e2aaa686db2ae735b6958d 127.0.0.1 26380 @ mymaster 127.0.0.1 6381
2078:X 28 Jul 19:50:13.261 # +switch-master mymaster 127.0.0.1 6381 127.0.0.1 6380
2078:X 28 Jul 19:50:13.261 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
2078:X 28 Jul 19:50:13.262 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
2078:X 28 Jul 19:50:18.279 # +sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

根據上面資訊可以看到: 其中一個哨兵發現6381 主觀下線, 然後發起了新的一輪投票;
quorum3/2 三個哨兵都認為6381下線了。然後啟動了故障恢復, 最終選舉6380為的主.

測試在登陸到6380 檢視執行資訊;

127.0.0.1:6381> shutdown save
not connected> 
not connected> 
not connected> 
not connected> quit
root@ubuntu:~/programs# 
root@ubuntu:~/programs# redis-cli -p 6380
127.0.0.1:6380> auth ****
OK
127.0.0.1:6380> 
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=56725,lag=0
master_repl_offset:56860
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:56859
127.0.0.1:6380> 

可以看到6380已經是master,而且有一個從6379; 然後我們將6381重新啟動,看是否它加入到新的master-6380下麼.

127.0.0.1:6380> 
127.0.0.1:6380> quit
root@ubuntu:~/programs# 
root@ubuntu:~/programs# /etc/init.d/redis_6380 start
/var/run/redis_6380.pid exists, process is already running or crashed
root@ubuntu:~/programs# 
root@ubuntu:~/programs# 
root@ubuntu:~/programs# /etc/init.d/redis_6381 start
Starting Redis server...
root@ubuntu:~/programs# 
root@ubuntu:~/programs# redis-cli -p 6380
127.0.0.1:6380> auth ****
OK
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6379,state=online,offset=91546,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=91560,lag=0
master_repl_offset:91560
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:91559
127.0.0.1:6380> 

可以看到6381已經是6380的從機了.

在6381啟動過程中哨兵監控的內容

2104:X 28 Jul 19:57:38.988 # -sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
2104:X 28 Jul 19:57:48.947 * +convert-to-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

6381啟動好了,客觀認為6381不在是主,直接將角色轉換成了6380的從機.

此時redis 主從 + 哨兵 實現高可用方案搭建完畢.

繼續將6380宕機,監控如下:

2104:X 28 Jul 20:04:01.733 # +new-epoch 29
2104:X 28 Jul 20:04:01.767 # +vote-for-leader b24714af31039c93f6ad4173c059c4d11e86f302 29
2104:X 28 Jul 20:04:01.767 # +odown master mymaster 127.0.0.1 6380 #quorum 2/2
2104:X 28 Jul 20:04:01.767 # Next failover delay: I will not start a failover before Thu Jul 28 20:10:02 2016
2104:X 28 Jul 20:04:02.801 # +config-update-from sentinel b24714af31039c93f6ad4173c059c4d11e86f302 127.0.0.1 26379 @ mymaster 127.0.0.1 6380
2104:X 28 Jul 20:04:02.801 # +switch-master mymaster 127.0.0.1 6380 127.0.0.1 6381
2104:X 28 Jul 20:04:02.801 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
2104:X 28 Jul 20:04:02.801 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
2104:X 28 Jul 20:04:07.834 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381

歡迎大家評論,吐槽

相關推薦

Spring Boot Redis-Sentinel實現Redis可用之哨兵模式

廢話簡論     Redis高可用之哨兵模式它就是,當你的reids掛掉了之後,它可以自己切換到其他redis上.不影響使用者的正常使用. 簡述Sentinel:      Sentinel具有四個特點: 監控,通知,自動故障轉移,配置提供者 監控:哨兵不斷的檢查ma

實現redis可用主從sentinel

redis sentinel redis主從 redis高可用 sentinel作用 監控(Monitoring): Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。 提醒(Notification): 當被監控的某個 Redis 服務器出現問題時, Sentinel 可以

主從 + sentinel 實現redis可用

redis提供主從模式(也就是複製replication), 如果不太清楚主從搭建過程的請參考之前部落格, 一主多從這種模式只是將讀寫進行了分類,如果主發生了故障,整個redis系統都將變的不可用. 然而redis 引進了哨兵, 哨兵可以獨立與redis執行的分

Sentinel 哨兵-實現Redis可用

客戶端連接 信息 客戶 redis 分布 nds 的確 mic sof 概述Redis哨兵為Redis提供了高可用性。實際上這意味著你可以使用哨兵模式創建一個可以不用人為幹預而應對各種故障的Redis部署。哨兵模式還提供了其他的附加功能,如監控,通知,為客戶端提供配置。下面

基於Sentinel(哨兵)搭建實現Redis可用叢集

概述 Redis哨兵為Redis提供了高可用性。實際上這意味著你可以使用哨兵模式建立一個可以不用人為干預而應對各種故障的Redis部署。 哨兵模式還提供了其他的附加功能,如監控,通知,為客戶端提供配置。 下面是在巨集觀層面上哨兵模式的功能列表: 監控:哨兵不斷的檢查mast

利用redis-sentinel+keepalived實現redis可用

目標、需求: 為上層應用提供高可靠、低延遲、低(無限接近0)資料損失的Redis快取服務 方案概述: 採用同一網路內的三臺主機(可以是物理主機、虛擬機器或docker容器),要求三臺主機之間都能相互訪問,每一臺主機上都安裝redis-server、redis-sen

Redis 可用 基於Sentinel + keepalived 實現

mas oba 保持 pan 分享 是否 因此 遇到 req 1 概述redis作為緩存工具,如果僅僅單機,一旦掛掉,將對業務造成嚴重的影響,因此建議生產環境上部署redis高可用環境,本文將基於Sentinel + keepalived 實現redis的高可用。本文主要

Redis 可用Redis Sentinel 主從複製故障轉移

Redis Sentinel  為 Redis 提供了高可用,可對複製叢集中進行監控、通知、故障轉移。 伺服器名稱:Centos222 , ip :192.168.1.222 ,主從角色:master 伺服器名稱:Centos224 , ip :192.168.1.22

採用 redis主從 + 哨兵(sentinel) + vip漂移搭建一套redis可用叢集

一、單個例項 當系統中只有一臺redis執行時,一旦該redis掛了,會導致整個系統無法執行。 單個例項 二、備份 由於單臺redis出現單點故障,就會導致整個系統不可用,所以想到的辦法自然就是備份(一般工業界認為比較安全的備份數應該是3份)。當一臺redis出現問題了,另一臺

利用Sentinel實現Redis主從切換

edi nbsp ilo bind redis poc 自主 日誌 sent 利用Sentinel(哨兵)實現Redis集群的故障自主切換 首先部署redis主從集群,這裏忽略過程,主要看配置文件: master: bind 0.0.0.0 port 6801 log

使用Keepalived配置主從熱備實現Nginx可用(HA)

_id keep 過去 基礎 inter icmp interval RR 轉發 Keepalived 簡要介紹 Keepalived 是一種高性能的服務器高可用或熱備解決方案,Keepalived 可以用來防止服務器單點故障的發生,通過配合 Nginx 可以實現 w

Redis可用方案哨兵機制------ 配置文件sentinel.conf詳解

有一個 發生 sim 超時時間 style 通信 配置文件 針對性 mas redis的哨兵機制是官方推薦的一種高可用(HA)方案,我們在使用Redis的主從結構時,如果主節點掛掉,這時是不能自動進行主備切換和通知客戶端主節點下線的。Redis-Sentinel機制主要用三

Memcached+keepalived+magent實現主從復制和可用

flags gre makefile 主從復制 http ffffff 緩存服務 oca color Memcached+keepalived+magent實現主從復制和高可用 實驗介紹 memcached之前並不能直接通信,所以memcached本身並不能完整備份所有的數

Redis主從復制與可用方案

安裝配置 失敗 tle nap 腳本 登錄 上線 集群 masters redis簡單介紹 Redis 是完全開源免費的,遵守BSD協議,是一個高性能的key-value數據庫。Redis與其他key – value緩存產品有以下三個特點: 支持數據的持久化,可以將內存中

Redis可用復制集群實現

priority emc 第一條 top 主服務器 filename byte 並行復制 加載 redis簡單介紹 Redis 是完全開源免費的,遵守BSD協議,是一個高性能的key-value數據庫。Redis 與其他 key - value 緩存產品有以下三個特點:

(六)java與redis可用,java連線哨兵sentinel原理

先來看下java連線redis主從結構圖: redis主從 需要在java中指定讀和寫redis源,而且是固定的,當主節點宕機之後,整個redis將不能使用,有明顯的單點問題。 使用sentinel哨兵之後為: Senti

Java架構學習(三十)redis高階&redis可用&主從複製&讀寫分離&叢集&哨兵機制&持久化RDB儲存&持久化AOF儲存&事務機制&Redis釋出訂閱

redis高階 一、基礎回顧 什麼是redis? 答:redis是非關係型資料庫,使用redis的目的是:減輕資料庫訪問壓力。 資料庫是做IO操作,使用redis是記憶體操作,記憶體資料庫, 效率要比IO效率高。這個就是快取。 如果資料庫值與redis

深入理解Redis可用方案-Sentinel

Redis Sentinel是Redis的高可用方案。是Redis 2.8中正式引入的。 在之前的主從複製方案中,如果主節點出現問題,需要手動將一個從節點升級為主節點,然後將其它從節點指向新的主節點,並且需要修改應用方主節點的地址。整個過程都需要人工干預。 下面通過日誌具體看看Sentinel的切換流

Redis可用sentinel

1.sentine介紹 Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案,當用Redis做Master-slave的高可用方案時,假如master宕機了,Redis本身(包括它的很多客戶端)都沒有實現自動進行主備切換,而Redis-sentinel本身也是一個獨立執行的程序,它能監

Redis可用叢集-哨兵模式(Redis-Sentinel)搭建配置教程【Windows環境】

No cross,no crown . 不經歷風雨,怎麼見彩虹。 Redis哨兵模式,用現在流行的話可以說就是一個“哨兵機器人”,給“哨兵機器人”進行相應的配置之後,這個”機器人”可以7*24小時工作,它能能夠自動幫助你做一些事情,如監控,提醒,自動處