前言
單機版mysql容易出現單點故障，所以需要搭建多臺mysql服務器，mysql架構有很多種，目的都是熱備份，多活，故障切換，負載均衡、讀寫分離等
一、主從復制架構
master主節點負責寫入資料，slave從節點負責讀取資料，實作了讀寫分離，應用與讀多寫少的業務場景，這種架構的缺點就是只有一個master,如果掛掉了，就無法寫入資料了，而且master和slave資料還有同步延遲的風險，
這種架構是級聯復制架構，用于解決讀需求更多的業務場景，如果讀壓力加大，就需要更多的slave來解決，但是如果slave的復制全部從master復制，勢必會加大master的復制IO的壓力，所以就出現了級聯復制，減輕master壓力，缺點就是slave延遲更加大了，
二、主主架構
兩個主節點，一個負責寫，一個負責讀，需要配合一個keepalived進行ip漂移，這樣一個掛掉了，另一個可以繼續作業，
上面這種架構，雙主多從，解決了單master復制的壓力大問題，減少了slave資料延遲，且雙master可以減少單點故障，
由上面的架構可以看出，搭建mysql集群是一個很大的開銷，絕大多數公司，用的還是單機版mysql，
三、MYSQL主從復制原理
- 復制程序-異步復制
異步復制是MYSQL主從復制默認的方式，流程如下:
1.客戶端提交sql陳述句至master的mysql服務器后，mysql服務器將sql陳述句寫入binglog日志，并將事務進行提交，回傳訊息給客戶端，
2.mysql服務中有個event監聽器，監聽binglog日志的變化，如果有變化，則通知dump執行緒，
3.master服務器的dump執行緒通知slave服務器的IO執行緒，有資料需要同步，slave服務器的IO執行緒從slave服務器的relay-log.info中獲取binlog檔案和pos位置(類似于Kafka中的偏移量，記錄binlog日志的插入位置)
4.slave節點通過IO執行緒通知master節點slave的binlog檔案和pos位置
5.根據slave的請求，master將相應的binlog檔案和pos位置傳給slave
6.slave獲取到資訊后，將資訊寫入relay-bin日志中，等待slave節點從relay-bin讀取日志，同步資料，
7.slave節點寫入relay-bin日志成功后，給master節點回復ack資訊，通知master寫入relay-bin日志成功，
8.master節點的dump執行緒通知服務將客戶端寫入的資料進行提交操作，然后給客戶端相應訊息， - 復制程序-半同步復制
1.客戶端提交sql陳述句至master的mysql服務器后，mysql服務器將sql陳述句寫入binglog日志，
2.mysql服務中有個event監聽器，監聽binglog日志的變化，如果有變化，則通知dump執行緒，
3.master服務器的dump執行緒通知slave服務器的IO執行緒，有資料需要同步，slave服務器的IO執行緒從slave服務器的relay-log.info中獲取binlog檔案和pos位置(類似于Kafka中的偏移量，記錄binlog日志的插入位置)
4.slave節點通過IO執行緒通知master節點slave的binlog檔案和pos位置
5.根據slave的請求，master將相應的binlog檔案和pos位置傳給slave
6.slave獲取到資訊后，將資訊寫入relay-bin日志中，等待slave節點從relay-bin讀取日志，同步資料，
7.slave節點寫入relay-bin日志成功后，給master節點回復ack資訊，通知master寫入relay-bin日志成功，
8.master節點的dump執行緒通知服務將客戶端寫入的資料進行提交操作，然后給客戶端相應訊息，
可以看出，異步復制中，master節點不管slave節點資料是否同步成功，都會將資料提交，回傳客戶端成功的訊息，這樣的風險就是slave節點資料同步不成功的話，客戶端并不知道，所以引入了半同步復制，master節點等到slave節點寫入relay-bin日志成功后，才提交事務資料，這樣更有利于資料的同步性，需要注意的是，開啟半同步復制后，如果slave節點掛了，則master一直等待slave節點的ack資訊，默認等待10秒，如果還沒收到slave的ack，則認為slave節點掛掉了，master節點會自動變成異步復制方式進行，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/342060.html
標籤：其他
上一篇：InnoDB存盤引擎體系架構