9.redis主從復制

什么是主從復制

主庫資料更新后根據配置和策略，自動同步到從庫（備份機）的master/slaver機制，master（主庫）以寫為主，slave（從庫）以讀為主，

主從復制作用

• 讀寫分離：master以寫為主，slave以讀為主，
• 容災恢復：由于slaves的資料是master的副本，無論master還是slaves宕機了都能讓資料得到有效的恢復，

環境準備

1. 拷貝三個redis.conf組態檔，并分別重命名為redis6379.conf，redis6380.conf和redis6381.conf
   
2. 三個組態檔都配置 daemonize yes
3. 埠分別配置為port 6379，port 6380和port 6381
4. pid檔案路徑分別配置為pidfile /var/run/redis_6379.pid，pidfile /var/run/redis_6380.pid和pidfile /var/run/redis_6381.pid
5. log名稱分別配置為logfile "6379.log"，logfile "6380.log"和logfile "6381.log"
6. db檔案名稱分別配置為dbfilename dump6379.rdb，dbfilename dump6380.rdb和dbfilename dump6381.rdb

當然以上配置都非必須的，只是為了在同一臺虛擬機上演示更好的區分開來

分別使用redis6379.conf，redis6380.conf和redis6381.conf組態檔來啟動三個不同的redis服務，并通過ps -ef|grep redis命令來查看服務狀態，

使用三個命令列視窗分別連接redis服務，

以79埠的redis服務為例，輸入命令 info replication查看主從復制資訊，

# Replication
#master表示為主庫，slave表示為從庫
role:master
#連接該主庫的從庫數量
connected_slaves:0
master_replid:07e5ec5474ccf8c60e1471309b47e2592f38aeb1
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

主從復制模式

1. 一主二從：一臺主庫（master），兩臺或多臺從庫（slaves）

假設以79埠服務為主庫，其他為從庫，

79服務分別造幾條資料，如下：

命令slaveof <host> <port>表示以host地址的port埠的redis服務為主庫，自己為從庫，假設80和81都以79為主庫，如下：

80和81分別以79為主庫后，主庫79的資料被復制到了從庫，又由于主庫79先新增資料，80和81后以79為主庫，由此可見從庫和主庫剛連接時為全量復制（后序主庫有新增資料，從庫為增量復制），

以從庫80為例，輸入info replication查看從庫主從復制資訊，感興趣的同學可以通過此命令嘗試查看主庫此時的主從復制資訊，

# Replication
#當前狀態為從庫
role:slave
#主庫ip地址
master_host:127.0.0.1
#主庫埠
master_port:6379
#與主庫的連通狀態，up表示連通，down不連通
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:882
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:02c33749f6cd663e01bf7442a4a80e03d25a0cda
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:882
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:393
repl_backlog_histlen:490

主庫可以寫，從庫只能讀，即：主寫從讀，讀寫分離

假如通過shutdown命令演示主庫79宕機了，問題：從庫80和81是原地待命等待與主庫重新連接還是從庫咸魚翻身由從變主？


主庫重新連接后，

結論：主庫宕機后，原地待命等待與主庫重新連接，只是與主庫的聯通狀態由up變為down，

以從庫80為例，從庫宕機后，重新連接后，問題：從庫80仍然是以79為主庫的從庫，還是與主庫79斷開主從關系，自己變為主庫？

結論：從庫宕機后重新連接，與原有主庫斷開主從關系，但保存有原來主庫的資料，

注：slaveof命令確定的主從關系只是臨時的，從庫重新啟動就斷開了，若要永久配置主從關系需要寫進組態檔，

假設80為master時，80以79為主庫后，從庫80原有的資料與主庫79合并還是79主庫的資料完全覆寫從庫80資料？

答案：從庫的資料被主庫完全覆寫，同學們可以自己嘗試嘗試，

2. 薪火相傳
   
   80作為79的slave，并擁有79的資料副本，同時80也是81的master，81擁有80的資料副本（也是79的副本），資料從79傳輸到80，又由80傳輸到81，脈脈相傳，80即作為master，同時也是slave，
   
   80的master是79，81的master是80，此時80既是master也是slave，使用info replication命令重點查看80的資訊如下：
   
   由于role只能顯示master或者slave，所以80是master&slave也只是理論上的一說，同時80執行set等修改命令仍然執行報錯，

按照如圖數字所示的順序執行命令，可知資料由79同步到了80，再由80同步到了81，
當主庫宕機，或者從庫宕機之后幾種情況理論分析和一主二從情況相同，此處不再贅述，

3. 反客為主

由一主二從可知，當master宕機之后，slaves原地待命等待master恢復，但不可一日無主，反客為主即為當master宕機后，從眾多的從庫中選擇一個作為master，其他從庫以其為新的master，

slaveof no one：使當前資料庫與其他資料庫的附屬關系，使其成為主資料庫，

在一主二從的基礎上，當79宕機后，slaveof no one使80斷開與79的附屬關系，slaveof 127.0.0.1 6380讓81的新master為80，

重新連接79后，查看79和80的主從復制資訊，如下：

由此可知，即使79重新連接后，但江山早已易主，

4. 哨兵模式（sentinel）

反客為主的自動版，由反客為主可知，當主庫宕機之后，需要手動重新選擇新的master，并且重新修改slave的主庫指向，哨兵模式即能夠在后臺監控主庫如果出現故障，則根據投票自動從從庫中選擇新的主庫，并且其他從庫以新的主庫為master，

和反客為主不同之處在于當舊的master重新連接后，舊的master也會成為新的master的slave，

sentinel monitor 被監控資料庫名稱（自定義） 被監控資料庫ip地址 被監控資料庫埠號 票數，表示當被監控的資料庫出現故障后，自動從從庫中投票，從庫達到指定票數后則變成其他從庫的新主庫，

新建sentinel.conf檔案，

編輯sentinel.conf檔案，寫入sentinel monitor host6479 127.0.0.1 6379 1，

分別啟動79，80和81資料庫，79分別為80和81的主庫（一主二從）

新的視窗用redis-sentinel /myredis/sentinel.conf以sentinel的方式啟動redis監控服務，

由日志可知79的從庫分別是80和81，

用shutdown演示79宕機后，由日志可知，后臺正通過投票從從庫中選擇新的主庫，


通過投票后新的master為81，

當79重新連接服務后，江山易主，權利變更，79成為81的從庫，

復制的原理

1. slave啟動成功連接到master后會發送一個sync命令；

2. master接到命令啟動后的存盤行程，同時收集所有接收到的用于修改資料集命令，在后臺行程執行完畢之后，master將傳送整個資料檔案到slave，以完成一次完全同步（全量復制）；

3. 全量復制：slave服務在接受到資料庫檔案資料后，將其存盤并加載到記憶體中；

4. 增量復制：master繼續將新的所有收集到的修改命令依次傳給slave，完成同步，但是只要是重新連接master，一次完全同步（全量復制）將被自動執行，

復制的缺點

由于所有的操作都是現在master上操作，然后同步更新到slaves上，所以從master同步到slaves機器有一定的延遲，當系統繁忙的時候延遲問題更加嚴重，slaves機器數量的增加也會是這個問題更嚴重，特別是薪火相傳模式時，master同步到slaveA，slaveA同步完后再同步到slaveB，slaveB同步完后再同步到slaveC… … 上一個slave同步完后下一個slave才能同步，更加延長了同步的時間，