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即可。其它的資訊都一併修改同步好，提前完成。
至於還有哪些方面需要考慮，暫且想到了圖中的方方面面，可以作為我們規範備庫的一個方式。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2119786/，如需轉載，請註明出處，否則將追究法律責任。