目錄

監視器關閉

監視器啟動，Detach備庫

主備正常，手動switchover

主庫故障，自動switchover

主庫故障，手動Takeover

主庫故障，備庫強制takeover

主庫重啟

備庫故障

公網連接異常

主庫私網異常

備庫私網異常

主備私網同時異常

---

1.Primary/Standby 模式的庫啟動后，自動進入 Mount 狀態,需要啟動守護進程才會open。

2.Standby數據庫mount后，DW才會啟動主庫。

3.如果不停守護進程，數據庫stop以后，DW會把進程自動拉起。INST_AUTO_RESTART = 0可以關閉自動拉起功能。

監視器關閉

首先關閉監視器

關閉主庫DW02，DW01(備庫)仍然是standby，因為沒有啟動監視器，不會進行switchover。

這個時候，再啟動監視器，會把DW01切換為primary嗎？不會。

把主庫DW02啟動，守護組恢復正常。

監視器啟動，Detach備庫

login

detach database?xx

stop dmwatcher database?xx

startup dmwatcher database?xx

attach database?xx

備庫DW02 Detach

退出重新進入監視器，show

備庫的歸檔狀態是INVALID

此時我們關閉DW01（主庫）

可以看到DW02還是standby，detach備庫后，備庫不會進行接管。

把DW02加入到DW里

對應的主庫DW01是停掉的狀態，不允許備庫DW02加入。

啟動DW01

測試一下，是否會數據同步。

發現數據從DW01可以正常同步到DW02，難道DW02自動加入DW組了？

啟動主庫后，備庫自動加入了。

主備正常，手動switchover

假定Choose Switchover選出的可切換備庫是 B，Switchover 切換流程如下：

1. 通知主備庫守護進程，切換為 Switchover 狀態
2. 通知主庫(A) Mount
3. 實時或 MPP 主備環境下，通知備庫(B) APPLY KEEP_RLOG_PKG
4. 通知備庫(B) Mount
5. 通知(A) 切換為 Standby 模式
6. MPP 主備環境下，通知(A)修改 MPP_INI 內存值為 0
7. 通知(B) 切換為 Primary 模式
8. 通知(B) 修改所有歸檔目標的歸檔狀態為無效
9. MPP 主備需要通知各組活動主庫更新 dmmpp.ctl 文件，參考后文說明
10. 通知新的備庫(A) Open
11. 通知新的主庫(B) Open
12. 通知主備庫守護進程切換為 Open 狀態
13. 清理所有守護進程上記錄的監視器命令執行信息

需要登錄，輸入login

登錄成功后，執行switchover

主庫故障，自動switchover

檢測到主庫故障的情況下，會自動進行switchover

殺掉DB進程

檢測到故障，自動切換

主庫故障，手動Takeover

以備庫 B 為例，接管的執行流程包括：

1. 監視器通知守護進程(B)切換為 Takeover 狀態
2. 實時主備或 MPP 主備環境下，通知備庫(B) APPLY KEEP_RLOG_PKG
3. 通知備庫(B) Mount
4. 通知(B) 切換為 Primary 模式
5. 通知(B) 修改到所有歸檔目標的歸檔狀態為 Invalid
6. MPP 主備需要通知活動主庫更新 dmmpp.ctl 文件
7. 通知新的主庫(B) Open
8. 通知守護進程(B)切換為 Open 狀態

主庫故障的情況下，自動切換失敗，可以手動進行切換。

dmwatcher的參數DW_MODE設為MANUAL進行測試：

殺掉DM02進程

可見DW02判斷為故障，Dw的狀態由open變為startup

show看一下狀態

主庫DW02狀態為error，備庫DW01狀態正常，DW01沒有自動切換，我們讓備庫DW01接管：

takeover?DW01

此時，備庫DW01切換成了primary。可以看到此時DW02仍然是primary。

再開啟DW02，看實例一DW日志：

DW02由Primary轉變為standby，DW的狀態也變為了startup

后面，DW和DW02狀態會變為OPEN，然后進行DW02的恢復

主庫故障，備庫強制takeover

與正常 takeover 命令相比，強制接管時系統不會對故障主庫與待接管備庫的數據一致性進行檢查，若接管前主備庫的數據是一致的，則強制接管與正常 takeover 效果相同，接管成功后不會出現數據丟失的情況，故障主庫重啟后也能正常加回集群。若接管前主備庫的數據不一致，則強制接管后會存在數據丟失，故障主庫重啟后無法加回集群，出現集群分裂。

典型的主備庫數據一致的場景：REALTIME 歸檔模式，主庫故障前到備庫的歸檔狀態為 VALID。由于 REALTIME 歸檔流程為主庫先發送日志到備庫，等待收到所有備庫的響應消息后再將該日志寫入本地的聯機日志文件中，所以在主庫故障后其聯機日志文件中已經寫入的日志一定不會備庫收到的日志更多。這種場景下執行強制接管后不會出現數據丟失，故障主庫重啟后也能夠作為備庫重新加入集群，不會發生集群分裂。

強制接管的條件包括：

1. 不存在活動主庫
2. 備庫守護進程處于 Open 或 Startup 狀態
3. 備庫實例運行正常
4. 備庫是 Standby 模式
5. 備庫處于 Open 或 Mount 狀態
6. 備庫的 KLSN 必須是所有備庫中最大的
7. 備庫守護進程控制文件必須有效

以下繼續做測試，殺掉DW01(主庫)：

強制接管DW02

由于是realtime同步，強制接管前數據是一致的，所以并沒有發生守護組分裂。

開啟DW01

過程同前面takeover介紹的一樣，DW01狀態為standby，狀態恢復正常。

主庫重啟

主庫重啟，守護進程狀態會先變成startup，然后再open，Open 成功后繼續作為主庫

備庫故障

手動切換模式

Kill DW01（備庫）

先看監視器，DW01 STANDBY故障

看到DW狀態由OPEN變為startup

從故障節點的DW日志里，也能看到：

Dw接收不到實例的TCP連接信息，狀態置為startup

但是DW02的狀態也會發生變化

守護進程（DW02）先由OPEN到STARTUP，再變為FAILOVER，然后OPEN

實例先SUSPEND,再OPEN

公網連接異常

影響：用戶無法連接數據庫

如果主庫公網無法連接，可以手動switchover，將備庫切換為主庫使用。

主庫私網異常

1. 主備庫之間無法通信
2. 守護進程間無法進行通信

3.REALTIME無法歸檔

4.守護進程無法與主庫進行通信

主庫掛起后，連接主庫的會話會掛住不切換新主庫，設置參數SESS_FREE_IN_SUSPEND配置的時間，會話會自動斷開老主庫。

關掉主庫私網網卡

守護進程間無法進行通信,DW02的守護進程為ERROR

DW01的歸檔為unkonwn，DW02的歸檔為invalid

守護進程無法與主庫進行通信

監視器檢測到Primary實例故障，開始執行takeover自動接管

使用備庫DW01自動接管成功

重新開啟DW02的網卡

守護進程DW02恢復了OPEN，但是實例DW02還是異常

原來是實例當掉了，我們重新開啟DW02實例

實例恢復正常，DW恢復正常。

備庫私網異常

1.主備庫之間無法通信

2.守護進程間無法進行通信

3.REALTIME歸檔失敗

4.守護進程無法與備庫進行通信

停掉DW02（備庫）的網卡

首先守護進程間無法通信，,DW02的守護進程為ERROR

主庫DW01的歸檔為unkonwn，備庫DW02的歸檔為unkonwn

守護進程無法與主庫進行通信，檢測到備庫故障

主庫實例狀態suspend->open，wstatus狀態failover->open

重新開啟DW02的網卡

DW02的守護進程狀態由none變為open

主備私網同時異常

兩節點同時關閉網卡

守護進程與DW01和DW02間無法通信

守護進程間無法通信

實例之間無法通信

監視器與守護進程無法通信

主備庫不會切換，主庫狀態變為suspend

打開兩節點網卡

守護進程：

DW01 ??none-> failover->open

DW02 none->open

實例：

DW01 suspend->open