1 數據守護概念

DM 數據守護(Data Watch)是一種集成化的高可用、高性能數據庫解決方案，是數據庫異地容災的首選方案。數據守護可以配置成實時主備、MPP主備、或讀寫分離集群,基本不受數據規模的影響,只需數秒時間就可以將備庫切換為主庫對外提供數據庫服務。

DM 數據守護(Data Watch)的實現原理非常簡單：將主庫(生產庫)產生的 Redo日志傳輸到備庫，備庫接收并重新應用 Redo 日志，從而實現備庫與主庫的數據同步。

DM 數據守護系統結構如下圖。主要由主庫、備庫、Redo 日志、Redo 日志傳輸、Redo 日志重演、守護進程(dmwatcher)、監視器(dmmonitor)組成。

相關組件說明：

主庫：

Primary 模式，提供完整數據庫服務的實例，一般來說主庫是用來直接支撐應用系統的生產庫。

備庫：

Standby 模式，提供只讀數據庫服務的實例。備庫除了用于容災，還可以提供備份、查詢等只讀功能，并且備庫還支持臨時表的 Insert/Delete/Update 操作。

備庫支持臨時表修改主要基于兩個因素：1.臨時表數據的修改不會產生 Redo 日志，主庫對臨時表的修改無法同步到備庫；2.可以提供更大靈活性，適應更多應用場景。

根據數據同步情況，備庫又可以分為可切換備庫和不可切換備庫。可切換備庫是指，主備庫之間數據完全同步，主庫發生故障、備庫切換為主庫后，不會造成任何數據丟失的備庫。

Redo 日志

Redo 日志記錄物理數據頁內容變動情況，是數據庫十分重要的一個功能，在數據庫系統故障(比如服務器掉電)重啟時，利用 Redo 日志可以把數據恢復到故障前的狀態。

Redo 日志也是數據守護的實現基礎，數據庫中 Insert、Delete、Update 等 DML操作以及 Create TABLE 等 DDL 操作最終都會體現為對某一個或者多個物理數據頁的修改，因此備庫通過重做 Redo 日志可以與主庫數據保持一致。

Redo 日志傳輸

主備庫之間的 Redo 日志傳輸，以日志緩沖區 RLOG_BUF 為單位，主庫通過 MAL 系統發送 Redo 日志到備庫。各種不同數據守護類型的區別，就在于主庫日志緩沖區 RLOG_BUF的發送時機，以及備庫收到 Redo 日志后的處理策略。

Redo 日志重演

Redo 日志重演的過程，就是備庫收到主庫發送的 Redo 日志后，在物理數據頁上，重新修改數據的過程。Redo 日志重演由專門的 Redo 日志重演服務完成，重演服務嚴格按照Redo 日志產生的先后順序，解析 Redo 日志、修改相應的物理數據頁，并且重演過程中備庫會生成自身的 Redo 日志寫入聯機日志文件。

守護進程

守護進程(dmwatcher)是數據守護系統的核心數據同工具，監控數據庫實例的運行狀態和主備庫步情況，在出現故障時啟動各種處理預案。守護進程是各種消息的中轉站，接收數據庫實例、其他守護進程、以及監視器發送的各種消息；同時，守護進程也會將收到的數據庫實例消息轉發給其他守護進程和監視器。守護進程必須和被守護的數據庫實例部署在同一臺機器上。

監視器

監視器(dmmonitor)用來監控守護系統內守護進程、數據庫實例信息，執行用戶輸入命令、監控實例故障、實現自動切換等。監視器一般配置在數據庫實例和守護進程以外的機器上。

2 DW理論概念說明

2.1 數據庫模式

DM 支持 3 種數據庫模式：Normal 模式、Primary 模式和 Standby 模式。

Normal 模式: 提供正常的數據庫服務，操作沒有限制。正常生成本地歸檔，但不發送實時歸檔 (Realtime)、即時歸檔(Timely)和異步歸檔(Async)。

Primary 模式: 提供正常的數據庫服務，操作有極少限制。該模式下部分功能受限，包括：不支持修改表空間文件名、不支持修改 arch_ini 參數。正常生成本地歸檔，支持實時歸檔(Realtime)、即時歸檔(Timely)和異步歸檔(Async)。Primary 模式下，對臨時表空間以外的所有的數據庫對象的修改操作都強制生成 Redo 日志。

Standby 模式: 可以執行數據庫備份、查詢等只讀數據庫操作。正常生成本地歸檔，正常發送異步歸檔Redo 日志；但實時歸檔(Realtime)、即時歸檔(Timely)均強制失效。該模式下時間觸發器、事件觸發器等都失效。

可以通過 SQL 語句切換數據庫模式，模式切換必須在 Mount 狀態下執行。

切換模式SQL 語句如下：

將數據庫切換為 Primary 模式：

alter database primary;

將數據庫切換為 Standby 模式：

alter database standby;

將數據庫切換為 Normal 模式：

alter database normal;

2.2 數據庫狀態

DM 的數據庫狀態包括：

2.2.1 Startup 狀態

系統剛啟動時設置為 Startup 狀態。 https://www.cndba.cn/dave/article/3665

2.2.2 After Redo 狀態

系統啟動過程中聯機日志重做完成后，回滾活動事務前設置為 After Redo 狀態。非 Standby 模式的實例在執行 alter database open 操作前，也會將系統設置為 After Redo 狀態。

2.2.3 Open 狀態

數據庫處于正常提供服務的狀態，但不能進行歸檔配置等操作。

2.2.4 Mount 狀態

數據庫在 Mount 狀態下，限制 Redo 日志刷盤，不能修改數據，不能訪問表、視圖等 數據庫對象，但可以執行修改歸檔配置、控制文件和修改數據庫模式等操作，也可以執行一 些不修改數據庫內容的操作，比如查詢動態視圖或者一些只讀的系統過程。

系統從 Open 狀態切換為 Mount 狀態時，需要回滾所有活動事務，但不會斷開用戶連接，也不會強制 Buffer 中的臟頁刷盤。

2.2.5 Suspend 狀態

數據庫在 Suspend 狀態下，限制 Redo 日志刷盤，可以訪問數據庫對象，甚至可以修改數據，但是一旦執行 COMMIT 等操作觸發 Redo 日志寫盤時，當前操作將被掛起。

相比 Open 到 Mount 的狀態切換，Open 到 Suspend 的狀態切換更加簡單、高效，不會回滾任何活動事務，在狀態切換完成后，所有事務可以繼續執行。

一般在修改歸檔狀態之前將系統切換為 Suspend 狀態，比如備庫故障恢復后，在歷史數據(歸檔日志)同步完成后，需要重新啟用實時歸檔功能時：

https://www.cndba.cn/dave/article/3665

將系統切換為 Suspend 狀態，限制 Redo 日志寫入聯機 Redo 日志文件。

修改歸檔狀態為 Valid。

重新將數據庫切換為 Open 狀態，恢復 Redo 日志寫入功能。

備庫與主庫重新進入實時同步狀態。

另外，實時歸檔失敗時(比如網絡故障導致)，Primary 實例將試圖切換成 Suspend 狀態，防止后續的日志寫入。因為一旦寫入，主備切換時，有可能備庫沒有收到最后那次的 RLOG_BUF，導致主庫上多一段日志，很容易造成主備數據不一致。當實例成功切換為 SUSPEND 狀態時，可直接退出，強制丟棄多余的日志，避免主備數據不一致。

2.2.6 Shutdown 狀態

實例正常退出時設置為 Shutdown 狀態。

數據庫狀態轉換如下圖：

用戶可以通過 SQL 語句進行數據庫狀態切換：1. Open 狀態與 Mount 狀態可以相互切換；2. Open 狀態與 Suspend 狀態 可以相互切換；3. Mount 和 Suspend 狀態不能直接轉換；4. 其他狀態為系統內部狀態， 用戶不能主動干預。

切換數據庫狀態的 SQL 如下：

1. 將數據庫修改為 Open 狀態。當系統處于 Primary/Standby 模式時，必須強制 加上 force 子句。

alter database open [force];

2. 將數據庫修改為 Mount 狀態。

alter database mount;

3. 將數據庫修改為 Suspend 狀態。

alter database suspend;

由于 dmwatcher 根據數據庫模式、狀態等信息作為故障處理、故障恢復的依據，建議在配置數據守護過程中，修改 dm.ini 參數ALTER_MODE_STATUS 為0，限制用戶直接通過 SQL 語句修改數據庫狀態、 模式，避免 dmwatcher 做出錯誤的決策。

2.3 LSN 介紹

LSN(Log Sequence Number)是由系統自動維護的 Bigint 類型數值，具有自動遞增、全局唯一特性，每一個LSN 值代表著 DM 系統內部產生的一個物理事務。物理事務(Physical Transaction，簡稱 ptx)是數據庫內部一系列修改物理數據頁操作的集合，與數據庫管理系統中事務(Transaction)概念相對應，具有原子性、有序性、無法撤銷

等特性。

DM 數據庫中與 LSN 相關的信息，可以通過查詢 V$RLOG 表來獲取。DM 主要包括以下幾種類型的 LSN 值：

1)CUR_LSN 是系統已經分配的最大 LSN 值。物理事務提交時，系統會為其分配一個唯一的 LSN 值，大小等于 CUR_LSN + 1，然后再修改 CUR_LSN=CUR_LSN+1。

2) FILE_LSN 是已經寫入聯機 Redo 日志文件的最大 LSN 值。每次將 Redo 日志緩沖區 RLOG_BUF 寫入聯機 Redo 日志文件后，都要修改 FILE_LSN 值。

3)FLUSH_LSN 是已經發起日志刷盤請求，但還沒有真正寫入聯機 Redo 日志文件的最大 LSN 值。

4)CKPT_LSN 是檢查點 LSN，所有 LSN <= CKPT_LSN 的物理事務修改的數據頁，都已經從 Buffer 緩沖區寫入磁盤，CKPT_LSN 由檢查點線程負責調整。

1)CLSN 與 CUR_LSN 保持一致，數據庫已經分配的最大 LSN 值。

2)FLSN 與 FILE_LSN 保持一致，已寫入聯機日志文件的 LSN 值。

3)SLSN 是 Standby LSN 的縮寫，是備庫收到的最后一個 RLOG_BUF 的最大 LSN值，與主庫的 FLUSH_LSN 保持一致。

4)SSLSN 是 Second Standby LSN 的縮寫，實時主備或 MPP 主備中備庫收到的倒數第二個 RLOG_BUF 的最大 LSN 值。在讀寫分離集群中 SLSN == SSLSN。

5)TAKEOVER_LSN 備庫接管時的 SLSN 值，記錄在 dmwatcher.ctl 文件中。同一守護進程組中故障庫恢復時，根據是 TAKEOVER_LSN 和故障庫的 FILE_LSN 值，來 判斷故障庫數據是否可以恢復。

2.4 Redo 日志

Redo 日志包含了所有物理數據頁的修改內容，Insert/delete/update 等 DML 操作、Create Table 等 DDL 操作，最終都會轉化為對物理數據頁的修改，這些修改都會反映到 Redo 日志中。一般說來一條 Insert 等 SQL 語句，在系統內部會轉化為多個相互獨立的物理事務來完成，物理事務提交時會將產生的 Redo 日志寫入緩沖區 RLOG_BUF 中。

一個物理事務包含一個或者多個 Redo 記錄(Redo Record)，每條 Redo 記錄(RREC)都對應一個修改物理數據頁的動作。根據記錄內容的不同，RREC 可以分為兩類：物理 RREC 和邏輯 RREC。 https://www.cndba.cn/dave/article/3665

1)物理 RREC 記錄的是數據頁的變化情況，內容包括：操作類型、修改數據頁地址、頁內偏移、數據頁上的修改內容，如果是變長類型的 Redo 記錄，在 RREC 記錄頭之后還會有一個兩字節的長度信息。

2)邏輯 RREC 記錄的是一些數據庫邏輯操作步驟，主要包括：事務啟動、事務提交、事務回滾、字典封鎖、事務封鎖、B 樹封鎖、字典淘汰等。

邏輯 RREC 記錄是專門為數據守護增加的記錄類型，用來解決備庫重演 Redo 日志與用戶訪問備庫之間的并發沖突，以及主庫執行 DDL 后導致的主備數據庫字典緩存不一致問題。

備數據庫解析到邏輯 RREC 記錄時，根據記錄內容，生成相應的事務，封鎖對應的數據庫對象，并從字典緩存中淘汰過期的字典對象。

2.5 Redo 日志緩沖區

Redo 日志緩沖區 RLOG_BUF 是 DM 數據庫內部的一個數據結構，用來優化、提升 Redo 日志刷盤效率。物理事務提交時將 Redo 日志寫入到 RLOG_BUF 中，在數據庫事務提交或 RLOG_BUF 緩沖區被寫滿時觸發日志刷盤動作。日志刷盤線程負責將 RLOG_BUF 中的 Redo 日志寫入聯機日志文件，如果配置了 Redo 日志歸檔，日志刷盤線程還將負責觸發歸檔動作。 https://www.cndba.cn/dave/article/3665

https://www.cndba.cn/dave/article/3665

DM 數據守護系統中，主庫以 RLOG_BUF 緩沖區為最小單位，發送 Redo 日志到備庫。

RLOG_BUF 由一系列的 RLOG_PAGE 組成，RLOG_PAGE 是物理事務的保存載體，一個 RLOG_PAGE 可以保存一個或多個物理事務信息，一個物理事務、甚至一條 Redo 記錄也可 能需要存放到多個 RLOG_PAGE 中。

2.6 KEEP_BUF 介紹

主庫的RLOG_BUF日志通過實時歸檔機制發送到備庫后，備庫將最新收到的RLOG_BUF 保存在內存中，不馬上啟動重演，這個 RLOG_BUF 我們稱之為 KEEP_BUF。引入 KEEP_BUF 的主要目的是，避免下述場景中，主庫故障重啟后不必要的主備切換，減少用戶干預。

場景說明(實時主備或 MPP 主備)：

1.用戶登錄主庫 A 執行

create table tx(c1 int);

insert into tx values(1);

commit;

其中 commit 操作將觸發實時歸檔，發送 RLOG_BUF 到備庫 B。

2.備庫 B 收到 RLOG_BUF，響應主庫 A，并啟動日志重演。

3.主庫 A 在 RLOG_BUF 寫入聯機日志文件之前故障。

4.主庫 A 重新啟動后，由于 RLOG_BUF 沒有寫入聯機日志文件，之前插入 tx 表的數據丟失；但此時備庫 B 已經重演日志成功，tx 表中已經插入一行數據。

上述場景中，主備庫數據不再保持一致，必須將備庫 B 切換為主庫，并重新從 B 同步 數據到 A。如果配置的是手動切換模式，則必須要有用戶干預，進行備庫接管后，才能恢復數據庫服務。

引入 KEEP_BUF 后，備庫 B 收到主庫 A 發送的 RLOG_BUF，并不會馬上啟動日志重演，主庫 A 重啟后，守護進程 A 檢測到備庫 B 存在 KEEP_BUF，通知備庫 B 丟棄 KEEP_BUF 后， 直接 Open 主庫 A，就可以繼續提供數據庫服務。并且，這些操作是由守護進程自動完成， 不需要用戶干預。

如果備庫自動接管、或者用戶發起備庫接管命令，那么備庫的 KEEP_BUF 將會啟動重演，不管主庫是否已經將 KEEP_BUF 對應的 Redo 日志寫入聯機日志文件中，備庫接管時的 TAKEOVER_LSN 一定是大于等于主庫的 FILE_LSN。當故障主庫重啟后，仍然可以作為備庫，自動重新加入數據守護系統。

備庫 KEEP_BUF 日志重演的時機包括：

收到主庫的重演命令，并且備庫的 SLSN 滿足重演條件

主庫會定時每 5 秒將 FILE_LSN 等信息發送到備庫，當主庫 FILE_LSN == 備庫 SLSN 時，表明主庫已經將 KEEP_BUF 對應的 Redo 日志寫入聯機日志文件中，此時備庫會啟動 KEEP_BUF 的日志重演。

備庫收到新的 RLOG_BUF

備庫收到新的 RLOG_BUF 時，會將當前保存的 KEEP_BUF 日志重演，并將新收到的 RLOG_BUF 再次放入 KEEP_BUF 中。https://www.cndba.cn/dave/article/3665

備庫切換為新主庫

在監視器執行 SWITCHOVER 或 TAKEOVER 命令，或者確認監視器通知備庫自動接管時， 備庫會在切換為 PRIMARY 模式之前，啟動 KEEP_BUF 的日志重演。

即時歸檔在 RLOG_BUF 寫入主庫聯機 Redo 日志文件后，再發送 RLOG_BUF 到備庫，因此即時備庫沒有 KEEP_BUF。

2.7 聯機 Redo 日志文件

DM 數據庫默認包含兩個聯機 Redo 日志文件(如 DAMENG01.log、DAMENG02.log， 系統內部分別稱為 0 號文件、1 號文件)，用來保存 Redo 日志，RLOG_BUF 順序寫入聯機 Redo 日志文件中，當一個日志文件寫滿后，自動切換到另外一個 Redo 日志文件。其中 0 號文件是 Redo 日志主文件，在日志主文件頭里保存了諸如 CKPT_LSN，CKPT_FILE，CKPT_OFFSET，FILE_LSN 等信息。系統故障重啟時，從[CKPT_FILE, CKPT_OFFSET] 位置開始讀取 Redo 日志，解析 RREC 記錄，并重新修改對應數據頁內容，確保將數據恢復 到系統故障前狀態。

隨著檢查點(Checkpoint)的推進，對應產生 Redo 日志的數據頁從數據緩沖區(DATA Buffer)寫入磁盤后，聯機 Redo 日志文件可以覆蓋重用、循環使用，確保 Redo 日志文 件不會隨著日志量的增加而增長。

任何數據頁從 Buffer 緩沖區寫入磁盤之前，必須確保修改數據頁產生的 Redo 日志已經寫入到聯機 Redo 日志文件中。

在聯機日志文件中，可以覆蓋寫入 Redo 日志的文件長度為可用日志空間；不能被覆蓋， 系統故障重啟需要重做部分，為有效 Redo 日志，有效 Redo 日志的 LSN 取值范圍是 (CKPT_LSN,FILE_LSN]；已經被發起日志刷盤請求，但還沒有真正寫入聯機 Redo 日志 文件的區間為(FILE_LSN,FLUSH_LSN]，稱為待寫入日志空間。

2.8 歸檔介紹

歸檔是實現數據守護系統的重要技術手段，根據功能與實現方式的不同，DM 數據庫的歸檔可以分為 4 類：本地歸檔、實時歸檔、即時歸檔和異步歸檔。

2.8.1 本地歸檔

Redo 日志本地歸檔(LOCAL)，就是將 Redo 日志寫入到本地歸檔日志文件的過程。

配置本地歸檔情況下，Redo 日志刷盤線程將 Redo 日志寫入聯機 Redo 日志文件后，對應的 RLOG_BUF 由專門的歸檔線程負責寫入本地歸檔日志文件中。

與聯機 Redo 日志文件可以被覆蓋重用不同，本地歸檔日志文件不能被覆蓋，寫入其中 的 Redo 日志信息會一直保留，直到用戶主動刪除；如果配置了歸檔日志空間上限，系統會自動刪除最早生成的歸檔 Redo 日志文件，騰出空間。

DM 提供了按指定的時間或指定的 LSN 刪除歸檔日志的系統函數，但用戶需要謹慎使用。

例如，在守護系統中，如果備庫故障了，主庫繼續服務，主庫的日志在繼續增長。此時如果刪除尚未同步到備庫的主庫歸檔日志，那么等待備庫重啟之后，會由于備庫收到的日志缺失導致主備庫無法正常同步數據。相關的系統函數分別為 SF_ARCHIVELOG_DELETE _BEFORE_TIME 和 SF_ARCHIVELOG_DELETE_BEFORE_LSN。

本地歸檔文件在配置的歸檔目錄下生成并保存，文件命名規則為：日志歸檔名_年月日時分秒毫秒.log，如：ARCHIVE_LOCAL1_20151014153933458.log。如果磁盤空間不足，且沒有配置歸檔日志空間上限(或者配置的上限超過實際空間)，系統將自動掛起，直到用戶主動釋放出足夠的空間后繼續運行。

為了最大限度的保護數據，當磁盤空間不足導致歸檔寫入失敗時，系統會掛起等待，直到用戶釋放出足夠的磁盤空間。當磁盤損壞導致歸檔日志寫入失敗時，系統會強制 HALT。

2.8.2 實時歸檔

與本地歸檔寫入本地磁盤不同，實時歸檔(Realtime)將主庫產生的 Redo 日志和將Huge 表數據修改，通過 MAL 系統傳遞到備庫，實時歸檔是實時主備和 MPP 主備的實現基礎。實時歸檔只有在主庫配置為 Primary 模式時才能生效，一個主庫可以配置 1~8 個實時備庫。

實時歸檔的執行流程是，主庫在 Redo 日志(RLOG_BUF)寫入聯機 Redo 日志文件前，將 Redo 日志發送到配置為 Standby 模式的備庫，備庫收到 Redo 日志(RLOG_BUF)后放入 KEEP_BUF，并將原有的 KEEP_BUF 中的內容加入日志重演任務系統后，馬上響應主庫，而不是等待 Redo 日志重演結束再響應主庫，主庫收到響應消息，確認備庫已經收到Redo 日志，再將 Redo 日志寫入聯機 Redo 日志文件中。

2.8.3 即時歸檔

即時歸檔(Timely)在主庫將 Redo 日志寫入聯機 Redo 日志文件后，再通過 MAL 系統將 Redo 日志發送到備庫。即時歸檔是讀寫分離集群的實現基礎，與實時歸檔的主要區別是發送 Redo 日志的時機不同。一個主庫可以配置 1~8 個即時備庫。

根據備庫重演 Redo 日志和響應主庫時機的不同，即時歸檔分為兩種模式：事務一致模式和高性能模式。即時歸檔模式根據配置文件 dmarch.ini 中的 ARCH_WAIT_APPLY 配置項來確定，配置為 1 就是事務一致模式，配置為 0 就是高性能模式，ARCH_WAIT_APPLY 缺省值是 1。

事務一致模式: 主庫事務 commit 觸發 Redo 日志刷盤和即時歸檔，備庫收到主庫發送的 Redo 日志要在重演完成后再響應主庫，主庫才能響應用戶 commit 成功。事務一致模式下，同一個事務的 SELECT 語句不管是在主庫執行，還是在備庫執行，查詢結果都滿足Read Commit 隔離級要求。

高性能模式: 與實時歸檔一樣，備庫收到主庫發送的 Redo 日志后，馬上響應主庫再啟動日志重演。高性能模式下，備庫與主庫的數據同步存在一定延時(一般情況下延遲時間非常短暫，用戶幾乎感覺不到)，不能嚴格保證事務一致性。

事務一致模式，主備庫之間嚴格維護事務一致性，但主庫要等備庫 Redo 日志重演完成后，再響應用戶的 commit 請求，事務 commit 時間會變長，存在一定的性能損失。高性能模式則通過犧牲事務一致性，來獲得更高的性能和提升系統的吞吐量。用戶應該根據實際情況，選擇合適的即時歸檔模式。

2.8.4 異步歸檔

異步歸檔(Async)，由主、備庫上配置的定時器觸發，根據異步備庫的 CUR_LSN 信息，掃描本地歸檔目錄獲取 Redo 日志，并通過 MAL 系統將 Redo 日志發送到異步備庫。

異步備庫的 Redo 日志重演過程與實時歸檔等其他類型的歸檔完全一致。

每個 Primary 或 Standby 模式的數據庫，最多可以配置 8 個異步備庫，Normal 模式下配置的異步備庫會被自動失效。

異步備庫可以級聯配置，異步備庫本身也可以作為源庫配置異步備庫。理論上守護系統中可配置的異步備庫的總數目只受 MAL 系統最大節點數(2048)的限制。

2.8.5 歸檔狀態

本地歸檔、實時歸檔和即時歸檔均包含兩種狀態：Valid 和 Invalid。異步歸檔只有一種歸檔狀態：Valid。

? Valid 歸檔有效，正常執行各種數據庫歸檔操作。

? Invalid 歸檔無效，主數據庫不發送聯機 redo 日志到備數據庫。

在不同的歸檔類型中，歸檔狀態轉換時機不同。具體轉換時機描述如下：

主備庫啟動后，主庫->所有備庫的歸檔默認是 Valid 狀態，守護進程 Open 主庫前，將主庫->所有備庫的歸檔狀態修改為 Invalid 狀態。

備庫故障恢復，同步主庫數據完成后，守護進程先將主庫修改為 Suspend 狀態，并將主庫->備庫的歸檔狀態從 Invalid 修改為 Valid。當守護進程再次 Open 主庫后，主備庫數據重新恢復為一致狀態。

主庫發送日志到實時備庫失敗掛起，守護進程處理 Failover 過程中，將主庫-> 備庫的歸檔狀態修改為 Invalid。

主庫發送即時歸檔失敗后，直接將主庫->備庫的歸檔改為 Invalid 狀態。

異步歸檔始終保持 Valid 狀態，一旦歸檔失敗馬上返回，等待下一次觸發再繼續發送。

實時歸檔、即時歸檔只對 Primary 模式的主庫有效，備庫上配置的實時歸檔、 即時歸檔狀態沒有實際意義，始終保持 Valid 狀態。

2.9 MAL 系統

MAL 系統是基于 TCP 協議實現的一種內部通信機制，具有可靠、靈活、高效的特性。

DM 通過 MAL 系統實現 Redo 日志傳輸，以及其他一些實例間的消息通訊。

2.10 OGUID

數據守護唯一標識碼，配置數據守護時，需要由用戶指定 OGUID 值。其中數據庫的OGUID 在 MOUNT 狀態下由系統函數 SP_SET_OGUID 設置，守護進程和監視器的 OGUID 值在配置文件中設定。

同一守護進程組中的所有數據庫、守護進程和監視器，都必須配置相同的 OGUID 值，取值范圍為 0~2147483647。

OGUID 的查詢方式：

select oguid from v$instance;

2.11 守護進程組

配置了相同 OGUID 的兩個或多個守護進程，構成一個守護進程組。為方便管理，對每個守護進程組進行命名，守護進程組中的所有守護進程和監視器，必須配置相同的組名。

2.12 組分裂

同一守護進程組中，不同數據庫實例的數據出現不一致，并且無法通過重演 Redo 日志， 重新同步數據的情況，我們稱為組分裂。

即時歸檔中，主庫在將 Redo 日志寫入本地聯機 Redo 日志文件之后，發送 Redo 日志到備庫之前出現故障，導致主備庫數據不一致，為了繼續提供服務，執行備庫強制接管。 此時，當故障主庫重啟后，就會引發組分裂。

故障備庫重新完成數據同步之前，主庫硬件故障，并且長時間無法恢復；在用戶接受丟失部分數據情況下，為了盡快恢復數據庫服務，執行備庫強制接管，將備庫切換為主庫。 此時，如果故障主庫重啟，也會造成組分裂。

檢測到組分裂后，守護進程會修改控制文件為分裂狀態，被分裂出去的數據庫需要通過備份還原等技術手段重新恢復，或者按照分裂庫修復步驟重新將數據恢復到一致狀態。

2.13 腦裂

腦裂是同一個守護進程組中，同時出現兩個或者多個活動主庫，并且這些主庫都接收用戶請求，提供完整數據庫服務。一旦發生腦裂，將無法保證數據一致性，對數據安全造成嚴重后果。

DM 數據守護系統為預防腦裂做了大量工作，例如故障自動切換模式數據守護，必須配置確認監視器。確認監視器啟動故障切換之前，會進行嚴格的條件檢查，避免腦裂發生。守護進程一旦檢測到腦裂發生，會馬上強制退出主庫，等待用戶干預，避免數據差異進一步擴大。

設置 dm.ini 參數 ALTER_MODE_STATUS=0，限制用戶進行直接通過 SQL 修改數據庫模式和狀態。

提供穩定、可靠的網絡環境。

配置自動切換數據守護時，將確認監視器部署在獨立的第三方機器上，不要與某一個數據庫實例部署在一起，避免由于網絡問題觸發自動故障切換，導致腦裂發生。

通過人工干預，將備庫切換為主庫之前，一定要確認主庫已經發生故障，避免主庫活動情況下，備庫強制接管，人為造成腦裂。

3 DW中術語定義

數據守護系統包含主庫、備庫、守護進程、監視器等諸多部件，在主備庫切換、故障處理等場景下，僅以主庫或者備庫這些稱謂，已經無法準確描述對應部件。為了更加清晰的描述數據守護系統，特別定義以下術語。

術語

含義

實時主備

配置實時歸檔的主備系統

MPP 主備

配置實時歸檔的 MPP 集群主備系統

讀寫分離集群

配置即時歸檔的主備系統

實時主庫[實例名]

實時主備系統中 Primary 模式的庫

實時備庫[實例名]

實時主備系統中 Standby 模式的庫

MPP 主庫[實例名]

MPP 主備系統中 Primary 模式的庫

MPP 備庫[實例名]

MPP 主備系統中 Standby 模式的庫

即時主庫[實例名]

讀寫分離主備系統中 Primary 模式的庫

即時備庫[實例名]

讀寫分離主備系統中 Standby 模式的庫

異步備庫[實例名]

異步歸檔目標庫，Standby 模式

異步源庫[實例名]

異步歸檔源庫，Primary/Standby 模式都可

故障主庫[實例名]

發生故障的 Primary 模式實例

故障備庫[實例名]

發生故障的 Standby 模式實例

數據一致備庫[實例名]

主庫到當前備庫歸檔處于有效狀態，備庫與主庫數據保持一致

可恢復備庫[實例名]

主庫到當前備庫歸檔處于失效狀態，備庫與主庫數據存在差異，但主庫歸檔日志涵蓋備庫缺失的數據

分裂庫[實例名]

與主庫數據不一致，且無法通過重做歸檔日志將數據恢復到一致狀態的庫

守護進程組[組名]

配置了相同 OGUID 的兩個或多個守護進程，構成一個守護進程組

監視器

基于監視器接口實現的命令行工具，用于監控、管理數據守護系統

確認監視器

運行在確認模式下的監視器

網絡故障

指主備庫之間網絡斷開，消息無法傳遞

網絡異常

指主備庫之間網絡未斷開，消息可以傳遞，但出現速度變慢等情形

備庫故障

指備庫出現軟、硬件故障，導致數據庫實例關閉

備庫異常

指備庫的數據庫實例正常，但響應速度出現異常

配置數據守護時，數據庫實例名不建議配置為 Primary/Standby，守護進程組名不建議配置成和實例名相同，避免在描述對象時產生歧義。

總結

以上是生活随笔為你收集整理的linux中mysql回滚重演_DM7 达梦 数据库 数据守护(Data Watch) (1) -- 基本概念的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。