MySQL的主从复制主从同步
MySQL 主從復制概念
MySQL 主從復制是指數(shù)據(jù)可以從一個MySQL數(shù)據(jù)庫服務(wù)器主節(jié)點復制到一個或多個從節(jié)點。MySQL 默認采用異步復制方式,這樣從節(jié)點不用一直訪問主服務(wù)器來更新自己的數(shù)據(jù),數(shù)據(jù)的更新可以在遠程連接上進行,從節(jié)點可以復制主數(shù)據(jù)庫中的所有數(shù)據(jù)庫或者特定的數(shù)據(jù)庫,或者特定的表。
常見的幾種主從架構(gòu)
- 單向主從模式:Master ——> Slave
- 雙向主從模式:Master <====> Master
- 級聯(lián)主從模式:Master ——> Slave1 ——> Slave2
- 一主多從模式
- 多主一從模式
主從復制功能
Mysql支持哪些復制
1. 基于語句的復制: 在主服務(wù)器執(zhí)行SQL語句,在從服務(wù)器執(zhí)行同樣語句。
注:MySQL默認采用基于語句的復制,效率較高。一旦發(fā)現(xiàn)沒法精確復制時, 會自動選基于行的復制。
2. 基于行的復制: 把改變的內(nèi)容復制過去,而不是把命令在從服務(wù)器上執(zhí)行一遍. 從mysql5.0開始支持
3. 混合類型的復制: 默認采用基于語句的復制,一旦發(fā)現(xiàn)基于語句的無法精確的復制時,就會采用基于行的復制。
為什么MySQL要做主從復制(讀寫分離)?
- 提高數(shù)據(jù)庫系統(tǒng)的可用性
- 當用戶的訪問量越來越高的時候,一旦查詢也就是讀取數(shù)據(jù)的操作太頻繁了,勢必網(wǎng)站崩掉,服務(wù)器宕機,很影響用戶的體驗度
- 數(shù)據(jù)庫數(shù)據(jù)是一個公司或者集團企業(yè)最為重要的資產(chǎn),以防數(shù)據(jù)的丟失和損壞,需要進行備份
主從復制原理
主從同步過程中主服務(wù)器有一個工作線程I/O dump thread,從服務(wù)器有兩個工作線程I/O thread和SQL thread。
I/O線程:監(jiān)聽主服務(wù)器是否發(fā)生數(shù)據(jù)更改的行為
SQL線程:將主服務(wù)器數(shù)據(jù)更改的數(shù)據(jù)從中繼日志文件中讀取數(shù)據(jù)寫入到從數(shù)據(jù)服務(wù)器中
中繼日志:承接主服務(wù)器數(shù)據(jù)信息,轉(zhuǎn)存在從服務(wù)器上
主庫把外界接收的SQL請求記錄到自己的binlog日志中,從庫的I/O thread去請求主庫的binlog日志,并將binlog日志寫到中繼日志中,然后從庫重做中繼日志的SQL語句。主庫通過I/O dump thread給從庫I/O thread傳送binlog日志。(I/O線程)
1)從庫會生成兩個線程,一個I/O線程,一個SQL線程;
2)I/O線程會去請求主庫的binlog,并將得到的binlog寫到本地的relay-log(中繼日志)文件中;
3)主庫會生成一個log dump線程,用來給從庫I/O線程傳binlog;
4)SQL線程,會讀取relay log文件中的日志,并解析成sql語句逐一執(zhí)行;
復制方式的分類:
異步復制
異步復制是MySQL默認的復制方式,主庫寫入binlog日志后即可成功返回客戶端,無須等待binlog日志傳遞給從庫的過程,但是一旦主庫宕機,就有可能出現(xiàn)丟失數(shù)據(jù)的情況。
半同步復制
MySQL默認的復制方式是異步復制,但是當主庫宕機,在高可用架構(gòu)做準備切換,就會造成新的主庫丟失數(shù)據(jù)的現(xiàn)象。
MySQL5.5版本之后引入了半同步復制,但是主從服務(wù)器必須同時安裝半同步復制插件。在該功能下,確保從庫接收完成主庫傳遞過來的binlog內(nèi)容已經(jīng)寫入到自己的relay log后才會通知主庫上面的等待線程。如果等待超時(超時參數(shù):rpl_semi_sync_master_timeout),則關(guān)閉半同步復制,并自動轉(zhuǎn)換為異步復制模式,直到至少有一臺從庫通知主庫已經(jīng)接收到binlog信息為止。
mysql主從同步的原理介紹
實際開發(fā)項目中可能存在一主多從的數(shù)據(jù)庫服務(wù)器,也就是一個主服務(wù)器,多個從服務(wù)器。現(xiàn)在就以一主一從的服務(wù)器配置來說明下數(shù)據(jù)怎么做到主從同步的,先來介紹下幾個名詞。
主數(shù)據(jù)服務(wù)器:主要用來從業(yè)務(wù)服務(wù)寫入數(shù)據(jù)或者修改更新數(shù)據(jù)
從數(shù)據(jù)服務(wù)器:主要用來讀取業(yè)務(wù)所需要的數(shù)據(jù)
二進制日志:用來存儲寫入以及更新的數(shù)據(jù)信息
中繼日志:承接主服務(wù)器數(shù)據(jù)信息,轉(zhuǎn)存在從服務(wù)器上
I/O線程:監(jiān)聽主服務(wù)器是否發(fā)生數(shù)據(jù)更改的行為
SQL線程:將主服務(wù)器數(shù)據(jù)更改的數(shù)據(jù)從中繼日志文件中讀取數(shù)據(jù)寫入到從數(shù)據(jù)服務(wù)器中
主從同步原理:
當主數(shù)據(jù)服務(wù)器master進行寫入數(shù)據(jù)或者更新數(shù)據(jù)操作的時候,數(shù)據(jù)更改會記錄在二進制日志(binary log file)中,主服務(wù)器master與從服務(wù)器slave進行通訊的是I/O線程,它將修改的數(shù)據(jù)異步復制寫入到slave服務(wù)器的中繼日志(relay log file)中,從服務(wù)器slave與中繼日志之間通信使用SQL線程,SQL線程可以異步從中繼日志中讀取數(shù)據(jù)后再寫入到自己的數(shù)據(jù)庫中,就完成了數(shù)據(jù)的主從同步功能。
從服務(wù)器slave為什么不能直接存儲二進制日志文件里面的數(shù)據(jù)?
本來做數(shù)據(jù)的主從同步就是為了讓計算機快速的進行讀寫操作,而且是大批量的數(shù)據(jù),一旦大量數(shù)據(jù)進行寫入或者更新數(shù)據(jù),從數(shù)據(jù)庫slave如果直接從二進制日志來接收,數(shù)據(jù)是以隊列形式進行傳輸?shù)?#xff0c;若隊列的數(shù)據(jù)沒有快速處理,堆積起來,從服務(wù)器可能也會崩潰宕機,所以從性能上考慮,從服務(wù)器slave創(chuàng)建了I/O線程對象將數(shù)據(jù)轉(zhuǎn)到中繼日志,起個緩存功能。
造成mysql同步延遲常見原因
1)網(wǎng)絡(luò):如主機或者從機的帶寬打滿、主從之間網(wǎng)絡(luò)延遲很大,導致主上的binlog沒有全量傳輸?shù)綇臋C,造成延遲。
2)機器性能:從機使用了爛機器?比如主機使用SSD而從機還是使用的SATA。
3)從機高負載:有很多業(yè)務(wù)會在從機上做統(tǒng)計,把從機服務(wù)器搞成高負載,從而造成從機延遲很大的情況
4)大事務(wù):比如在RBR模式下,執(zhí)行帶有大量的delete操作,這種通過查看processlist相關(guān)信息以及使用mysqlbinlog查看binlog中的SQL就能快速進行確認
5)鎖: 鎖沖突問題也可能導致從機的SQL線程執(zhí)行慢,比如從機上有一些select … for update的SQL,或者使用了MyISAM引擎等。
硬件方面(優(yōu)化)
1.采用好服務(wù)器,比如4u比2u性能明顯好,2u比1u性能明顯好。
2.存儲用ssd或者盤陣或者san,提升隨機寫的性能。
3.主從間保證處在同一個交換機下面,并且是萬兆環(huán)境。
總結(jié):硬件強勁,延遲自然會變小。一句話,縮小延遲的解決方案就是花錢和花時間。
mysql主從同步加速
1)sync_binlog在slave端設(shè)置為0
當事務(wù)提交后,Mysql僅僅是將binlog_cache中的數(shù)據(jù)寫入Binlog文件,但不執(zhí)行fsync之類的磁盤 同步指令通知文件系統(tǒng)將緩存刷新到磁盤
而讓Filesystem自行決定什么時候來做同步,這個是性能最好的。
2)slave端 innodb_flush_log_at_trx_commit = 2
每次事務(wù)提交時MySQL都會把log buffer的數(shù)據(jù)寫入log file,但是flush(刷到磁盤)操作并不會同時進行。
該模式下,MySQL會每秒執(zhí)行一次 flush(刷到磁盤)操作。
3)–logs-slave-updates 從服務(wù)器從主服務(wù)器接收到的更新不記入它的二進制日志。
4)直接禁用slave端的binlog
原址參考來自于此
總結(jié)
以上是生活随笔為你收集整理的MySQL的主从复制主从同步的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Mysql的事务事务的特征事务的隔离级别
- 下一篇: MySQL的索引及优化方案