Data Guard故障自動切換的想法(r11筆記第40天)

    大概在2年前，我寫過一篇文章，當時也算是隨感。由Gavin King的故事所做的感悟 (r4筆記第24天) ，年輕嘛，都是意氣風發，想好好擼起袖子大幹一場。

    但是可能很多人都會碰到了這樣一個問題，那就是在公司內造輪子的情況非常普遍，而且很多時候一個指令碼，工具，系統只是適用於具體的業務，脫離了系統平臺，部門之外，公司之外都無法適用。很多應用要聯絡具體場景，這個無可厚非，就如同一個表test,含有3個欄位，裡面可以存放100條應用資料，也可以存放200條，這個是根據具體業務具體對待的。很多時候都是由個別幾個人牽頭做成的，而有一個似乎不變的現象就是一旦負責人離開，要麼就是重複造輪子，要麼就是被廢棄。

   從公司的層面來說，其實一定程度上有耦合是件好事，因為很多東西不希望太通用，太容易被複制。這個原因可能會略微複雜一些，但是也沒有錯。

  延伸到資料庫方面，我想對於很多DBA來算，能夠做到故障的自動切換是一件蠻不錯的事情。這個從能力，技術上都是一種非常大的提升和考驗。

  我也有很多不錯的想法，但是如果有時候沒有切磋交流，就會發現其實有些想法不是太迫切，有些細節是需要引起注意的。

   打個比方，一個普通的Data Guard故障切換場景可能看起來簡單，其實涉及很多面，而這些方方面面如果都能夠逐個攻破，那就回歸了問題的本質，有個說法挺好，提高DBA的幸福度。

    有些場景是一主一備的，可能實現的時候就是隻考慮了這樣的情況。

  

    有些場景可能會有代理伺服器，中控伺服器等的角色，這個對原來已有的實現方式就有很大的改動。

    有些場景可能是一主多備的架構，那麼故障切換的時候就需要做很多的事情。如果再加上代理伺服器，中控伺服器，這個場景就更加複雜。

    所以有時候要做加法，有時候要做減法。總之加加減減，可加可減。

    目前設想的Data Guard故障切換的具體實現方式，主要是解決計劃外的故障場景，比如伺服器當機，切換業務到備庫，對調IP地址，重新配置主備關係，甚至實現自動化搭建備庫的場景。這樣一來我們就可以極大的從中受益。

     這件事情，還是要做的，而且我覺得也是目前對我來說感覺相對自由，有一些自己的空間的一個原因。

     要實現這個需求，說實話，有些地方簡單，需要地方真心難。但是凡事都有循序漸進的過程，我簡單梳理了一下，和團隊也做了簡單的交流，大體是這樣的一個演進方式。

1.    梳理目前的資產資訊，系統資產列表目前只有物理資訊，但是對於主備關係的標識，機房位置，備庫的切換優先順序目前需要進一步補充。
2.    系統後設資料備份
    涉及主庫的防火牆資訊，/etc/hosts,核心引數配置等
    備庫的防火牆資訊，主機配置，核心引數配置等
3.    資料庫後設資料備份，涉及資料庫的listener.ora,tnsnams.ora,引數檔案
4.    故障切換指令碼化  故障切換有幾個方面的檢查工作。
    1）.    檢測主庫是否可訪問（系統，網路，資料庫）
    2）.    檢測備庫的資料同步情況
    3）.    判斷故障切換的優先順序和服務可用性檢測
    4）.    資料庫角色的切換（備切主）
 5.    資料庫IP對調  
 6.    自愈稽核
    1）.    檢查資料庫連線數和應用連線情況
    2）.    多備庫的主備關係重新配置
    3）.    後設資料備份
    4）.    操作日誌歸檔和通知
7.    自動化搭建備庫，如果是多備庫環境，準備好備庫環境，自動化配置

大體上上面的一個步驟，尤其是第7步，是本次故障自愈的一個亮點，那就是自動化搭建Data Guard,思路就是使用一臺備用伺服器，根據需求搭建Data Guard,比如我有10套環境，我們新增一個伺服器作為備機，在故障發生的時候，能夠根據故障情況搭建Data Guard.

   我現在也在規劃中，最近會打算在github上來一起做點東西出來。