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

錯誤

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

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

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

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

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

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

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