Data Guard broker系列之五：資料庫角色轉換

轉自：

---

[@more@]資料庫轉換的基本概念

top轉換的型別

資料庫之間的轉換有switchover和failover兩種方式。

switchover

switchover是primary資料庫和它的一個standby資料庫之間角色的切換，通常是有計劃的資料庫轉換，保證不會有資料丟失。

failover

failover發生在primary資料庫失敗之後，它的一個standby接替它成為primary資料庫。failover通常發生primary資料庫不可恢復的情況下，根據資料庫保護模式的不一樣failover可能會有資料丟失。

top轉換目標的選擇

對於switchover操作來說，遵循以下的步驟

1. 首先選擇未應用的redo的standby，這個可以透過SHOW DATABASE db_unique_name RecvQEntries看到。
2. 對於物理和邏輯standby同時存在時，優先選擇redo apply queue最小的物理standby，因為物理standby在轉換之後所有的standby都能正常工作，而轉換到邏輯standby之後同一組裡面的物理standby將要重建。

對failover操作來說，遵循以下的步驟

1. 為降低資料丟失的數量，首先要選擇應用日誌最多的standby。
2. 對於物理和邏輯standby同時存在時，優先選擇物理standby，因為物理standby在轉換之後所有的standby都能正常工作，而轉換到邏輯standby之後同一組裡面的standby將要重建。另外一個如果邏輯standby使用DBMS_LOGSTDBY.SKIP忽略了一部分資料庫話也會造成資料丟失。

topData Guard轉換的三個層次

第一個層次是在沒有配置broker的環境中，在這種環境下，如果要進行資料庫的角色卻換的話通常需要3個步驟：

1. 首先是檢查data guard環境中的資料庫是否滿足轉換的條件。
2. 然後登陸到primary資料庫執行sql轉換角色，再重啟primary資料庫使其變成standby。
3. 再登入到要轉換的standby資料庫上，執行sql轉換角色，再重新啟動standby以變成新的primary。

第二個層次是配置了broker但是沒有配置FSF(fast-start failover)的環境中，在這裡做switchover和failover都只需要一個簡單的命令，剩下的重啟primary和standby的操作就交給broker去做了。

第三個層次是配置了FSF的機器，這時候資料庫的狀態由FSF Observer監控著，一旦primary資料庫出現了問題需要failover操作，FSF會自動進行資料庫的轉換，根本就不需要人來參與了。

topbroker管理下的switchover和failover

topswitchover

broker管理下的switchover的過程

1. 檢查primary和standby是否online，是否有錯誤，如果有錯誤則switchover失敗。
2. 如果primary是RAC，則關掉RAC中所有不參與switchover的instance。
3. 將primary資料庫轉換成standby資料庫，然後將目標standby資料庫轉換成新的primary資料庫。
4. 更新broker控制檔案記錄轉換之後的資料庫角色資訊。
5. 如果新的standby是物理standby的話將會重啟之，然後開始redo log應用。RAC環境中將會重啟那些被關閉的instance。
6. 如果是物理standby環境的話重啟新的primary資料庫然後開始rodo log的傳送到其他的standby中。
   最後broker會確認轉換之後的新primary和standby都工作正常，redo log傳送和應用都正常。對於那些沒有參與switchover的standby將會保持不變。

下面是一個switchover的詳細過程

topfailover

failover有兩種型別：完全failover和立即failover。

完全failover

進行完全failover操作的是很broker會竟可能的恢復資料，同時在failover完成之後會根據情況儘可能的將沒有參與failover的standby變成新的primary的可用的standby。

立即failover

立即failover的操作開始之後broker不再去試圖恢復更多的資料，另一個就是failover完成之後所有沒有參與failover的standby都要重新啟用。

呼叫這兩種failover的命令如下

topbroker執行完全failover的過程

1. 檢查primary是否可用，可用的話給出一條警告資訊。
2. 確認目標standby可用，不可用的話failover失敗。RAC環境中將關閉standby的其他不參與的instance。
3. 等待目標standby完成還在佇列中的redo資訊之後關閉redo log apply或是sql apply。
4. 將目標standby轉換成新的primary。
   • 將新的primary資料庫開啟為讀寫模式。
   • 檢查其他的standby是否能成為新primary的standby，如果可以的話則該standby的狀態保證不變，否則則需要re-enable。
   • 啟動redo傳送服務將redo傳送給那些不需要re-enable的standby資料庫。
5. 如果是RAC環境則重啟那些之前關閉的instance。

topbroker執行立即failover的過程

1. 確認目標standby可用，不可用的話failover失敗。RAC環境中將關閉standby的其他不參與的instance。
2. 立即停止redo log apply或是sql apply，不管是否還有可恢復的資料，這樣可能會造成資料丟失。
3. 將目標standby轉換成新的primary並開啟到讀寫模式，並啟動redo傳送服務。

一個完全failover的例子

DGMGRL> failover to torclb
Performing failover NOW, please wait…
Failover succeeded, new primary is “torclb”
DGMGRL> show configuration

Configuration

Name: FSF
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
torcla – Physical standby database (disabled)
torclb – Primary database

Current status for “FSF”:
SUCCESS

從上面的狀態我們可以看到此時的新standby是不可用的，處於disabled狀態。

top角色轉換之後的資料庫的啟用

在角色轉換之後我們可能還需要進行額外的操作來啟用被禁用的資料庫，操作已經data guard的型別不同需要啟用資料庫情況也不同。

轉換操作	reinstate或recreate 有問題的primary資料庫	重新啟用沒有參與failover的standby
switchover到物理standby	不需要其他操作	不需要其他操作
switchover到邏輯standby	不需要其他操作	所有物理standby需要recreate
完全failover到物理standby	如果啟用了flashback而且retention足夠的話可以reinstate，否則只能recreate	對於物理standby如果啟用了flashback而且retention足夠的話可以reinstate，否則只能recreate 對於邏輯standby必須recreate
完全failover邏輯standby	如果啟用了flashback而且retention足夠的話可以reinstate，否則只能recreate	所有standby都會被disabled，都需要recreate
立即failover到物理standby或邏輯standby	必須要recreate	所有standby都會被disabled，都需要recreate

topreinstate操作

在broker中進行reinstate資料庫操作只需要執行一個命令就行了，不過前提是配置了flashback以及足夠的retention。

基本步驟是：

1. 重啟資料庫到mount狀態
2. 使用dgmgrl連線到primary資料庫
3. 執行REINSTATE DATABASE命令

下面對上一步failover之後的新standby做一次reinstate操作

可以看到reinstate之後資料庫torcla已經可以正常使用了。