通過(guò)負(fù)載均衡功能在MySQL數(shù)據(jù)庫(kù)中的實(shí)現(xiàn)，我們?cè)诖嗽跒榇蠹已a(bǔ)充一些知識(shí)。我們?cè)诓渴鸱?wù)器負(fù)載均衡功能時(shí)，需要注意一些問(wèn)題，以及在部署過(guò)程和實(shí)現(xiàn)過(guò)程中常遇到的故障問(wèn)題進(jìn)行了分析。

注意事項(xiàng)

正確部署實(shí)現(xiàn)具有負(fù)載均衡功能的MySQL服務(wù)器集群必須注意以下事項(xiàng):

(1). MySQL數(shù)據(jù)庫(kù)復(fù)制(replication)特性是核心

此處的復(fù)制不是簡(jiǎn)單的copy,從屬服務(wù)器啟動(dòng)兩個(gè)線程(thread):I/O線程和SQL線程,I/O線程接收主服務(wù)器對(duì)參與復(fù)制數(shù)據(jù)庫(kù)的更新操作事件(event),并記入自己的中繼二進(jìn)制更新日志文件(hostname-relay-bin.00000n),由SQL線程將更新操作寫入自己的數(shù)據(jù)庫(kù)表項(xiàng)｡主從服務(wù)器之間復(fù)制的不是具體的數(shù)據(jù)內(nèi)容,而是具體的以二進(jìn)制格式記錄的操作事件,因而在一定程度上實(shí)現(xiàn)主從服務(wù)器之間的數(shù)據(jù)同步｡(這種復(fù)制類似于生物學(xué)意義上的按基因復(fù)制,在英語(yǔ)中replication的主要詞義就是指該種復(fù)制｡)

(2). 復(fù)制的復(fù)雜性

主從數(shù)據(jù)庫(kù)服務(wù)器間的replication要求Master與Slave上的MySQL版本最好一致,主從服務(wù)器必須設(shè)置相同的字符集,否則很容易造成復(fù)制失敗｡主服務(wù)器上更新權(quán)限表內(nèi)容的FLUSH語(yǔ)句不會(huì)被復(fù)制[8]｡

(3). 按照范式化要求設(shè)計(jì)數(shù)據(jù)庫(kù)

生產(chǎn)環(huán)境下基于MySQL服務(wù)器的應(yīng)用系統(tǒng)要想穩(wěn)定運(yùn)行,按范式化設(shè)計(jì)系統(tǒng)數(shù)據(jù)庫(kù)是基本要求,具體內(nèi)容可參考相關(guān)書(shū)籍｡

(4). 打開(kāi)數(shù)據(jù)庫(kù)服務(wù)器的遠(yuǎn)程用戶連接功能

打開(kāi)主從服務(wù)器的遠(yuǎn)程用戶連接是實(shí)現(xiàn)更新､查詢操作分別定向的必要條件,否則,來(lái)自應(yīng)用服務(wù)器的連接請(qǐng)求失敗,影響系統(tǒng)應(yīng)用正常運(yùn)行｡

(5). 負(fù)載均衡功能的實(shí)現(xiàn)需要良好的團(tuán)隊(duì)合作

BIND DNS服務(wù)器實(shí)現(xiàn)了從屬服務(wù)器Slave之間的負(fù)載均衡,Slave和Master之間的負(fù)載均衡則由應(yīng)用系統(tǒng)開(kāi)發(fā)人員在程序代碼級(jí)實(shí)現(xiàn)｡整個(gè)系統(tǒng)的性能提升和冗余容錯(cuò)需要網(wǎng)絡(luò)管理和應(yīng)用系統(tǒng)開(kāi)發(fā)團(tuán)隊(duì)之間的良好合作,否則負(fù)載均衡功能的實(shí)現(xiàn)就會(huì)失敗｡

常見(jiàn)問(wèn)題

(1). 如何估算MySQL服務(wù)器集群的性能提升量?

針對(duì)本文采用的結(jié)構(gòu)模式,可對(duì)應(yīng)用系統(tǒng)整體性能提升做出大致估算｡假設(shè)應(yīng)用系統(tǒng)寫操作占10%,讀操作占90%,寫操作耗時(shí)是讀操作的2倍,系統(tǒng)的吞吐量(throughput)為T(用reads/s讀操作次數(shù)/秒來(lái)衡量)｡把寫操作線性轉(zhuǎn)換為讀操作,則有:

T= 2Xwrites + 9Xwrites ==>writes=T/11① (不采用主從復(fù)制模式,讀寫操作集中到一個(gè)服務(wù)器上)

T= 2Xwrites + 9Xwrites/N ==> writes=T/(2+9/N)② (采用一對(duì)多的主從復(fù)制模式,讀操作在從屬服務(wù)器,寫操作在主服務(wù)器)

其中,writes為系統(tǒng)單位時(shí)間內(nèi)所能承受的最大寫操作次數(shù),N為從屬服務(wù)器個(gè)數(shù),N大于等于2｡在不采用主從復(fù)制模式時(shí),系統(tǒng)性能writes=T/11;采用本文一對(duì)三的復(fù)制模式時(shí),系統(tǒng)性能writes=T/5｡采用負(fù)載均衡模式與不采用系統(tǒng)性能之比為11:5,即2.2:1,考慮到應(yīng)用服務(wù)器的額外開(kāi)銷,系統(tǒng)整體性能提升了整整1倍!從②式可以看出,系統(tǒng)整體性能理論極限為T/2,當(dāng)然在實(shí)際生產(chǎn)環(huán)境中不可能達(dá)到｡具體部署時(shí)用戶可以根據(jù)自己的實(shí)際情況估算出合理的從屬服務(wù)器數(shù)量,主要影響因素是網(wǎng)絡(luò)帶寬和機(jī)器整體性能[9]｡

(2). 如何應(yīng)對(duì)主從服務(wù)器崩潰?

當(dāng)某臺(tái)從屬服務(wù)器崩潰時(shí),修復(fù)故障重啟后重新連接到主服務(wù)器,根據(jù)其master.info文件更新其數(shù)據(jù),保持與主服務(wù)器的數(shù)據(jù)同步｡如果主服務(wù)器崩潰,在某一從屬服務(wù)器上執(zhí)行STOP SLAVES; GRANT REPLICATION SLAVE ON *.* repl_db TO ‘repl'@'%' IDENTIFIED BY‘g00r002b';RESET MASTER;這三個(gè)SQL語(yǔ)句,由于從屬服務(wù)器已啟動(dòng)了二進(jìn)制更新日志功能,因此具備了角色轉(zhuǎn)換的必要條件｡更改其主機(jī)名､IP地址及server-id與Master一樣,重啟MySQL服務(wù)器,系統(tǒng)開(kāi)始正常對(duì)外提供服務(wù)｡其它兩臺(tái)從屬服務(wù)器則不需執(zhí)行任何操作,繼續(xù)執(zhí)行replication過(guò)程｡BIND DNS服務(wù)器和應(yīng)用程序也不需做任何調(diào)整,繼續(xù)對(duì)系統(tǒng)用戶提供不間斷服務(wù)｡主服務(wù)器排除故障恢復(fù)正常后,將其網(wǎng)絡(luò)配置改為與現(xiàn)有Master轉(zhuǎn)換角色之前一樣的配置,重啟MySQL服務(wù),將其角色轉(zhuǎn)換為從屬服務(wù)器｡也就是說(shuō),整個(gè)集群機(jī)器的角色可以相互循環(huán)轉(zhuǎn)換,提高系統(tǒng)的冗余性和可靠性｡在此需要注意的是,在應(yīng)用系統(tǒng)調(diào)試運(yùn)行正常之后,在Slave角色服務(wù)器的/etc/my.cnf文件[mysqld]段加入slave-skip-errors=all,保證集群之間復(fù)制(replication)的正常運(yùn)行｡

結(jié)束語(yǔ)

部署與實(shí)現(xiàn)具有負(fù)載均衡功能的MySQL服務(wù)器集群是一項(xiàng)復(fù)雜的系統(tǒng)工程,需要多方面良好的協(xié)同合作才能做好｡服務(wù)器的搭建配置､BIND DNS服務(wù)器的配置部署,以及應(yīng)用系統(tǒng)程序的開(kāi)發(fā)都要緊緊圍繞實(shí)現(xiàn)MySQL服務(wù)器集群負(fù)載均衡功能這個(gè)目標(biāo)｡必須對(duì)主服務(wù)器的運(yùn)行狀態(tài)進(jìn)行動(dòng)態(tài)監(jiān)控,如果發(fā)生故障,立即執(zhí)行角色轉(zhuǎn)換過(guò)程,確保為終端用戶提供可靠､不間斷的服務(wù)｡可以針對(duì)具體系統(tǒng)環(huán)境寫出監(jiān)控腳本或程序,確保系統(tǒng)的可靠性與穩(wěn)定性｡