我們之前提到當(dāng)備庫(kù)足夠多時(shí)，會(huì)對(duì)主庫(kù)造成很大的負(fù)載。每個(gè)備庫(kù)會(huì)在主庫(kù)上創(chuàng)建一個(gè)線程，并執(zhí)行binlogdump命令。該命令會(huì)讀取二進(jìn)制日志文件中的數(shù)據(jù)并將其發(fā)送給備庫(kù)。每個(gè)備庫(kù)都會(huì)重復(fù)這樣的工作，它們不會(huì)共享binlog dump的資源。

如果有很多備庫(kù)，并且有大的事件時(shí)，例如一次很大的L0AD DATA INFILE操作，主庫(kù)上的負(fù)載會(huì)顯著上升，甚至可能由于備庫(kù)同時(shí)請(qǐng)求同樣的事件而耗盡內(nèi)存并崩潰。另一方面，如果備庫(kù)請(qǐng)求的數(shù)據(jù)不在文件系統(tǒng)的緩存中，可能會(huì)導(dǎo)致大量的磁盤(pán)檢索，這同樣會(huì)影響主庫(kù)的性能并增加鎖的競(jìng)爭(zhēng)。

因此，如果需要多個(gè)備庫(kù)，一個(gè)好辦法是從主庫(kù)移除負(fù)載并使用分發(fā)主庫(kù)。分發(fā)主庫(kù)事實(shí)上也是一個(gè)備庫(kù)，它的唯-目的就是提取和提供主庫(kù)的二進(jìn)制日志。多個(gè)備庫(kù)連接到分發(fā)主庫(kù)，這使原來(lái)的主庫(kù)擺脫了負(fù)擔(dān)。為了避免在分發(fā)主庫(kù)上做實(shí)際的查詢(xún)，可以將它的表修改為blackhole存儲(chǔ)引擎。

很難說(shuō)當(dāng)備庫(kù)數(shù)據(jù)達(dá)到多少時(shí)需要一個(gè)分發(fā)主庫(kù)。按照通用準(zhǔn)則，如果主庫(kù)接近滿負(fù)載，不應(yīng)該為其建立10個(gè)以上的備庫(kù)。如果有少量的寫(xiě)操作，或者只復(fù)制其中一部分表，主庫(kù)就可以提供更多的復(fù)制。另外，也不一定只使用一個(gè)分發(fā)主庫(kù)。如果需要的話，可以使用多個(gè)分發(fā)主庫(kù)向大量的各庫(kù)進(jìn)行復(fù)制，或者使用金字塔狀的分發(fā)主庫(kù)。在某些情況下，可以通過(guò)設(shè)置slave_compressed_protoco來(lái)節(jié)約一些主庫(kù)帶寬。 這對(duì)跨數(shù)據(jù)中心復(fù)制很有好處。

還可以通過(guò)分發(fā)主庫(kù)實(shí)現(xiàn)其他目的，例如，對(duì)二進(jìn)制日志事件執(zhí)行過(guò)速和重寫(xiě)規(guī)則。這比在每個(gè)備庫(kù)上重復(fù)進(jìn)行日志記錄、重寫(xiě)和過(guò)濾要高效得多。如果在分發(fā)主庫(kù)上使用blackhole表，可以支持更多的備庫(kù)。雖然會(huì)在分發(fā)主庫(kù)執(zhí)行查詢(xún)，但其代價(jià)非常小，因?yàn)閎lackhole表中沒(méi)有任何數(shù)據(jù)。blockhole 表的缺點(diǎn)是其存在Bug,例如在某些情況下會(huì)忘記將自增ID寫(xiě)人到二進(jìn)制日志中。所以要小心使用blackhole表。

一個(gè)比較常見(jiàn)的問(wèn)題是如何確保分發(fā)

storage_ engine = blackhole

這只會(huì)影響那些沒(méi)有指定存儲(chǔ)引擎的CREATE TALE的語(yǔ)句，如果有一個(gè)無(wú)法控制的應(yīng)用，這種拓?fù)浣Y(jié)構(gòu)可能會(huì)非常脆弱。可以通過(guò)skip_innodb 選項(xiàng)禁止InoDB,將表退化為MyISAM。但你無(wú)法禁止MyISAM成者M(jìn)emory引擎。

使用分發(fā)主庫(kù)另外一個(gè)主要的缺點(diǎn)是無(wú)法使用一個(gè)備庫(kù)來(lái)代替主庫(kù)。因?yàn)橛捎诜职l(fā)主庫(kù)的存在，導(dǎo)致各個(gè)備庫(kù)與原始主庫(kù)的二進(jìn)制日志坐標(biāo)已經(jīng)不相同。

總結(jié)

以上是生活随笔為你收集整理的mysql 备库,高性能MySQL：主库、分发主库以及备库的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。