Data Guard實現故障自動切換（二）(r11筆記第39天)

   今天下午我的一個朋友碰到了一個Data Guard的問題，大體是主備網路出現問題，因為環境中配置了自動切換，結果備庫就自動切換為了主庫，這樣就成了“雙主”，我幫忙看了下，對備庫做了閃回，然後直接轉換主庫為備庫角色，一個看似繁瑣的修復工作就完成了。

   在一個一主多備的環境中，的確需要一個強大的工具來支援，所以最後朋友說DG Broker真是個好東西，我回了句 用好了DG Broker,手工管理Data Guard就是小米加步槍啊。

   就如同我昨天文章Data Guard故障自動切換的想法(r11筆記第39天)所說，自動切換也是故障自愈的一個關鍵環節。而其中Oracle自帶的Fast-Start Failover就是一個相對不錯的選擇，如果你的環境網路層面做了統一的管理規劃，只關注資料層面的自動切換，這個自帶的方案其實很強悍，完全可以實現一些較為複雜的自動化切換需求。

    我們先來示範一下，看看它的好，然後說說它的限制和改進之處。

首先就是DG Broker最基礎的兩個命令了。

第一個命令是建立配置，新增主節點

DGMGRL> create configuration dg_dataguru as
>  primary database is dataguru
>  connect identifier is dataguru;
Configuration "dg_dataguru" created with primary database "dataguru"啟用一下配置

DGMGRL> enable configuration;
第二個命令是新增備庫節點

DGMGRL> add database sdataguru as
>  connect identifier is sdataguru
>  maintained as physical;
Database "sdataguru" added
DGMGRL> enable database sdataguru
Enabled.剩下的命令都主要是圍繞這兩個命令來服務的，檢視一下配置成功後的資訊情況。

DGMGRL> show configuration;
Configuration - dg_dataguru
  Protection Mode: MaxPerformance
  Databases:
    dataguru  - Primary database
    sdataguru - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS正如紅色字型標識的，目前的主備是在最大效能模式下，我看很多文章說要配置Fast-Start Failover需要在最大高可用模式下，這是錯誤的，實際上在最大效能模式和最大高可用模式下均可。
   如果要開啟Fast-Start Failover，單單使用enable選項是不夠的。

DGMGRL> enable fast_start failover;
Error: ORA-16651: requirements not met for enabling fast-start failover
Failed檢視oerr ora 16651你會看到一螢幕的提示資訊，把要點都說全了。我點幾個主要的點

1.主備庫需要開啟閃回資料庫

主庫開啟在open狀態下即可，非常方便，至於為什麼主庫需要開啟，主要是作為reinstate來鋪墊的，是故障自愈的一個環節。

SQL> alter database flashback on;
Database altered.

備庫開啟閃回資料庫略有不同，大體步驟如下：

SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database flashback on;
Database altered.
SQL> recover managed standby database disconnect from session;
Media recovery complete.   --最後的步驟或者使用enable database的方式也可以2.主備庫的網路配置
這個其實根據我的瞭解，絕大多數的系統中都是會忽略掉這個配置，因為對於基本的Switchover,Failover來說也夠用了，所以有的同學也會偷懶不配置了。

一個簡單的listener.ora的配置如下：

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = TCP)(HOST = newtest.oracle.com)(PORT = 1521))
      )
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =  
 (SID_DESC =
      (GLOBAL_DBNAME = dataguru)
      (ORACLE_HOME = /U01/app/oracle/product/11.2.0.4)
      (SID_NAME = dataguru)
    )
 (SID_DESC =
      (GLOBAL_DBNAME=DATAGURU_DGMGRL)
      (ORACLE_HOME = /U01/app/oracle/product/11.2.0.4)
      (SID_NAME = dataguru)
    )
  )重點就是紅色的部分，基本格式就是<DB_Unique_Name>_DGMGRL

配置後要確保監聽的服務正確註冊了，重啟對應的監聽保證服務使用無誤。

備庫的配置也是類似的形式，就不重複貼出了。
2.主備延遲，Failover的一些觸發條件

設定資料庫的切換優先順序，可以配置FastStartFailoverTarget

如果我要設定資料庫sdataguru的Failover物件為dataguru,就可以使用如下的命令。

edit database sdataguru set property FastStartFailoverTarget=dataguru;

如果主備的設定為最大高可用保護模式，則需要設定LogXptMode為sync

如果主備的設定為最大效能保護模式，則需要設定LogXptMode為async

啟用FastStart Failover

DGMGRL> enable fast_start failover;
Enabled.
DGMGRL> start observer ;
Observer started檢視狀態的資訊如下,有幾點需要注意的就是我們可以設定Lag Limit，Observer Reconnect等屬性。

DGMGRL> show fast_start failover;
Fast-Start Failover: ENABLED
  Threshold:          30 seconds
  Target:             dataguru
  Observer:           snewtest2.cyou.com
  Lag Limit:          30 seconds
  Shutdown Primary:   TRUE
  Auto-reinstate:     TRUE
  Observer Reconnect: (none)
  Observer Override:  FALSE
Configurable Failover Conditions
  Health Conditions:
    Corrupted Controlfile          YES
    Corrupted Dictionary           YES
    Inaccessible Logfile            NO
    Stuck Archiver                  NO
    Datafile Offline               YES

  Oracle Error Conditions:
    (none)

在此你可能對故障自愈沒有深刻的體驗，我們就來實驗一下。

主庫直接shutdown abort
DG Broker中的observer的日誌如下：

22:36:07.60  Tuesday, January 10, 2017
Initiating Fast-Start Failover to database "sdataguru"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "sdataguru"
22:36:16.52  Tuesday, January 10, 2017可以清晰的看到，是做了Failover的操作。
對於故障自愈，如果主庫已經修復，可以正常啟動，那麼就會自動觸發由主庫調整為備庫，也就是我們開頭所說的reinstate.

我們只需要把資料庫啟動到mount階段，然後靜觀日誌變化。
22:37:34.67  Tuesday, January 10, 2017
Initiating reinstatement for database "dataguru"...
Reinstating database "dataguru", please wait...
Operation requires shutdown of instance "dataguru" on database "dataguru"
Shutting down instance "dataguru"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "dataguru" on database "dataguru"
Starting instance "dataguru"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "dataguru" ...
Reinstatement of database "dataguru" succeeded
22:38:24.08  Tuesday, January 10, 2017

就這樣一個看似複雜的reinstate工作就自動修復了，無需手工干預和處理。

當然你要說這個過程中還有什麼特別的研製，資料庫層面來說，這種方式是非常好的，可以在這個基礎上去借鑑更多的有點和細節之處。

    而這個方案的一個瓶頸就在於這個完全自動化的部分，如果出現了誤判的情況，可能這時候問題就會很尷尬，會導致一些資料庫切換的難解問題。

   從實踐的角度和通用的角度來說，我們需要定義更多的規則和邏輯。這種方式可以作為一種非常好的參考理念。