Data Guard中快速Switchover,Failover的一些建議

Data Guard中快速Switchover,Failover的一些建議

其實對於Failover和Switchover是大家處理災難時很頭疼的一個環節，也是最關鍵的處理過程。

假設你半夜正在睡覺，被警示電話驚醒，得知某個伺服器產生了故障宕機，在這種情況下，我們大體會有下面的處理流程：

1）檢查原來的節點是否可用，需要查看ILO和儲存，是否存在異常

2）如果原來的節點可以重啟，可以盡量馬上恢複業務，然後分析根本原因，是否是硬體老化，硬體故障導致，如果發現問題影響較大，可以使用Switchover

3）如果原來的節點無法重啟，這個時候需要考慮Failover,如果在同機房可以直接替換IP，異地機房需要配合開發，系統營運來修改應用串連IP

4) 配合系統，開發，檢查業務是否恢複正常

這個時候有幾個問題就擺在了眼前

1）原來庫的防火牆資訊在Failover之後，備庫本身是沒有的。這個怎麼辦，一種臨時解決辦法就是關閉防火牆，然後允許應用都串連進來，在後台收集串連伺服器資訊和連接埠，收集到一定程度之後，開啟防火牆，另外一種方式就是從曆史的備份中找到，開啟防火牆

2）Switchover,Failover之後，主備庫的多監聽連接埠是否一致，要不資料庫間通訊沒問題，很可能應用串連的連接埠不一而導致串連問題

3）主備庫切換後，部分db link不可用，究其原因還是tnsnames.ora中的主機名稱配置不夠統一，缺少許可權導致。

還有更多的細節問題，比較參數檔案不統一，核心參數檔案不統一導致的配置問題，效能問題。

所以我們需要快速Swithover,Failover,資料的切換之外，這些額外的工作花費的時間要遠多於切換。

當然我之前也分析過命令的方式切換，也寫過一些指令碼輔助。從根本上來說，Switchover和Failover的差別很小，對於備庫來說都是透明的，只是一種狀態標示。所以我們可以簡化switchover和Failover的一些內容，其實操作上來說，主要的區別就是是否修改IP,switchover可能會替換IP,而Failover可能會修改備庫IP為原來的主庫IP

在這一點上看起來不好統一，其實進一步分析，如果我們使用主機名稱的方式在listenerora,tnsnames.ora，那麼在/etc/hosts中只需標記一次即可，替換就修改/etc/hosts的配置，否則不修改。

而其它的資訊就會更加清晰，都提前同步好了，準備好了。

那麼可能會有一個問題，就是主庫已經是線上業務，這個怎麼統一啊，而且處理不當會弄巧成拙，這個擔憂是很對的，對於主庫沒有200%的把握不要修改主庫的這些資訊，主庫不能改動，備庫可以啊。所以我們可以從備庫的層面來規範，始終保證這些配置資訊在備庫都是標準，規範的配置。這樣一來在宕機事件面前，我們的操作及混簡單，決定是switchover還是failover即可。其它的資訊都一併修改同步好，提前完成。

至於還有哪些方面需要考慮，暫且想到了圖中的方方面面，可以作為我們規範備庫的一個方式。