MySQL 主從復(fù)制概念
MySQL 主從復(fù)制是指數(shù)據(jù)可以從一個MySQL數(shù)據(jù)庫服務(wù)器主節(jié)點復(fù)制到一個或多個從節(jié)點罐孝。一般主服務(wù)器負(fù)責(zé)寫肥缔，而從服務(wù)器負(fù)責(zé)讀莲兢，Mysql的主從復(fù)制的過程是一個異步的過程续膳。
MySQL 主從復(fù)制作用
1.讀寫分離
在開發(fā)工作中，有時候會遇見某個sql 語句需要鎖表遣耍，導(dǎo)致暫時不能使用讀的服務(wù)，這樣就會影響現(xiàn)有業(yè)務(wù)，使用主從復(fù)制酣溃，讓主庫負(fù)責(zé)寫，從庫負(fù)責(zé)讀扛或，這樣，即使主庫出現(xiàn)了鎖表的情景熙兔，通過讀從庫也可以保證業(yè)務(wù)的正常運(yùn)作艾恼。
2.高可用
當(dāng)系統(tǒng)中某個節(jié)點發(fā)生故障時，可以方便的故障切換钠绍。
3.提高讀寫性能
有了主從復(fù)制，增加多個數(shù)據(jù)存儲節(jié)點，將負(fù)載分布在多個從節(jié)點上碱屁，這樣可以提高系統(tǒng)的讀寫性能蛾找。
MySQL 主從形式
1.一主一從
2.一主多從，提高系統(tǒng)的讀性能
一主一從和一主多從是最常見的主從架構(gòu)打毛，實施起來簡單并且有效，
優(yōu)點：不僅可以實現(xiàn)高可用闹瞧，而且還能讀寫分離，進(jìn)而提升集群的并發(fā)能力奥邮。
缺點：主庫更新的數(shù)據(jù)到從庫更新數(shù)據(jù)有一定的延遲罗珍。
3.多主一從
多主一從可以將多個mysql數(shù)據(jù)庫備份到一臺存儲性能比較好的服務(wù)器上
4.雙主復(fù)制
雙主復(fù)制，也就是互做主從復(fù)制蘸朋，每個master既是master，又是另外一臺服務(wù)器的slave藕坯。這樣任何一方所做的變更噪沙，都會通過復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫中炼彪。
5.級聯(lián)復(fù)制
如果太多從庫從主庫同步數(shù)據(jù)正歼，會對主庫有一點壓力，所以可以讓一部分從庫從連接主庫的從庫上同步數(shù)據(jù)喜爷。
主從復(fù)制的原理
例如一主一從的情況下萄唇，從庫 B 跟主庫 A 之間維持了一個長連接：
1.在從庫 B 上通過 change master 命令檩帐，設(shè)置主庫 A 的 IP穷绵、端口、用戶名、密碼揍障，以及要從哪個位置開始請求 binlog俩由，這個位置包含文件名和日志偏移量毒嫡。
2.在從庫 B 上執(zhí)行 start slave 命令，這時候從庫會啟動兩個線程兜畸，就是圖中的 io_thread 和 sql_thread碘梢。其中 io_thread 負(fù)責(zé)與主庫建立連接咬摇。
3.主庫 A 校驗完用戶名煞躬、密碼后，開始按照從庫 B 傳過來的位置恩沛，從本地讀取 binlog，發(fā)給 B雷客。
4.從庫 B 拿到 binlog 后，寫到本地文件皱卓，稱為中轉(zhuǎn)日志（relay log）。
5.sql_thread 讀取中轉(zhuǎn)日志好爬，解析出日志里的命令甥啄，并執(zhí)行。
循環(huán)復(fù)制問題
在雙主復(fù)制的情況下A蜈漓、B庫都為主庫宫盔，會互相發(fā)送更新語句，所以為了避免循環(huán)執(zhí)行的情況灼芭，要求兩個庫的 server id 必須不同，如果相同，則它們之間不能設(shè)定為主備關(guān)系茴迁。MySQL 在 binlog 中記錄了這個命令第一次執(zhí)行時所在實例的 server id萤衰。每個庫在收到從自己的主庫發(fā)過來的日志后堕义，先判斷 server id脆栋，如果跟自己的相同倦卖，表示這個日志是自己生成的，就直接丟棄這個日志椿争。
讀寫分離的問題及解決辦法
問題：主庫更新數(shù)據(jù)到從庫更新數(shù)據(jù)會存在延遲怕膛，客戶端執(zhí)行完一個更新事務(wù)后馬上發(fā)起查詢，如果查詢選擇的是從庫的話秦踪，就有可能讀到剛剛的事務(wù)更新之前的狀態(tài)褐捻。
解決方案：
- 強(qiáng)制走主庫方案
1.對于必須要拿到最新結(jié)果的請求，強(qiáng)制將其發(fā)到主庫上。比如，在一個交易平臺上线欲，賣家發(fā)布商品以后肯适，馬上要返回主頁面，看商品是否發(fā)布成功筝蚕。那么，這個請求需要拿到最新的結(jié)果，就必須走主庫。
2.對于可以讀到舊數(shù)據(jù)的請求聊疲，才將其發(fā)到從庫上茬底。在這個交易平臺上，買家來逛商鋪頁面获洲，就算晚幾秒看到最新發(fā)布的商品阱表，也是可以接受的。那么贡珊，這類請求就可以走從庫最爬。 - sleep 方案
主庫更新后，讀從庫之前先 sleep 一下门岔。 - 判斷主備無延遲方案
show slave status 結(jié)果里的 seconds_behind_master 參數(shù)的值爱致，可以用來衡量主備延遲時間的長短。每次從庫執(zhí)行查詢請求前寒随，先判斷 seconds_behind_master 是否已經(jīng)等于 0糠悯。如果還不等于 0 帮坚，那就必須等到這個參數(shù)變?yōu)?0 才能執(zhí)行查詢請求。 - 用redis之類的做緩存
主庫更新成功之后更新進(jìn)redis互艾，下次讀也就直接讀redis了试和。
