誤區(qū) #11:鏡像在檢測到故障后瞬間就能故障轉(zhuǎn)移

錯(cuò)誤 數(shù)據(jù)庫鏡像的故障轉(zhuǎn)移既可以自動(dòng)發(fā)起，也可以手動(dòng)發(fā)起。

在自動(dòng)發(fā)起的情況下,是由鏡像服務(wù)器執(zhí)行故障轉(zhuǎn)移操作（你沒有看錯(cuò)，并不是由見證服務(wù)器來做故障轉(zhuǎn)移的決定）,在見證服務(wù)器和鏡像服務(wù)器都發(fā)現(xiàn)無法和主體服務(wù)器交換信息(這個(gè)過程被稱為”形成仲裁”,譯者注:也就是通過程序?qū)哼M(jìn)行監(jiān)管，集群可用的依據(jù)來自監(jiān)管程序的算法，比如根據(jù):每個(gè)節(jié)點(diǎn)的配置，文件共享情況，磁盤訪問情況，每個(gè)節(jié)點(diǎn)的可用性等來確定集群是否可用)并且鏡像方式是同步時(shí)，可以進(jìn)行故障轉(zhuǎn)移。(譯者注：所謂的同步指的是主體服務(wù)器必須等待鏡像服務(wù)器的日志寫入后，才能夠提交事務(wù)。相對異步來說性能更差，但更安全，并且還不需要SQL Server是企業(yè)版)。

手動(dòng)故障轉(zhuǎn)移是由你發(fā)起的,手動(dòng)發(fā)起可能是由于不存在見證服務(wù)器(以至于無法“形成仲裁”)，或是在主體服務(wù)器現(xiàn)在問題時(shí)鏡像的運(yùn)行模式不是“同步”。

當(dāng)主體服務(wù)器發(fā)生故障時(shí)，鏡像服務(wù)器在日志隊(duì)列Redo完成之前不會上線(所謂的日志隊(duì)列就是由主體服務(wù)器傳送到鏡像服務(wù)器的日志，但還沒有在鏡像服務(wù)器Replay)。即使你鏡像的運(yùn)行模式是同步,也僅僅只能說明日志被寫入鏡像磁盤，但不能保證日志在鏡像服務(wù)器被重放。而對于故障轉(zhuǎn)移來說，鏡像服務(wù)器必須經(jīng)歷Roll Forward階段才能夠上線.但Roll Back階段是鏡像上線后才會做的。

在SQL Server標(biāo)準(zhǔn)版以及企業(yè)版所在的CPU低于5個(gè)內(nèi)核，Roll Forward只有一個(gè)線程。對于企業(yè)版并且CPU多余5核，為每4個(gè)核分配一個(gè)Roll Forward線程。所以完全可以看出故障轉(zhuǎn)移所需的時(shí)間取決于需要對日志進(jìn)行Redo處理的隊(duì)列大小，CPU的核數(shù)，以及鏡像服務(wù)器的負(fù)載。

由于大家都認(rèn)為鏡像工作在同步方式時(shí)可以迅速進(jìn)行故障轉(zhuǎn)移，所以很少有人檢測日志Redo隊(duì)列。但由于Redo隊(duì)列的大小確定了故障轉(zhuǎn)移時(shí)Downtime的大小，所以檢測鏡像服務(wù)器Redo隊(duì)列變得十分重要。

有關(guān)這里更細(xì)節(jié)的文章，你可以參看:Estimating the Interruption of Service During Role Switching

版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非maisonbaluchon.cn所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。