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

錯誤

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

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

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

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

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

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

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

最新評論