誤區(qū) #11:鏡像在檢測(cè)到故障后瞬間就能故障轉(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ù)。相對(duì)異步來說性能更差，但更安全，并且還不需要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完成之前不會(huì)上線(所謂的日志隊(duì)列就是由主體服務(wù)器傳送到鏡像服務(wù)器的日志，但還沒有在鏡像服務(wù)器Replay)。即使你鏡像的運(yùn)行模式是同步,也僅僅只能說明日志被寫入鏡像磁盤，但不能保證日志在鏡像服務(wù)器被重放。而對(duì)于故障轉(zhuǎn)移來說，鏡像服務(wù)器必須經(jīng)歷Roll Forward階段才能夠上線.但Roll Back階段是鏡像上線后才會(huì)做的。

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

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

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

最新評(píng)論