是什麼 主從複製，master以寫為主，slave以讀為主。 當master數據變化的時候，自動將新的數據非同步同步到其他slave資料庫 能幹嘛 讀寫分離 容災恢復 數據備份 水平擴容支撐高併發 怎麼玩 master如果配置了requirepass參數，需要密碼登錄，那麼slave就要配置maste ...
主從複製，master以寫為主，slave以讀為主。
當master數據變化的時候，自動將新的數據非同步同步到其他slave資料庫
能幹嘛
-
讀寫分離
-
容災恢復
-
數據備份
-
水平擴容支撐高併發
怎麼玩
-
master如果配置了requirepass參數，需要密碼登錄，那麼slave就要配置masterauth來設置校驗密碼，否則master會拒絕slave的訪問請求
-
後臺啟動：預設daemonize no 改為
daemonize yes
-
關閉保護模式：預設protected-mode yes 改為
protected-mode no
-
註釋掉
bind 127.0.0.1直接註釋掉這行(預設bind 127.0.0.1只能本機訪問)或改成本機IP地址，否則影響遠程IP連接
-
指定埠
-
指定當前工作目錄
-
pid文件名字
-
log文件名字
-
requirepass
-
dump.rdb名字
-
aof文件
-
從機增加的配置
三種模式
一主二僕
-
方案一：配置文件固定寫死
配置文件文件執行 replicaof 主庫IP 主庫埠
配從(庫)不配主(庫)
先master後兩台slave依次啟動
主從關係查看
-
日誌
主機日誌
從機日誌
-
命令
info replication 命令查看
-
主從問題演示：
-
從機可以執行寫命令嗎？
-
slave是從頭開始複製還是從切入點開始複製?
從頭開始一鍋端！（首次一鍋端，後續跟隨，master寫，slave跟）
-
主機shutdown後，從機 會上位嗎？
從機不動，原地待命，從機數據可以正常使用；等待主機重啟動歸來
-
主機shutdown重啟後主從關係還在嗎？從機還能否順利複製？
在，可以！
-
某台從機down後，master繼續，該從機重啟後還能跟上大部隊嗎？
可以！
-
方案二：命令操作手動指定
slaveof 主庫IP 主庫埠
-
從機停機去掉配置文件中的配置項，3台目前都是主機（master）狀態，各不從屬
-
從機上執行命令 slaveof 主庫IP 主庫埠
-
用命令設置的主從關係，2台從機重啟後，關係還在嗎？
不在了！
配置 VS 命令
配置，持久穩定
命令，當次生效
薪火相傳
上一個slave可以是下一個slave的master，slave同樣可以接收其他slave的連接和同步請求，那麼該slave作為了鏈條中下一個的master，可以有效減輕註master的寫壓力。
中途變更主機會清除之前的數據，重新建立拷貝最新的主機數據。
反客為主
SLAVEOF no one
使當前資料庫停止與其他資料庫的同步，轉成主資料庫
複製原理&工作流程
-
slave啟動，同步出請：
-
slave啟動成功連接到master會發送一個sync的命令
-
slave首次全新連接master，一次完全同步（全量複製）將被自動執行，slave自身原有數據會被master覆蓋清除。
-
-
首次連接，全量複製：
-
master節點收到sync命令後會開始在後臺保存快照（即RDB持久化，主從複製時會觸發RDB），同時收集所有接收到的用於修改數據集的命令緩存起來，master節點執行RDB持久化完成後，master將所有rdb快照文件和所有緩存的命令發送到所有slave，以完成一次完全同步。
-
而slave服務在接收到資料庫文件數據後，將其存檔並載入到記憶體中，從而完成複製初始化。
-
-
心跳持續，保持通信：
repl-ping-replica-period 10：master發出PING包的周期，預設是10秒
-
進入平穩，增量複製：
master繼續講新的所有收集到的修改命令自動依次傳給slave，完成同步。
-
從機下線，重連續傳：
master會檢查backlog裡面的offset，master和slave都會保存一個複製的offset還有一個masterId，offset是保存在backlog中的。master只會把已經複製的offset後面的數據複製給slave，類似斷點續傳。
缺點
-
複製延時，信號衰減
由於所有的寫操作都是先在Master上操作，然後同步更新到Slave上，所以從Master同步到Slave機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，Slave機器數量的增加也會使這個問題更加嚴重。
-
