項(xiàng)目一：單節(jié)點(diǎn)數(shù)據(jù)庫(kù)轉(zhuǎn)到oracle rac

?

項(xiàng)目簡(jiǎn)介（功能與用途）：

項(xiàng)目發(fā)生在04年初，由于當(dāng)時(shí)采用的是基于linux的pc server，隨著網(wǎng)站訪問(wèn)量的突飛猛漲，單臺(tái)linux server已經(jīng)基本達(dá)到了瓶頸，主機(jī)端系統(tǒng)load基本在10以上，由于linux server的硬件已經(jīng)不能擴(kuò)展，而當(dāng)時(shí)的預(yù)算又不夠采用小型機(jī)，所以需要有一種可擴(kuò)展方案來(lái)解決。這個(gè)時(shí)候我們就想到了使用oracle 9i rac來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)的橫向擴(kuò)展，同時(shí)對(duì)應(yīng)用系統(tǒng)做切分，分成了3個(gè)數(shù)據(jù)庫(kù)，每個(gè)庫(kù)設(shè)計(jì)容量是2個(gè)節(jié)點(diǎn)，可以提供一天5000萬(wàn)次訪問(wèn)量的方案。

?

項(xiàng)目難點(diǎn)與解決方案：

在確定方案后，我們開始針對(duì)機(jī)器進(jìn)行選型測(cè)試，對(duì)比hp4640和sun880單節(jié)點(diǎn)數(shù)據(jù)庫(kù)和dell linux server跑oracle rac的性能，我們的測(cè)試團(tuán)隊(duì)設(shè)計(jì)了測(cè)試用例，用app集群直接跑網(wǎng)站真實(shí)應(yīng)用去測(cè)試數(shù)據(jù)庫(kù)性能，測(cè)試結(jié)果在相同訪問(wèn)量下dell pc server跑2個(gè)節(jié)點(diǎn)的rac的sql相應(yīng)時(shí)間最短，所以最終選定了dell linux server＋oracle rac的方案。在存儲(chǔ)方面我們最初是用netapp的nas存儲(chǔ)作為數(shù)據(jù)庫(kù)存儲(chǔ)，但是在使用過(guò)程中發(fā)現(xiàn)netapp的nas存儲(chǔ)在數(shù)據(jù)塊頻繁變化的環(huán)境下多塊讀的效率不是十分理想，所以決定采用emc 的CLARiiON系列存儲(chǔ)。選型完畢后項(xiàng)目進(jìn)入實(shí)施階段,實(shí)施初期是搭建san存儲(chǔ)架構(gòu)，把所有emc存儲(chǔ)通過(guò)光纖交換機(jī)和主機(jī)相連，每2臺(tái)pc server拖一臺(tái)存儲(chǔ)，一共是6臺(tái)pc server加3套存儲(chǔ)。在存儲(chǔ)架構(gòu)搭建完畢后，我們開始創(chuàng)建oracle rac，采用2個(gè)節(jié)點(diǎn)的rac， 然后開始進(jìn)行數(shù)據(jù)遷移方案，我們使用oracle 的materialized view來(lái)同步大表，在切換前幾天基本實(shí)現(xiàn)新老系統(tǒng)的大表持續(xù)同步，在系統(tǒng)切換當(dāng)晚我們切斷老系統(tǒng)，刷新materialized view最后一點(diǎn)還沒(méi)同步的數(shù)據(jù)到新系統(tǒng)，同時(shí)遠(yuǎn)程insert小表到新系統(tǒng)，總共切換時(shí)間在30分鐘之內(nèi)完成。系統(tǒng)切換后重新啟動(dòng)應(yīng)用服務(wù)器，整個(gè)應(yīng)用系統(tǒng)正常提供服務(wù)。

?

項(xiàng)目成功與失敗的經(jīng)驗(yàn)歸納：

在新系統(tǒng)上線后，主機(jī)端load下降到0.5左右，用戶反映系統(tǒng)相應(yīng)速度明顯提升，app服務(wù)器的等待隊(duì)列明顯減少，在很長(zhǎng)一段時(shí)間里面這套系統(tǒng)都表現(xiàn)出了相當(dāng)穩(wěn)定的運(yùn)行狀態(tài)。

這是我們第一次使用集群數(shù)據(jù)庫(kù)，同時(shí)也是第一次使用san存儲(chǔ)，整個(gè)方案完全由我們的DBA,SA,JAVA構(gòu)架師，測(cè)試團(tuán)隊(duì)制定并實(shí)施，在當(dāng)時(shí)的業(yè)界我們的做法還是比較領(lǐng)先的，也是oracle rac的早期用戶。在一段時(shí)間的穩(wěn)定期后，由于業(yè)務(wù)的飛速發(fā)展，我們的系統(tǒng)訪問(wèn)量達(dá)到了8000萬(wàn)次每天，在這個(gè)時(shí)候rac的一些弊端開始顯示出來(lái)，由于應(yīng)用沒(méi)有不是針對(duì)RAC系統(tǒng)專門開發(fā)的，所以rac cache fusion的代價(jià)非常大，在變化頻繁的系統(tǒng)上，rac 的一系列wait event占據(jù)了大部分的系統(tǒng)等待時(shí)間，系統(tǒng)效率開始下降。同時(shí)當(dāng)一個(gè)節(jié)點(diǎn)發(fā)生問(wèn)題時(shí)而down掉時(shí)，另一個(gè)節(jié)點(diǎn)要恢復(fù)壞掉的節(jié)點(diǎn)的數(shù)據(jù)，在這個(gè)恢復(fù)階段所有應(yīng)用將hang住直到恢復(fù)完畢，通常在這個(gè)時(shí)間段里面前臺(tái)的app服務(wù)器由于請(qǐng)求太多不能響應(yīng)而掛掉，所以基本上在繁忙的系統(tǒng)上rac的平滑切換將很難實(shí)現(xiàn)，這也決定了我們后來(lái)從RAC退回到單節(jié)點(diǎn)數(shù)據(jù)庫(kù)。

?

你在項(xiàng)目中崗位與貢獻(xiàn)：

負(fù)責(zé)制定產(chǎn)品預(yù)算 負(fù)責(zé)產(chǎn)品選型溝通

參與制定測(cè)試用例 參與測(cè)試

負(fù)責(zé)San網(wǎng)絡(luò)搭建 負(fù)責(zé)系統(tǒng)安裝調(diào)試

負(fù)責(zé)存儲(chǔ)規(guī)劃 負(fù)責(zé)數(shù)據(jù)庫(kù)建立

負(fù)責(zé)數(shù)據(jù)遷移 負(fù)責(zé)系統(tǒng)切換

負(fù)責(zé)后期維護(hù) 負(fù)責(zé)后期應(yīng)用優(yōu)化

sql審核，sql培訓(xùn)

?

?

?

?

項(xiàng)目二：dell linux server向ibm p590系統(tǒng)遷移

項(xiàng)目簡(jiǎn)介（功能與用途）：

項(xiàng)目發(fā)生在05年初，距離上次系統(tǒng)升級(jí)一年時(shí)間，在這一年時(shí)間里，公司業(yè)務(wù)飛速發(fā)展，日訪問(wèn)量從2000萬(wàn)次增長(zhǎng)到8000萬(wàn)次以上，oracle rac在這急速增長(zhǎng)的壓力下也暴露出一些問(wèn)題，由于rac cache fusion的內(nèi)耗越來(lái)越嚴(yán)重，再對(duì)rac擴(kuò)展節(jié)點(diǎn)的方案基本被否定，同時(shí)因?yàn)?/span>rac的維護(hù)成本比單節(jié)點(diǎn)數(shù)據(jù)庫(kù)要高很多，所以我們定下來(lái)下一步方案要采用基于UNIX小型機(jī)的單節(jié)點(diǎn)數(shù)據(jù)庫(kù)。系統(tǒng)設(shè)計(jì)容量要求要能支撐2億次每天的訪問(wèn)量。

?

項(xiàng)目難點(diǎn)與解決方法：

和上一次升級(jí)一樣，我們從硬件測(cè)試選型開始，這次我們選型了hp superdome Integrity服務(wù)器和IBM P590進(jìn)行對(duì)比測(cè)試。和上次系統(tǒng)升級(jí)一樣，我們的DBA,測(cè)試團(tuán)隊(duì)，JAVA架構(gòu)師組成了一個(gè)特別測(cè)試組去hp和ibm的測(cè)試中心進(jìn)行了對(duì)比測(cè)試，用我們自己的系統(tǒng)跑測(cè)試，最后對(duì)比下來(lái)IBM的P590在高并發(fā)情況下機(jī)器的響應(yīng)時(shí)間曲線比較平穩(wěn)，同時(shí)由于AIX系統(tǒng)的很多自動(dòng)化管理功能可以簡(jiǎn)化對(duì)主機(jī)的維護(hù)工作，我們最終選定了IBM P590做為新的數(shù)據(jù)庫(kù)服務(wù)器。在存儲(chǔ)方面，我們處于成本考慮并沒(méi)有更換原先的存儲(chǔ)，繼續(xù)使用了EMC CLARiiON系列存儲(chǔ)。由于我們?cè)谏弦淮蜗到y(tǒng)升級(jí)后對(duì)所有rac數(shù)據(jù)庫(kù)又建立了dataguard做備份數(shù)據(jù)庫(kù)，這次升級(jí)我們把dataguard庫(kù)的CLARiiON存儲(chǔ)先行接到了P590上，然后在p590上建立oracle數(shù)據(jù)庫(kù)，同上次系統(tǒng)升級(jí)一樣，我們采用materialized view來(lái)同步數(shù)據(jù)，力求達(dá)到最短停機(jī)時(shí)間。同時(shí)我們調(diào)整了我們所有的監(jiān)控腳本，保證了新系統(tǒng)的預(yù)警功能。另外我們建立了dataguard系統(tǒng)，保證了系統(tǒng)的可靠性。最終切換時(shí)間我們也控制在了每個(gè)數(shù)據(jù)庫(kù)30分鐘以內(nèi)。

?

項(xiàng)目成功與失敗的經(jīng)驗(yàn)歸納：

P590系統(tǒng)上線后，我們的系統(tǒng)load從6下降到1以下，另外我們使用了AIX的LVM來(lái)管理磁盤，降低了很多原來(lái)使用linux raw device管理上的成本。

這是我們第一次使用基于UNIX的服務(wù)器，也是國(guó)內(nèi)最早一批使用P590的用戶，在系統(tǒng)上線相當(dāng)長(zhǎng)的一段時(shí)間內(nèi)都保證了業(yè)務(wù)的可持續(xù)快速發(fā)展。在系統(tǒng)升級(jí)的實(shí)施方面由于有了上一次的經(jīng)驗(yàn)，這次升級(jí)做到了更加平滑的切換，所有的監(jiān)控腳本都經(jīng)過(guò)測(cè)試運(yùn)行，保證了新系統(tǒng)的預(yù)警。在這套系統(tǒng)跑了一段時(shí)間以后，主機(jī)端依然提供了非常強(qiáng)勁的功能，但是由于數(shù)據(jù)庫(kù)的不斷擴(kuò)大，越來(lái)越多的i/o等待開始暴露出來(lái)，針對(duì)這個(gè)問(wèn)題我們升級(jí)了主機(jī)的內(nèi)存，加大了data buffer,同時(shí)為了保證系統(tǒng)的可擴(kuò)展性，我們最終選用了sun 9990系列存儲(chǔ)，基本上是系統(tǒng)實(shí)現(xiàn)了線性可擴(kuò)。

?

你在項(xiàng)目中崗位與貢獻(xiàn)：

負(fù)責(zé)制定產(chǎn)品預(yù)算

負(fù)責(zé)產(chǎn)品選型溝通

參與制定測(cè)試用例

參與測(cè)試

負(fù)責(zé)San網(wǎng)絡(luò)搭建

負(fù)責(zé)存儲(chǔ)規(guī)劃

負(fù)責(zé)系統(tǒng)安裝調(diào)試

負(fù)責(zé)數(shù)據(jù)庫(kù)建立

負(fù)責(zé)數(shù)據(jù)遷移

負(fù)責(zé)系統(tǒng)切換

負(fù)責(zé)監(jiān)控體系建立

負(fù)責(zé)后期維護(hù)

負(fù)責(zé)后期應(yīng)用優(yōu)化，sql審核，sql培訓(xùn)

?

?

?

?

項(xiàng)目三：淘寶網(wǎng)遠(yuǎn)程容災(zāi)站點(diǎn),建立容災(zāi)數(shù)據(jù)庫(kù)

項(xiàng)目簡(jiǎn)介（功能與用途）：

在系統(tǒng)切換到了UNIX平臺(tái)后，我們的關(guān)注點(diǎn)從性能開始轉(zhuǎn)換到高可用性上，陸續(xù)建立了dataguard，hacmp，提高了系統(tǒng)的高可用性。這個(gè)時(shí)候我們覺得應(yīng)該考慮災(zāi)備，美國(guó)的911事件導(dǎo)致了很多公司一夜之間所有數(shù)據(jù)都消失無(wú)蹤，對(duì)于我們這種對(duì)數(shù)據(jù)庫(kù)依賴性極大的公司來(lái)說(shuō)，數(shù)據(jù)就是生命，我們一定要做好災(zāi)難備份。處于成本和實(shí)施難度考慮，我們提出了整個(gè)災(zāi)備的過(guò)程分3部走的想法，首先建立一個(gè)最簡(jiǎn)單的容災(zāi)站點(diǎn)，可以保證數(shù)據(jù)不丟失，但災(zāi)備站點(diǎn)不提供對(duì)外服務(wù)。第二步，實(shí)現(xiàn)準(zhǔn)實(shí)時(shí)不同城市間的復(fù)制，災(zāi)備站點(diǎn)不對(duì)外提供服務(wù)，但是碰到主站點(diǎn)災(zāi)難可以切換到災(zāi)備站點(diǎn)進(jìn)行服務(wù)。第三步，準(zhǔn)實(shí)時(shí)的多站點(diǎn)復(fù)制，災(zāi)備站點(diǎn)同時(shí)提供服務(wù)。

?

?

?

項(xiàng)目難點(diǎn)與解決方法：

由于實(shí)施第一步方案受限于預(yù)算和災(zāi)備機(jī)房的線路問(wèn)題，我們把災(zāi)備站點(diǎn)定在本城市另一端的一個(gè)機(jī)房，通過(guò)裸光纖鏈路和主站點(diǎn)相連，采用了低于主站點(diǎn)的服務(wù)器配置，用了一臺(tái)IBM P550服務(wù)器做為3個(gè)主庫(kù)的dataguard，連接一臺(tái)EMC CLARiiON存儲(chǔ)，dataguard端一直處于恢復(fù)狀態(tài)，實(shí)現(xiàn)在災(zāi)難時(shí)最多發(fā)生20分鐘的的數(shù)據(jù)丟失。

?

?

?

?

?

項(xiàng)目成功與失敗的經(jīng)驗(yàn)歸納：

項(xiàng)目上線后數(shù)據(jù)同步良好，基本實(shí)現(xiàn)系統(tǒng)設(shè)計(jì)目標(biāo)，以最小的成本構(gòu)建了一套可用的災(zāi)備系統(tǒng)。

項(xiàng)目實(shí)施成本一直是私營(yíng)企業(yè)最關(guān)注的，我們的所有項(xiàng)目都面臨著把每一分錢花在刀刃上，所有的項(xiàng)目方案都由公司內(nèi)部人員討論得出，顯示了團(tuán)隊(duì)的強(qiáng)大的戰(zhàn)斗力。在我們以后的項(xiàng)目中，我們依然會(huì)追求以最小成本獲得最大收益，我相信中國(guó)絕大部分公司都是中小企業(yè)，都將會(huì)面臨到和我們一樣的問(wèn)題，我們走過(guò)的路，做過(guò)的項(xiàng)目是對(duì)他們最好的指導(dǎo)。

?

?

?

?

你在項(xiàng)目中崗位與貢獻(xiàn)：

負(fù)責(zé)制定產(chǎn)品預(yù)算

負(fù)責(zé)產(chǎn)品選型溝通

負(fù)責(zé)San網(wǎng)絡(luò)搭建

負(fù)責(zé)系統(tǒng)安裝調(diào)試

負(fù)責(zé)存儲(chǔ)規(guī)劃

負(fù)責(zé)數(shù)據(jù)庫(kù)建立

負(fù)責(zé)監(jiān)控體系建立

負(fù)責(zé)后期維護(hù)

?

?

?

?