SQLServer-高可用、高性能和高保護(hù)延伸

SQLServer高可用、高性能和高保護(hù)延伸最近，和一個(gè)朋友談?wù)摳髯怨緦?duì)如何提高SQLServer數(shù)據(jù)庫(kù)的保護(hù)和數(shù)據(jù)庫(kù)可用性以及提高性能方面所采用的技術(shù)時(shí)，發(fā)現(xiàn)SQLServer有不少技術(shù)可用，而且有很多可以互補(bǔ)的地方，SQLServer雖沒有Oracle的RAC，但如果把它現(xiàn)有的技術(shù)充分發(fā)揮下，還是足以應(yīng)付絕大部分的情況的（遺憾的是有些技術(shù)在性能和可靠性方面還是有些不成熟,出現(xiàn)問題很難搞定）。很多公司保護(hù)數(shù)據(jù)，最先用到的基本都是備份（這個(gè)是必不可少，也是最節(jié)約成本的方法了），基本的備份有三種，全備、差異和日志（當(dāng)然還有基于文件、文件組、Page等的備份方案，不做討論），如何合理的安排這些備份計(jì)劃，需要根據(jù)應(yīng)用系統(tǒng)的業(yè)務(wù)要求和特點(diǎn)來定，還得考慮備份文件的保留時(shí)間、備份頻率等。本地備份但是隨著數(shù)據(jù)量的增加，同時(shí)考慮一些安全性的原因，將數(shù)據(jù)都保存到本機(jī)硬盤的方案變得不可取，于是考慮購(gòu)買一臺(tái)磁帶機(jī)，將備份的數(shù)據(jù)從本地磁盤，轉(zhuǎn)移到磁帶機(jī)上，本地磁盤只保留一份最新的全套備份；一方面可以解決磁盤空間問題，同時(shí)還將數(shù)據(jù)備份到了其他設(shè)備中，增強(qiáng)了數(shù)據(jù)的安全性。磁帶機(jī)備份有了完善的數(shù)據(jù)庫(kù)備份方案，視乎我們的數(shù)據(jù)得到了有效的保護(hù)，但是想象下，如果我們的服務(wù)器真出現(xiàn)故障，服務(wù)器起不來了，該怎么做呢？當(dāng)然是按我們的備份計(jì)劃，將數(shù)據(jù)從最新的全備份開始，然后差異，然后再日志還原過來；假定我們的備份文件100%的可用（不可用的情況也經(jīng)常發(fā)生哦），如果數(shù)據(jù)庫(kù)小，那不久就可以還原好，但是如果是個(gè)幾百G的數(shù)據(jù)庫(kù)，要按這樣一步步還原，而此時(shí)后面一堆人都掛著等你的數(shù)據(jù)庫(kù)恢復(fù)，boss過兩分鐘過來問下情況，手里的電話被各個(gè)需要使用的部門打爆…，這時(shí)候沒有強(qiáng)悍的心理素質(zhì)，估計(jì)早就崩潰了；并且備份還有時(shí)間選擇，比方你一個(gè)小時(shí)備份一個(gè)日志文件，但是如果數(shù)據(jù)庫(kù)某天運(yùn)行到1：50分左右突然掛掉了，此時(shí)如果備份不到最后50分鐘的日志信息，那你這50分鐘所產(chǎn)生的數(shù)據(jù)就找不回了。正因?yàn)檫@樣的備份恢復(fù)方案無法達(dá)到我們及時(shí)恢復(fù)數(shù)據(jù)庫(kù)和最大限度保障數(shù)據(jù)的要求，于是我們不得不考慮其他更快恢復(fù)數(shù)據(jù)并減少數(shù)據(jù)丟失的方案，我們先考慮SQLServer給我們提供的方案（硬件方案后面討論），數(shù)據(jù)庫(kù)里面有兩種技術(shù)方案可以使用，一種是Mirroring，另一種是Logshipping（兩種技術(shù)的細(xì)節(jié)這里不討論）。Mirroring/Logshipping有了mirroring和logshipping（稱備機(jī)），我們不但縮短了數(shù)據(jù)庫(kù)恢復(fù)的時(shí)間，減少了數(shù)據(jù)丟失的可能，還可以將某些不需要完全實(shí)時(shí)的操作放到備機(jī)上（如：BI抽取數(shù)據(jù)，做報(bào)表等），真是一舉兩得；不過，采取Mirroring和Logshipping會(huì)增加服務(wù)器的負(fù)擔(dān)（不過一般都可以接受），Mirroring技術(shù)的高安全性可以最大限度保護(hù)數(shù)據(jù)不丟失，但對(duì)主服務(wù)器影響較大（需要等待備服務(wù)器響應(yīng)和回傳信息），高可用性能提高恢復(fù)數(shù)據(jù)庫(kù)上線的速度，但是需要增加一臺(tái)見證機(jī)，高可用性對(duì)數(shù)據(jù)的保護(hù)要稍微差點(diǎn)（主要取決于服務(wù)器性能和網(wǎng)絡(luò)帶寬），但對(duì)主服務(wù)器性能影響較??；而Logshipping是定期備份日志，然后傳到備機(jī)上還原，數(shù)據(jù)丟失多少取決于備份和傳送的頻率，同時(shí)這兩項(xiàng)技術(shù)還增加了部分硬件投入（需要備機(jī)）。這樣做之后，對(duì)一些普通的系統(tǒng)基本都可以應(yīng)付了，但是對(duì)那些需要7×24小時(shí)不間斷提供服務(wù)的應(yīng)用還是有所不足；例如：如果我們數(shù)據(jù)庫(kù)服務(wù)器一塊網(wǎng)卡壞了，或者操作系統(tǒng)崩潰了（但數(shù)據(jù)庫(kù)本身沒問題），那我們不得不停止業(yè)務(wù)來進(jìn)行更換網(wǎng)卡或者啟用備機(jī)來提供服務(wù)，影響了業(yè)務(wù)的進(jìn)行；想象一下，淘寶這類的在線交易購(gòu)物網(wǎng)站，一天的交易筆數(shù)有多少，當(dāng)機(jī)一分鐘都可能有上千萬的損失（個(gè)人估計(jì)，沒實(shí)際調(diào)研，淘寶也不用SQLServer，呵呵），為應(yīng)對(duì)這些在線時(shí)間要求高的情況，我們的Cluster就應(yīng)運(yùn)而生了。Cluster通過用兩臺(tái)服務(wù)器來連接一個(gè)數(shù)據(jù)庫(kù)（形式有多種），也就是說兩套硬件服務(wù)器和兩套操作系統(tǒng)來支持一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)的運(yùn)行，數(shù)據(jù)都存放到磁盤陣列中，磁盤陣列可以采用Raid技術(shù)來提供磁盤的冗余；這樣相當(dāng)于為SQLServer提供了兩套訪問設(shè)備，一套壞了，另一套立馬可以頂替過來，這大大縮短了故障恢復(fù)的時(shí)間，差不多只相當(dāng)于重啟了一次數(shù)據(jù)庫(kù)而已，（當(dāng)然還有資源轉(zhuǎn)移的時(shí)間，但一般不會(huì)太長(zhǎng)），不過這樣設(shè)備投入就更多了。Cluster通過這些技術(shù)后，數(shù)據(jù)保護(hù)和在線能力都有了很大的提高，但是這么多的操作都集中到了存儲(chǔ)上，當(dāng)訪問量很大時(shí)，存儲(chǔ)就成了數(shù)據(jù)庫(kù)系統(tǒng)的瓶頸，那該如何處理呢？有兩種思路，一提高存儲(chǔ)系統(tǒng)的性能，使用轉(zhuǎn)速更快，性能更好的磁盤，所以現(xiàn)在出現(xiàn)了很火的SSD；二拆分業(yè)務(wù)或者是使用讀寫分離，將對(duì)一臺(tái)數(shù)據(jù)庫(kù)的訪問分散到多臺(tái)機(jī)器上，減輕單臺(tái)的壓力。SSD磁盤讀寫分離業(yè)務(wù)拆分這樣就足夠了嗎？知道911嗎？像911那樣的事故，可能我們都不會(huì)遇到，但是，電信機(jī)房起火事件發(fā)生的概率還是有的（里面機(jī)器多呀），如果這樣的情況發(fā)生，如果我們沒有提前做好應(yīng)對(duì)方案的話，一切就都o(jì)ver了；于是異地容災(zāi)就被提出來了，主要有異地備份和異地機(jī)房方案（異地備份就不講啦）；如果建了異地機(jī)房，那怎么樣同步數(shù)據(jù)就是個(gè)頭大的問題，目前大部分硬件提供商提供的方案是磁盤同步的方案，兩地機(jī)房之間用光纖相連（成本呀），當(dāng)A機(jī)房的某個(gè)磁盤寫數(shù)據(jù)時(shí)，通過光纖將這些數(shù)據(jù)傳到B機(jī)房對(duì)應(yīng)的磁盤上，這樣就完成了兩個(gè)磁盤數(shù)據(jù)的同步（至于這個(gè)同步有多大的延時(shí)，就不好說啦）；A、B機(jī)房采用同樣的架構(gòu)，正常情況下只有A機(jī)房的磁盤對(duì)外提供服務(wù)，B機(jī)房的磁盤不提供對(duì)外訪問(起碼不