SQL Server誤區30日談 第11天 鏡像在檢測到故障後瞬間就能容錯移轉

誤區 #11:鏡像在檢測到故障後瞬間就能容錯移轉

錯誤

資料庫鏡像的容錯移轉既可以自動發起，也可以手動發起。

在自動發起的情況下,是由鏡像伺服器執行容錯移轉操作（你沒有看錯，並不是由見證伺服器來做容錯移轉的決定）,在見證伺服器和鏡像伺服器都發現無法和主體伺服器交換資訊(這個過程被稱為”形成仲裁”,譯者注:也就是通過程式對叢集進行監管，叢集可用的依據來自監管程式的演算法，比如根據:每個節點的配置，檔案分享權限設定情況，磁碟訪問情況，每個節點的可用性等來確定叢集是否可用)並且鏡像方式是同步時，可以進行容錯移轉。(譯者註：所謂的同步指的是主體伺服器必須等待鏡像伺服器的日誌寫入後，才能夠提交事務。相對非同步來說效能更差，但更安全，並且還不需要SQL Server是企業版)。

手動容錯移轉是由你發起的,手動發起可能是由於不存在見證伺服器(以至於無法“形成仲裁”)，或是在主體伺服器現在問題時鏡像的運行模式不是“同步”。

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

在SQL Server標準版以及企業版所在的CPU低於5個核心，Roll Forward只有一個線程。對於企業版並且CPU多餘5核，為每4個核分配一個Roll Forward線程。所以完全可以看出容錯移轉所需的時間取決於需要對日誌進行Redo處理的隊列大小，CPU的核心數，以及鏡像伺服器的負載。

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

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