Redis（八）：Redis的復制（Master/Slave）

Redis的復制（Master/Slave）目錄導航：

• 是什么
• 能干嘛
• 怎么玩
• 復制原理
• 哨兵模式（sentinel）
• 復制的缺點

是什么

• 官網

• 行話：也就是我們所說的主從復制，主機數據更新后根據配置和策略，自動同步到備機的master/slaver機制，Master以寫為主，Slave以讀為主。

能干嘛

• 讀寫分離
• 容災恢復

怎么玩

• 配從(庫)不配主(庫)
• 從庫配置：slaveof 主庫IP 主庫端口
• 每次與master斷開之后，都需要重新連接，除非你配置進redis.conf文件
  
• Info replication
• 修改配置文件細節操作
• 拷貝多個redis.conf文件
  

• • 開啟daemonize yes

• • Pid文件名字
  • 指定端口
  • Log文件名字

• • Dump.rdb名字

• 常用3招
  • 一主二仆
    
    • Init
      

 

• • • 一個Master兩個Slave

 

• • • 日志查看
      
      • 主機日志
        

 

• • • • 備機日志

• • • • info replication

• • • 主從問題演示

1 切入點問題？slave1、slave2是從頭開始復制還是從切入點開始復制?比如從k4進來，那之前的123是否也可以復制
2 從機是否可以寫？set可否？
3 主機shutdown后情況如何？從機是上位還是原地待命
4 主機又回來了后，主機新增記錄，從機還能否順利復制？
5 其中一台從機down后情況如何？依照原有它能跟上大部隊嗎？

• • 薪火相傳

  • 上一個Slave可以是下一個slave的Master，Slave同樣可以接收其他slaves的連接和同步請求，那么該slave作為了鏈條中下一個的master,可以有效減輕master的寫壓力

  • 中途變更轉向:會清除之前的數據，重新建立拷貝最新的
  • Slaveof 新主庫IP 新主庫端口
  • 反客為主
    • SLAVEOF no one
      
      • 使當前數據庫停止與其他數據庫的同步，轉成主數據庫

復制原理

• Slave啟動成功連接到master后會發送一個sync命令

• Master接到命令啟動后台的存盤進程，同時收集所有接收到的用於修改數據集命令，在后台進程執行完畢之后，master將傳送整個數據文件到slave,以完成一次完全同步

• 全量復制：而slave服務在接收到數據庫文件數據后，將其存盤並加載到內存中。
• 增量復制：Master繼續將新的所有收集到的修改命令依次傳給slave,完成同步
• 但是只要是重新連接master,一次完全同步（全量復制）將被自動執行

哨兵模式（sentinel）

• 是什么
• 反客為主的自動版，能夠后台監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫
  
• 怎么玩(使用步驟)
• 調整結構，6379帶着80、81
  
• 自定義的/myredis目錄下新建sentinel.conf文件，名字絕不能錯
• 配置哨兵,填寫內容
  •  sentinel monitor 被監控數據庫名字(自己起名字) 127.0.0.1 6379 1
    
  • 上面最后一個數字1，表示主機掛掉后salve投票看讓誰接替成為主機，得票數多少后成為主機
• 啟動哨兵

• • Redis-sentinel /myredis/sentinel.conf
  • 上述目錄依照各自的實際情況配置，可能目錄不同
  • 正常主從演示
  • 原有的master掛了

• • 投票新選

 

• • 重新主從繼續開工,info replication查查看

 

• • 問題：如果之前的master重啟回來，會不會雙master沖突？

 

• 一組sentinel能同時監控多個Master

復制的缺點

• 復制延時

由於所有的寫操作都是先在Master上操作，然后同步更新到Slave上，所以從Master同步到Slave機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，Slave機器數量的增加也會使這個問題更加嚴重。