redis學習十四、Redis主從複製

whpark發表於2020-12-31
Redis

十四、Redis主從複製

概念

主從複製，是指將一臺Redis伺服器的資料，複製到其他的Redis伺服器。前者稱為主節點 (master/leader)，後者稱為從節點(slave/follower)；資料的複製是單向的，只能由主節點到從節點。 Master以寫為主，Slave 以讀為主。

預設情況下，每臺Redis伺服器都是主節點； 且一個主節點可以有多個從節點(或沒有從節點)，但一個從節點只能有一個主節點。

主從複製的作用主要包括：

1、資料冗餘：主從複製實現了資料的熱備份，是持久化之外的一種資料冗餘方式。

2、故障恢復：當主節點出現問題時，可以由從節點提供服務，實現快速的故障恢復；實際上是一種服務 的冗餘。

3、負載均衡：在主從複製的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務 （即寫Redis資料時應用連線主節點，讀Redis資料時應用連線從節點），分擔伺服器負載；尤其是在寫 少讀多的場景下，通過多個從節點分擔讀負載，可以大大提高Redis伺服器的併發量。

4、高可用（叢集）基石：除了上述作用以外，主從複製還是哨兵和叢集能夠實施的基礎，因此說主從復 制是Redis高可用的基礎。

一般來說，要將Redis運用於工程專案中，只使用一臺Redis是萬萬不能的（當機），原因如下：

1、從結構上，單個Redis伺服器會發生單點故障，並且一臺伺服器需要處理所有的請求負載，壓力較 大；

2、從容量上，單個Redis伺服器記憶體容量有限，就算一臺Redis伺服器記憶體容量為256G，也不能將所有 記憶體用作Redis儲存記憶體，一般來說，單臺Redis最大使用記憶體不應該超過20G。

電商網站上的商品，一般都是一次上傳，無數次瀏覽的，說專業點也就是"多讀少寫"。

對於這種場景，我們可以使如下這種架構：

主從複製，讀寫分離！ 80% 的情況下都是在進行讀操作！減緩伺服器的壓力！架構中經常使用！ 一主 二從！ 只要在公司中，主從複製就是必須要使用的，因為在真實的專案中不可能單機使用Redis！

為什麼使用叢集

  1. 單臺伺服器難以負載大量的請求
  2. 單臺伺服器故障率高，系統崩壞概率大
  3. 單臺伺服器記憶體容量有限。

環境配置

在瞭解配置檔案的時候，注意到有一個replication模組,就是負責主從複製的。

檢視當前庫的資訊：info replication

127.0.0.1:6379> info replication
# Replication
role:master # 角色
connected_slaves:0 # 從機數量
master_replid:3b54deef5b7b7b7f7dd8acefa23be48879b4fcff
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

既然需要啟動多個服務，就需要多個配置檔案。每個配置檔案對應修改以下資訊：

  • 埠號
  • pid程式名
  • 日誌檔名
  • rdb檔名

修改完畢之後，啟動我們的3個redis伺服器，可以通過程式資訊檢視：

image-20201228181034134

一主二從配置

預設情況下，每臺Redis伺服器都是主節點；我們一般情況下只用配置從機就好了！

認老大！一主（79）二從（80，81）

使用SLAVEOF host port就可以為從機配置主機了。

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379 # SLAVEOF host 6379 找誰當自己的老大！
OK
127.0.0.1:6380> info replication
# Replication
role:slave # 當前角色是從機
master_host:127.0.0.1 # 可以的看到主機的資訊
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:1540
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:4c96a6d5a3989db9df6e012fe91f3c84c589f166
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1540
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:29
repl_backlog_histlen:1512
127.0.0.1:6380> 

# 在主機中檢視！
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2 #多了從機的配置
slave0:ip=127.0.0.1,port=6381,state=online,offset=336,lag=1
slave1:ip=127.0.0.1,port=6380,state=online,offset=336,lag=1
master_replid:4c96a6d5a3989db9df6e012fe91f3c84c589f166
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:6379>

我們這裡是使用命令搭建，是暫時的，真實開發中應該在從機的配置檔案中進行配置，這樣的話是永久的。

  • 配置主機ip和埠

  • 若主機有密碼，配置主機密碼（都是在從機的配置檔案redis.conf中配置的哈）

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-1O4tymw3-1609428488458)(C:\Users\汪航\AppData\Roaming\Typora\typora-user-images\image-20201228190309565.png)]

使用規則

  1. 從機只能讀，不能寫，主機可讀可寫但是多用於寫。

     127.0.0.1:6381> set name sakura # 從機6381寫入失敗
(error) READONLY You can't write against a read only replica.

127.0.0.1:6380> set name sakura # 從機6380寫入失敗
(error) READONLY You can't write against a read only replica.

127.0.0.1:6379> set name sakura
OK
127.0.0.1:6379> get name
"sakura"

  2. 當主機斷電當機後，預設情況下從機的角色不會發生變化 ，叢集中只是失去了寫操作，當主機恢復以後，又會連線上從機恢復原狀。

  3. 當從機斷電當機後，若不是使用配置檔案配置的從機，再次啟動後作為主機是無法獲取之前主機的資料的，若此時重新配置稱為從機，又可以獲取到主機的所有資料。這裡就要提到一個同步原理。

    複製原理 Slave 啟動成功連線到 master 後會傳送一個sync同步命令 Master 接到命令，啟動後臺的存檔程式，同時收集所有接收到的用於修改資料集命令，在後臺程式執行 完畢之後，master將傳送整個資料檔案到slave，並完成一次完全同步。

    • 全量複製：而slave服務在接收到資料庫檔案資料後，將其存檔並載入到記憶體中。
    • 增量複製：Master 繼續將新的所有收集到的修改命令依次傳給slave，完成同步
    • 但是隻要是重新連線master，一次完全同步（全量複製）將被自動執行！ 我們的資料一定可以在從機中 看到！

  4. 第二條中提到，預設情況下，主機故障後，不會出現新的主機，有兩種方式可以產生新的主機：

    • 從機手動執行命令slaveof no one,這樣執行以後從機會獨立出來成為一個主機
    • 使用哨兵模式（自動選舉）

層層鏈路

上一個M連結下一個 S！ 這時候也可以完成我們的主從複製！

這個思路其實就是有點像連結串列，通過鏈式連線主從機，中間的80是79的從機，是81的主機，實際上還是從機。如圖所示：

如果沒有老大了，這個時候能不能選擇出來一個老大呢？手動！（哨兵模式沒有應用之前）

謀朝篡位

如果主機斷開了連線，之前的從機可以使用SLAVEOF no one讓自己變成主機！其他的節點就可以手動連線到最新的主節點（手動）！如果這個時候老大修復了，那麼就只能重新連線！這也是使用命令的好處，不用去修改配置檔案

哨兵模式

自動選老大

概述

主從切換技術的方法是：當主伺服器當機後，需要手動把一臺從伺服器切換為主伺服器，這就需要人工 干預，費事費力，還會造成一段時間內服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮 哨兵模式。Redis從2.8開始正式提供了Sentinel（哨兵） 架構來解決這個問題。

謀朝篡位的自動版，能夠後臺監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫。

哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的程式，作為程式，它會獨 立執行。其原理是哨主從切換技術的方法是：當主伺服器當機後，需要手動把一臺從伺服器切換為主伺服器，這就需要人工 干預，費事費力，還會造成一段時間內服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮 哨兵模式。Redis從2.8開始正式提供了Sentinel（哨兵） 架構來解決這個問題。 謀朝篡位的自動版，能夠後臺監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫。 哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的程式，作為程式，它會獨 立執行。其原理是哨兵通過傳送命令，等待Redis伺服器響應，從而監控執行的多個Redis例項。

單機單個哨兵

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-jEfvqbck-1609428488460)(C:\Users\汪航\AppData\Roaming\Typora\typora-user-images\image-20201228193122144.png)]

哨兵的作用：

  • 通過傳送命令，讓Redis伺服器返回監控其執行狀態，包括主伺服器和從伺服器。
  • 當哨兵監測到master當機，會自動將slave切換成master，然後通過釋出訂閱模式通知其他的從伺服器，修改配置檔案，讓它們切換主機。

然而一個哨兵程式對Redis伺服器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控。 各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。

多哨兵模式

假設主伺服器當機，哨兵1先檢測到這個結果，系統並不會馬上進行failover過程，僅僅是哨兵1主觀的認 為主伺服器不可用，這個現象成為主觀下線。當後面的哨兵也檢測到主伺服器不可用，並且數量達到一 定值時，那麼哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover[故障轉移]操作。 切換成功後，就會通過釋出訂閱模式，讓各個哨兵把自己監控的從伺服器實現切換主機，這個過程稱為 客觀下線。

哨兵的核心配置

# sentinel monitor 被監控的名稱 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
#數字1表示 ：當一個哨兵主觀認為主機斷開，就可以客觀認為主機故障，然後開始選舉新的主機。

測試

一主二次

redis-sentinel wconfig/sentinel.conf

成功啟動哨兵模式

[root@Z2ze1oot49z63sxa9myw9Z bin]# redis-sentinel wconfig/sentinel.conf
30503:X 28 Dec 2020 20:14:15.901 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
30503:X 28 Dec 2020 20:14:15.901 # Redis version=6.0.9, bits=64, commit=00000000, modified=0, pid=30503, just started
30503:X 28 Dec 2020 20:14:15.901 # Configuration loaded
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.0.9 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 30503
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

30503:X 28 Dec 2020 20:14:15.903 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
30503:X 28 Dec 2020 20:14:15.908 # Sentinel ID is 9b9f011e6898d25dadb0d84969cc00d1f26a99b3
30503:X 28 Dec 2020 20:14:15.908 # +monitor master myredis 127.0.0.1 6379 quorum 1
30503:X 28 Dec 2020 20:14:15.909 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:14:15.912 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379

此時哨兵監視著我們的主機6379，如果Master 節點斷開了，這個時候就會從從機中隨機選擇一個伺服器！ （這裡面有一個投票演算法！）

30503:X 28 Dec 2020 20:16:03.708 # +failover-state-select-slave master myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:16:03.808 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:16:03.808 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:16:03.892 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:16:04.455 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:16:04.455 # +failover-state-reconf-slaves master myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:16:04.516 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:16:05.456 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:16:05.457 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:16:05.511 # +failover-end master myredis 127.0.0.1 6379
30503:X 28 Dec 2020 20:16:05.511 # +switch-master myredis 127.0.0.1 6379 127.0.0.1 6380
30503:X 28 Dec 2020 20:16:05.511 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6380
30503:X 28 Dec 2020 20:16:05.511 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6380
30503:X 28 Dec 2020 20:16:35.581 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6380

可以看到6380成為了新的主機

127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=22874,lag=1
master_replid:c6212846a85bada050be677f517bddbfc9111331
master_replid2:4c96a6d5a3989db9df6e012fe91f3c84c589f166
master_repl_offset:23006
second_repl_offset:13006
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:29
repl_backlog_histlen:22978
127.0.0.1:6380>

如果主機此時回來了，只能歸併到新的主機下，當做從機，這就是哨兵模式的規則！

哨兵模式優缺點

優點：

  1. 哨兵叢集，基於主從複製模式，所有主從複製的優點，它都有
  2. 主從可以切換，故障可以轉移，系統的可用性更好
  3. 哨兵模式是主從模式的升級，手動到自動，更加健壯

缺點：

  1. Redis不好線上擴容，叢集容量一旦達到上限，線上擴容就十分麻煩
  2. 實現哨兵模式的配置其實是很麻煩的，裡面有很多配置項

哨兵模式的全部配置

完整的哨兵模式配置檔案 sentinel.conf

# Example sentinel.conf
# 哨兵sentinel例項執行的埠 預設26379
port 26379
# 哨兵sentinel的工作目錄
dir /tmp
# 哨兵sentinel監控的redis主節點的 ip port
# master-name 可以自己命名的主節點名字 只能由字母A-z、數字0-9 、這三個字元".-_"組成。
# quorum 配置多少個sentinel哨兵統一認為master主節點失聯 那麼這時客觀上認為主節點失聯了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 當在Redis例項中開啟了requirepass foobared 授權密碼 這樣所有連線Redis例項的客戶端都要提供密碼
# 設定哨兵sentinel 連線主從的密碼 注意必須為主從設定一樣的驗證密碼
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# 指定多少毫秒之後 主節點沒有應答哨兵sentinel 此時 哨兵主觀上認為主節點下線 預設30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 這個配置項指定了在發生failover主備切換時最多可以有多少個slave同時對新的master進行 同步，
這個數字越小，完成failover所需的時間就越長，
但是如果這個數字越大，就意味著越 多的slave因為replication而不可用。
可以通過將這個值設為 1 來保證每次只有一個slave 處於不能處理命令請求的態。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障轉移的超時時間 failover-timeout 可以用在以下這些方面：
#1. 同一個sentinel對同一個master兩次failover之間的間隔時間。
#2. 當一個slave從一個錯誤的master那裡同步資料開始計算時間。直到slave被糾正為向正確的master那裡同步資料時。
#3.當想要取消一個正在進行的failover所需要的時間。
#4.當進行failover時，配置所有slaves指向新的master所需的最大時間。不過，即使過了這個超時，slaves依然會被正確配置為指向master，但是就不按parallel-syncs所配置的規則來了
# 預設三分鐘
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# SCRIPTS EXECUTION
#配置當某一事件發生時所需要執行的指令碼，可以通過指令碼來通知管理員，例如當系統執行不正常時發郵件通知相關人員。
#對於指令碼的執行結果有以下規則：
#若指令碼執行後返回1，那麼該指令碼稍後將會被再次執行，重複次數目前預設為10
#若指令碼執行後返回2，或者比2更高的一個返回值，指令碼將不會重複執行。
#如果指令碼在執行過程中由於收到系統中斷訊號被終止了，則同返回值為1時的行為相同。
#一個指令碼的最大執行時間為60s，如果超過這個時間，指令碼將會被一個SIGKILL訊號終止，之後重新執行。
#通知型指令碼:當sentinel有任何警告級別的事件發生時（比如說redis例項的主觀失效和客觀失效等等），將會去呼叫這個指令碼，這時這個指令碼應該通過郵件，SMS等方式去通知系統管理員關於系統不正常執行的資訊。呼叫該指令碼時，將傳給指令碼兩個引數，一個是事件的型別，一個是事件的描述。如果sentinel.conf配置檔案中配置了這個指令碼路徑，那麼必須保證這個指令碼存在於這個路徑，並且是可執行的，否則sentinel無法正常啟動成功。
#通知指令碼
# shell程式設計
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 客戶端重新配置主節點引數指令碼
# 當一個master由於failover而發生改變時，這個指令碼將會被呼叫，通知相關的客戶端關於master地址已經發生改變的資訊。
# 以下引數將會在呼叫指令碼時傳給指令碼:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>總是“failover”,
# <role>是“leader”或者“observer”中的一個。
# 引數 from-ip, from-port, to-ip, to-port是用來和舊的master和新的master(即舊的slave)通訊的
# 這個指令碼應該是通用的，能被多次呼叫，不是針對性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由運維來配置！

相關文章