1 數(shù)據(jù)守護(hù)概念

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

DM 數(shù)據(jù)守護(hù)(Data Watch)的實(shí)現(xiàn)原理非常簡單：將主庫(生產(chǎn)庫)產(chǎn)生的 Redo日志傳輸?shù)絺鋷?#xff0c;備庫接收并重新應(yīng)用 Redo 日志，從而實(shí)現(xiàn)備庫與主庫的數(shù)據(jù)同步。

DM 數(shù)據(jù)守護(hù)系統(tǒng)結(jié)構(gòu)如下圖。主要由主庫、備庫、Redo 日志、Redo 日志傳輸、Redo 日志重演、守護(hù)進(jìn)程(dmwatcher)、監(jiān)視器(dmmonitor)組成。

相關(guān)組件說明：

主庫：

Primary 模式，提供完整數(shù)據(jù)庫服務(wù)的實(shí)例，一般來說主庫是用來直接支撐應(yīng)用系統(tǒng)的生產(chǎn)庫。

備庫：

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

備庫支持臨時(shí)表修改主要基于兩個(gè)因素：1.臨時(shí)表數(shù)據(jù)的修改不會(huì)產(chǎn)生 Redo 日志，主庫對(duì)臨時(shí)表的修改無法同步到備庫；2.可以提供更大靈活性，適應(yīng)更多應(yīng)用場(chǎng)景。

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

Redo 日志

Redo 日志記錄物理數(shù)據(jù)頁內(nèi)容變動(dòng)情況，是數(shù)據(jù)庫十分重要的一個(gè)功能，在數(shù)據(jù)庫系統(tǒng)故障(比如服務(wù)器掉電)重啟時(shí)，利用 Redo 日志可以把數(shù)據(jù)恢復(fù)到故障前的狀態(tài)。

Redo 日志也是數(shù)據(jù)守護(hù)的實(shí)現(xiàn)基礎(chǔ)，數(shù)據(jù)庫中 Insert、Delete、Update 等 DML操作以及 Create TABLE 等 DDL 操作最終都會(huì)體現(xiàn)為對(duì)某一個(gè)或者多個(gè)物理數(shù)據(jù)頁的修改，因此備庫通過重做 Redo 日志可以與主庫數(shù)據(jù)保持一致。

Redo 日志傳輸

主備庫之間的 Redo 日志傳輸，以日志緩沖區(qū) RLOG_BUF 為單位，主庫通過 MAL 系統(tǒng)發(fā)送 Redo 日志到備庫。各種不同數(shù)據(jù)守護(hù)類型的區(qū)別，就在于主庫日志緩沖區(qū) RLOG_BUF的發(fā)送時(shí)機(jī)，以及備庫收到 Redo 日志后的處理策略。

Redo 日志重演

Redo 日志重演的過程，就是備庫收到主庫發(fā)送的 Redo 日志后，在物理數(shù)據(jù)頁上，重新修改數(shù)據(jù)的過程。Redo 日志重演由專門的 Redo 日志重演服務(wù)完成，重演服務(wù)嚴(yán)格按照Redo 日志產(chǎn)生的先后順序，解析 Redo 日志、修改相應(yīng)的物理數(shù)據(jù)頁，并且重演過程中備庫會(huì)生成自身的 Redo 日志寫入聯(lián)機(jī)日志文件。

守護(hù)進(jìn)程

守護(hù)進(jìn)程(dmwatcher)是數(shù)據(jù)守護(hù)系統(tǒng)的核心數(shù)據(jù)同工具，監(jiān)控?cái)?shù)據(jù)庫實(shí)例的運(yùn)行狀態(tài)和主備庫步情況，在出現(xiàn)故障時(shí)啟動(dòng)各種處理預(yù)案。守護(hù)進(jìn)程是各種消息的中轉(zhuǎn)站，接收數(shù)據(jù)庫實(shí)例、其他守護(hù)進(jìn)程、以及監(jiān)視器發(fā)送的各種消息；同時(shí)，守護(hù)進(jìn)程也會(huì)將收到的數(shù)據(jù)庫實(shí)例消息轉(zhuǎn)發(fā)給其他守護(hù)進(jìn)程和監(jiān)視器。守護(hù)進(jìn)程必須和被守護(hù)的數(shù)據(jù)庫實(shí)例部署在同一臺(tái)機(jī)器上。

監(jiān)視器

監(jiān)視器(dmmonitor)用來監(jiān)控守護(hù)系統(tǒng)內(nèi)守護(hù)進(jìn)程、數(shù)據(jù)庫實(shí)例信息，執(zhí)行用戶輸入命令、監(jiān)控實(shí)例故障、實(shí)現(xiàn)自動(dòng)切換等。監(jiān)視器一般配置在數(shù)據(jù)庫實(shí)例和守護(hù)進(jìn)程以外的機(jī)器上。

2 DW理論概念說明

2.1 數(shù)據(jù)庫模式

DM 支持 3 種數(shù)據(jù)庫模式：Normal 模式、Primary 模式和 Standby 模式。

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

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

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

可以通過 SQL 語句切換數(shù)據(jù)庫模式，模式切換必須在 Mount 狀態(tài)下執(zhí)行。

切換模式SQL 語句如下：

將數(shù)據(jù)庫切換為 Primary 模式：

alter database primary;

將數(shù)據(jù)庫切換為 Standby 模式：

alter database standby;

將數(shù)據(jù)庫切換為 Normal 模式：

alter database normal;

2.2 數(shù)據(jù)庫狀態(tài)

DM 的數(shù)據(jù)庫狀態(tài)包括：

2.2.1 Startup 狀態(tài)

系統(tǒng)剛啟動(dòng)時(shí)設(shè)置為 Startup 狀態(tài)。 https://www.cndba.cn/dave/article/3665

2.2.2 After Redo 狀態(tài)

系統(tǒng)啟動(dòng)過程中聯(lián)機(jī)日志重做完成后，回滾活動(dòng)事務(wù)前設(shè)置為 After Redo 狀態(tài)。非 Standby 模式的實(shí)例在執(zhí)行 alter database open 操作前，也會(huì)將系統(tǒng)設(shè)置為 After Redo 狀態(tài)。

2.2.3 Open 狀態(tài)

數(shù)據(jù)庫處于正常提供服務(wù)的狀態(tài)，但不能進(jìn)行歸檔配置等操作。

2.2.4 Mount 狀態(tài)

數(shù)據(jù)庫在 Mount 狀態(tài)下，限制 Redo 日志刷盤，不能修改數(shù)據(jù)，不能訪問表、視圖等 數(shù)據(jù)庫對(duì)象，但可以執(zhí)行修改歸檔配置、控制文件和修改數(shù)據(jù)庫模式等操作，也可以執(zhí)行一 些不修改數(shù)據(jù)庫內(nèi)容的操作，比如查詢動(dòng)態(tài)視圖或者一些只讀的系統(tǒng)過程。

系統(tǒng)從 Open 狀態(tài)切換為 Mount 狀態(tài)時(shí)，需要回滾所有活動(dòng)事務(wù)，但不會(huì)斷開用戶連接，也不會(huì)強(qiáng)制 Buffer 中的臟頁刷盤。

2.2.5 Suspend 狀態(tài)

數(shù)據(jù)庫在 Suspend 狀態(tài)下，限制 Redo 日志刷盤，可以訪問數(shù)據(jù)庫對(duì)象，甚至可以修改數(shù)據(jù)，但是一旦執(zhí)行 COMMIT 等操作觸發(fā) Redo 日志寫盤時(shí)，當(dāng)前操作將被掛起。

相比 Open 到 Mount 的狀態(tài)切換，Open 到 Suspend 的狀態(tài)切換更加簡單、高效，不會(huì)回滾任何活動(dòng)事務(wù)，在狀態(tài)切換完成后，所有事務(wù)可以繼續(xù)執(zhí)行。

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

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

將系統(tǒng)切換為 Suspend 狀態(tài)，限制 Redo 日志寫入聯(lián)機(jī) Redo 日志文件。

修改歸檔狀態(tài)為 Valid。

重新將數(shù)據(jù)庫切換為 Open 狀態(tài)，恢復(fù) Redo 日志寫入功能。

備庫與主庫重新進(jìn)入實(shí)時(shí)同步狀態(tài)。

另外，實(shí)時(shí)歸檔失敗時(shí)(比如網(wǎng)絡(luò)故障導(dǎo)致)，Primary 實(shí)例將試圖切換成 Suspend 狀態(tài)，防止后續(xù)的日志寫入。因?yàn)橐坏懭?#xff0c;主備切換時(shí)，有可能備庫沒有收到最后那次的 RLOG_BUF，導(dǎo)致主庫上多一段日志，很容易造成主備數(shù)據(jù)不一致。當(dāng)實(shí)例成功切換為 SUSPEND 狀態(tài)時(shí)，可直接退出，強(qiáng)制丟棄多余的日志，避免主備數(shù)據(jù)不一致。

2.2.6 Shutdown 狀態(tài)

實(shí)例正常退出時(shí)設(shè)置為 Shutdown 狀態(tài)。

數(shù)據(jù)庫狀態(tài)轉(zhuǎn)換如下圖：

用戶可以通過 SQL 語句進(jìn)行數(shù)據(jù)庫狀態(tài)切換：1. Open 狀態(tài)與 Mount 狀態(tài)可以相互切換；2. Open 狀態(tài)與 Suspend 狀態(tài) 可以相互切換；3. Mount 和 Suspend 狀態(tài)不能直接轉(zhuǎn)換；4. 其他狀態(tài)為系統(tǒng)內(nèi)部狀態(tài)， 用戶不能主動(dòng)干預(yù)。

切換數(shù)據(jù)庫狀態(tài)的 SQL 如下：

1. 將數(shù)據(jù)庫修改為 Open 狀態(tài)。當(dāng)系統(tǒng)處于 Primary/Standby 模式時(shí)，必須強(qiáng)制 加上 force 子句。

alter database open [force];

2. 將數(shù)據(jù)庫修改為 Mount 狀態(tài)。

alter database mount;

3. 將數(shù)據(jù)庫修改為 Suspend 狀態(tài)。

alter database suspend;

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

2.3 LSN 介紹

LSN(Log Sequence Number)是由系統(tǒng)自動(dòng)維護(hù)的 Bigint 類型數(shù)值，具有自動(dòng)遞增、全局唯一特性，每一個(gè)LSN 值代表著 DM 系統(tǒng)內(nèi)部產(chǎn)生的一個(gè)物理事務(wù)。物理事務(wù)(Physical Transaction，簡稱 ptx)是數(shù)據(jù)庫內(nèi)部一系列修改物理數(shù)據(jù)頁操作的集合，與數(shù)據(jù)庫管理系統(tǒng)中事務(wù)(Transaction)概念相對(duì)應(yīng)，具有原子性、有序性、無法撤銷

等特性。

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

1)CUR_LSN 是系統(tǒng)已經(jīng)分配的最大 LSN 值。物理事務(wù)提交時(shí)，系統(tǒng)會(huì)為其分配一個(gè)唯一的 LSN 值，大小等于 CUR_LSN + 1，然后再修改 CUR_LSN=CUR_LSN+1。

2) FILE_LSN 是已經(jīng)寫入聯(lián)機(jī) Redo 日志文件的最大 LSN 值。每次將 Redo 日志緩沖區(qū) RLOG_BUF 寫入聯(lián)機(jī) Redo 日志文件后，都要修改 FILE_LSN 值。

3)FLUSH_LSN 是已經(jīng)發(fā)起日志刷盤請(qǐng)求，但還沒有真正寫入聯(lián)機(jī) Redo 日志文件的最大 LSN 值。

4)CKPT_LSN 是檢查點(diǎn) LSN，所有 LSN <= CKPT_LSN 的物理事務(wù)修改的數(shù)據(jù)頁，都已經(jīng)從 Buffer 緩沖區(qū)寫入磁盤，CKPT_LSN 由檢查點(diǎn)線程負(fù)責(zé)調(diào)整。

1)CLSN 與 CUR_LSN 保持一致，數(shù)據(jù)庫已經(jīng)分配的最大 LSN 值。

2)FLSN 與 FILE_LSN 保持一致，已寫入聯(lián)機(jī)日志文件的 LSN 值。

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

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

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

2.4 Redo 日志

Redo 日志包含了所有物理數(shù)據(jù)頁的修改內(nèi)容，Insert/delete/update 等 DML 操作、Create Table 等 DDL 操作，最終都會(huì)轉(zhuǎn)化為對(duì)物理數(shù)據(jù)頁的修改，這些修改都會(huì)反映到 Redo 日志中。一般說來一條 Insert 等 SQL 語句，在系統(tǒng)內(nèi)部會(huì)轉(zhuǎn)化為多個(gè)相互獨(dú)立的物理事務(wù)來完成，物理事務(wù)提交時(shí)會(huì)將產(chǎn)生的 Redo 日志寫入緩沖區(qū) RLOG_BUF 中。

一個(gè)物理事務(wù)包含一個(gè)或者多個(gè) Redo 記錄(Redo Record)，每條 Redo 記錄(RREC)都對(duì)應(yīng)一個(gè)修改物理數(shù)據(jù)頁的動(dòng)作。根據(jù)記錄內(nèi)容的不同，RREC 可以分為兩類：物理 RREC 和邏輯 RREC。 https://www.cndba.cn/dave/article/3665

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

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

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

備數(shù)據(jù)庫解析到邏輯 RREC 記錄時(shí)，根據(jù)記錄內(nèi)容，生成相應(yīng)的事務(wù)，封鎖對(duì)應(yīng)的數(shù)據(jù)庫對(duì)象，并從字典緩存中淘汰過期的字典對(duì)象。

2.5 Redo 日志緩沖區(qū)

Redo 日志緩沖區(qū) RLOG_BUF 是 DM 數(shù)據(jù)庫內(nèi)部的一個(gè)數(shù)據(jù)結(jié)構(gòu)，用來優(yōu)化、提升 Redo 日志刷盤效率。物理事務(wù)提交時(shí)將 Redo 日志寫入到 RLOG_BUF 中，在數(shù)據(jù)庫事務(wù)提交或 RLOG_BUF 緩沖區(qū)被寫滿時(shí)觸發(fā)日志刷盤動(dòng)作。日志刷盤線程負(fù)責(zé)將 RLOG_BUF 中的 Redo 日志寫入聯(lián)機(jī)日志文件，如果配置了 Redo 日志歸檔，日志刷盤線程還將負(fù)責(zé)觸發(fā)歸檔動(dòng)作。 https://www.cndba.cn/dave/article/3665

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

DM 數(shù)據(jù)守護(hù)系統(tǒng)中，主庫以 RLOG_BUF 緩沖區(qū)為最小單位，發(fā)送 Redo 日志到備庫。

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

2.6 KEEP_BUF 介紹

主庫的RLOG_BUF日志通過實(shí)時(shí)歸檔機(jī)制發(fā)送到備庫后，備庫將最新收到的RLOG_BUF 保存在內(nèi)存中，不馬上啟動(dòng)重演，這個(gè) RLOG_BUF 我們稱之為 KEEP_BUF。引入 KEEP_BUF 的主要目的是，避免下述場(chǎng)景中，主庫故障重啟后不必要的主備切換，減少用戶干預(yù)。

場(chǎng)景說明(實(shí)時(shí)主備或 MPP 主備)：

1.用戶登錄主庫 A 執(zhí)行

create table tx(c1 int);

insert into tx values(1);

commit;

其中 commit 操作將觸發(fā)實(shí)時(shí)歸檔，發(fā)送 RLOG_BUF 到備庫 B。

2.備庫 B 收到 RLOG_BUF，響應(yīng)主庫 A，并啟動(dòng)日志重演。

3.主庫 A 在 RLOG_BUF 寫入聯(lián)機(jī)日志文件之前故障。

4.主庫 A 重新啟動(dòng)后，由于 RLOG_BUF 沒有寫入聯(lián)機(jī)日志文件，之前插入 tx 表的數(shù)據(jù)丟失；但此時(shí)備庫 B 已經(jīng)重演日志成功，tx 表中已經(jīng)插入一行數(shù)據(jù)。

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

引入 KEEP_BUF 后，備庫 B 收到主庫 A 發(fā)送的 RLOG_BUF，并不會(huì)馬上啟動(dòng)日志重演，主庫 A 重啟后，守護(hù)進(jìn)程 A 檢測(cè)到備庫 B 存在 KEEP_BUF，通知備庫 B 丟棄 KEEP_BUF 后， 直接 Open 主庫 A，就可以繼續(xù)提供數(shù)據(jù)庫服務(wù)。并且，這些操作是由守護(hù)進(jìn)程自動(dòng)完成， 不需要用戶干預(yù)。

如果備庫自動(dòng)接管、或者用戶發(fā)起備庫接管命令，那么備庫的 KEEP_BUF 將會(huì)啟動(dòng)重演，不管主庫是否已經(jīng)將 KEEP_BUF 對(duì)應(yīng)的 Redo 日志寫入聯(lián)機(jī)日志文件中，備庫接管時(shí)的 TAKEOVER_LSN 一定是大于等于主庫的 FILE_LSN。當(dāng)故障主庫重啟后，仍然可以作為備庫，自動(dòng)重新加入數(shù)據(jù)守護(hù)系統(tǒng)。

備庫 KEEP_BUF 日志重演的時(shí)機(jī)包括：

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

主庫會(huì)定時(shí)每 5 秒將 FILE_LSN 等信息發(fā)送到備庫，當(dāng)主庫 FILE_LSN == 備庫 SLSN 時(shí)，表明主庫已經(jīng)將 KEEP_BUF 對(duì)應(yīng)的 Redo 日志寫入聯(lián)機(jī)日志文件中，此時(shí)備庫會(huì)啟動(dòng) KEEP_BUF 的日志重演。

備庫收到新的 RLOG_BUF

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

備庫切換為新主庫

在監(jiān)視器執(zhí)行 SWITCHOVER 或 TAKEOVER 命令，或者確認(rèn)監(jiān)視器通知備庫自動(dòng)接管時(shí)， 備庫會(huì)在切換為 PRIMARY 模式之前，啟動(dòng) KEEP_BUF 的日志重演。

即時(shí)歸檔在 RLOG_BUF 寫入主庫聯(lián)機(jī) Redo 日志文件后，再發(fā)送 RLOG_BUF 到備庫，因此即時(shí)備庫沒有 KEEP_BUF。

2.7 聯(lián)機(jī) Redo 日志文件

DM 數(shù)據(jù)庫默認(rèn)包含兩個(gè)聯(lián)機(jī) Redo 日志文件(如 DAMENG01.log、DAMENG02.log， 系統(tǒng)內(nèi)部分別稱為 0 號(hào)文件、1 號(hào)文件)，用來保存 Redo 日志，RLOG_BUF 順序?qū)懭肼?lián)機(jī) Redo 日志文件中，當(dāng)一個(gè)日志文件寫滿后，自動(dòng)切換到另外一個(gè) Redo 日志文件。其中 0 號(hào)文件是 Redo 日志主文件，在日志主文件頭里保存了諸如 CKPT_LSN，CKPT_FILE，CKPT_OFFSET，FILE_LSN 等信息。系統(tǒng)故障重啟時(shí)，從[CKPT_FILE, CKPT_OFFSET] 位置開始讀取 Redo 日志，解析 RREC 記錄，并重新修改對(duì)應(yīng)數(shù)據(jù)頁內(nèi)容，確保將數(shù)據(jù)恢復(fù) 到系統(tǒng)故障前狀態(tài)。

隨著檢查點(diǎn)(Checkpoint)的推進(jìn)，對(duì)應(yīng)產(chǎn)生 Redo 日志的數(shù)據(jù)頁從數(shù)據(jù)緩沖區(qū)(DATA Buffer)寫入磁盤后，聯(lián)機(jī) Redo 日志文件可以覆蓋重用、循環(huán)使用，確保 Redo 日志文 件不會(huì)隨著日志量的增加而增長。

任何數(shù)據(jù)頁從 Buffer 緩沖區(qū)寫入磁盤之前，必須確保修改數(shù)據(jù)頁產(chǎn)生的 Redo 日志已經(jīng)寫入到聯(lián)機(jī) Redo 日志文件中。

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

2.8 歸檔介紹

歸檔是實(shí)現(xiàn)數(shù)據(jù)守護(hù)系統(tǒng)的重要技術(shù)手段，根據(jù)功能與實(shí)現(xiàn)方式的不同，DM 數(shù)據(jù)庫的歸檔可以分為 4 類：本地歸檔、實(shí)時(shí)歸檔、即時(shí)歸檔和異步歸檔。

2.8.1 本地歸檔

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

配置本地歸檔情況下，Redo 日志刷盤線程將 Redo 日志寫入聯(lián)機(jī) Redo 日志文件后，對(duì)應(yīng)的 RLOG_BUF 由專門的歸檔線程負(fù)責(zé)寫入本地歸檔日志文件中。

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

DM 提供了按指定的時(shí)間或指定的 LSN 刪除歸檔日志的系統(tǒng)函數(shù)，但用戶需要謹(jǐn)慎使用。

例如，在守護(hù)系統(tǒng)中，如果備庫故障了，主庫繼續(xù)服務(wù)，主庫的日志在繼續(xù)增長。此時(shí)如果刪除尚未同步到備庫的主庫歸檔日志，那么等待備庫重啟之后，會(huì)由于備庫收到的日志缺失導(dǎo)致主備庫無法正常同步數(shù)據(jù)。相關(guān)的系統(tǒng)函數(shù)分別為 SF_ARCHIVELOG_DELETE _BEFORE_TIME 和 SF_ARCHIVELOG_DELETE_BEFORE_LSN。

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

為了最大限度的保護(hù)數(shù)據(jù)，當(dāng)磁盤空間不足導(dǎo)致歸檔寫入失敗時(shí)，系統(tǒng)會(huì)掛起等待，直到用戶釋放出足夠的磁盤空間。當(dāng)磁盤損壞導(dǎo)致歸檔日志寫入失敗時(shí)，系統(tǒng)會(huì)強(qiáng)制 HALT。

2.8.2 實(shí)時(shí)歸檔

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

實(shí)時(shí)歸檔的執(zhí)行流程是，主庫在 Redo 日志(RLOG_BUF)寫入聯(lián)機(jī) Redo 日志文件前，將 Redo 日志發(fā)送到配置為 Standby 模式的備庫，備庫收到 Redo 日志(RLOG_BUF)后放入 KEEP_BUF，并將原有的 KEEP_BUF 中的內(nèi)容加入日志重演任務(wù)系統(tǒng)后，馬上響應(yīng)主庫，而不是等待 Redo 日志重演結(jié)束再響應(yīng)主庫，主庫收到響應(yīng)消息，確認(rèn)備庫已經(jīng)收到Redo 日志，再將 Redo 日志寫入聯(lián)機(jī) Redo 日志文件中。

2.8.3 即時(shí)歸檔

即時(shí)歸檔(Timely)在主庫將 Redo 日志寫入聯(lián)機(jī) Redo 日志文件后，再通過 MAL 系統(tǒng)將 Redo 日志發(fā)送到備庫。即時(shí)歸檔是讀寫分離集群的實(shí)現(xiàn)基礎(chǔ)，與實(shí)時(shí)歸檔的主要區(qū)別是發(fā)送 Redo 日志的時(shí)機(jī)不同。一個(gè)主庫可以配置 1~8 個(gè)即時(shí)備庫。

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

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

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

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

2.8.4 異步歸檔

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

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

每個(gè) Primary 或 Standby 模式的數(shù)據(jù)庫，最多可以配置 8 個(gè)異步備庫，Normal 模式下配置的異步備庫會(huì)被自動(dòng)失效。

異步備庫可以級(jí)聯(lián)配置，異步備庫本身也可以作為源庫配置異步備庫。理論上守護(hù)系統(tǒng)中可配置的異步備庫的總數(shù)目只受 MAL 系統(tǒng)最大節(jié)點(diǎn)數(shù)(2048)的限制。

2.8.5 歸檔狀態(tài)

本地歸檔、實(shí)時(shí)歸檔和即時(shí)歸檔均包含兩種狀態(tài)：Valid 和 Invalid。異步歸檔只有一種歸檔狀態(tài)：Valid。

? Valid 歸檔有效，正常執(zhí)行各種數(shù)據(jù)庫歸檔操作。

? Invalid 歸檔無效，主數(shù)據(jù)庫不發(fā)送聯(lián)機(jī) redo 日志到備數(shù)據(jù)庫。

在不同的歸檔類型中，歸檔狀態(tài)轉(zhuǎn)換時(shí)機(jī)不同。具體轉(zhuǎn)換時(shí)機(jī)描述如下：

主備庫啟動(dòng)后，主庫->所有備庫的歸檔默認(rèn)是 Valid 狀態(tài)，守護(hù)進(jìn)程 Open 主庫前，將主庫->所有備庫的歸檔狀態(tài)修改為 Invalid 狀態(tài)。

備庫故障恢復(fù)，同步主庫數(shù)據(jù)完成后，守護(hù)進(jìn)程先將主庫修改為 Suspend 狀態(tài)，并將主庫->備庫的歸檔狀態(tài)從 Invalid 修改為 Valid。當(dāng)守護(hù)進(jìn)程再次 Open 主庫后，主備庫數(shù)據(jù)重新恢復(fù)為一致狀態(tài)。

主庫發(fā)送日志到實(shí)時(shí)備庫失敗掛起，守護(hù)進(jìn)程處理 Failover 過程中，將主庫-> 備庫的歸檔狀態(tài)修改為 Invalid。

主庫發(fā)送即時(shí)歸檔失敗后，直接將主庫->備庫的歸檔改為 Invalid 狀態(tài)。

異步歸檔始終保持 Valid 狀態(tài)，一旦歸檔失敗馬上返回，等待下一次觸發(fā)再繼續(xù)發(fā)送。

實(shí)時(shí)歸檔、即時(shí)歸檔只對(duì) Primary 模式的主庫有效，備庫上配置的實(shí)時(shí)歸檔、 即時(shí)歸檔狀態(tài)沒有實(shí)際意義，始終保持 Valid 狀態(tài)。

2.9 MAL 系統(tǒng)

MAL 系統(tǒng)是基于 TCP 協(xié)議實(shí)現(xiàn)的一種內(nèi)部通信機(jī)制，具有可靠、靈活、高效的特性。

DM 通過 MAL 系統(tǒng)實(shí)現(xiàn) Redo 日志傳輸，以及其他一些實(shí)例間的消息通訊。

2.10 OGUID

數(shù)據(jù)守護(hù)唯一標(biāo)識(shí)碼，配置數(shù)據(jù)守護(hù)時(shí)，需要由用戶指定 OGUID 值。其中數(shù)據(jù)庫的OGUID 在 MOUNT 狀態(tài)下由系統(tǒng)函數(shù) SP_SET_OGUID 設(shè)置，守護(hù)進(jìn)程和監(jiān)視器的 OGUID 值在配置文件中設(shè)定。

同一守護(hù)進(jìn)程組中的所有數(shù)據(jù)庫、守護(hù)進(jìn)程和監(jiān)視器，都必須配置相同的 OGUID 值，取值范圍為 0~2147483647。

OGUID 的查詢方式：

select oguid from v$instance;

2.11 守護(hù)進(jìn)程組

配置了相同 OGUID 的兩個(gè)或多個(gè)守護(hù)進(jìn)程，構(gòu)成一個(gè)守護(hù)進(jìn)程組。為方便管理，對(duì)每個(gè)守護(hù)進(jìn)程組進(jìn)行命名，守護(hù)進(jìn)程組中的所有守護(hù)進(jìn)程和監(jiān)視器，必須配置相同的組名。

2.12 組分裂

同一守護(hù)進(jìn)程組中，不同數(shù)據(jù)庫實(shí)例的數(shù)據(jù)出現(xiàn)不一致，并且無法通過重演 Redo 日志， 重新同步數(shù)據(jù)的情況，我們稱為組分裂。

即時(shí)歸檔中，主庫在將 Redo 日志寫入本地聯(lián)機(jī) Redo 日志文件之后，發(fā)送 Redo 日志到備庫之前出現(xiàn)故障，導(dǎo)致主備庫數(shù)據(jù)不一致，為了繼續(xù)提供服務(wù)，執(zhí)行備庫強(qiáng)制接管。 此時(shí)，當(dāng)故障主庫重啟后，就會(huì)引發(fā)組分裂。

故障備庫重新完成數(shù)據(jù)同步之前，主庫硬件故障，并且長時(shí)間無法恢復(fù)；在用戶接受丟失部分?jǐn)?shù)據(jù)情況下，為了盡快恢復(fù)數(shù)據(jù)庫服務(wù)，執(zhí)行備庫強(qiáng)制接管，將備庫切換為主庫。 此時(shí)，如果故障主庫重啟，也會(huì)造成組分裂。

檢測(cè)到組分裂后，守護(hù)進(jìn)程會(huì)修改控制文件為分裂狀態(tài)，被分裂出去的數(shù)據(jù)庫需要通過備份還原等技術(shù)手段重新恢復(fù)，或者按照分裂庫修復(fù)步驟重新將數(shù)據(jù)恢復(fù)到一致狀態(tài)。

2.13 腦裂

腦裂是同一個(gè)守護(hù)進(jìn)程組中，同時(shí)出現(xiàn)兩個(gè)或者多個(gè)活動(dòng)主庫，并且這些主庫都接收用戶請(qǐng)求，提供完整數(shù)據(jù)庫服務(wù)。一旦發(fā)生腦裂，將無法保證數(shù)據(jù)一致性，對(duì)數(shù)據(jù)安全造成嚴(yán)重后果。

DM 數(shù)據(jù)守護(hù)系統(tǒng)為預(yù)防腦裂做了大量工作，例如故障自動(dòng)切換模式數(shù)據(jù)守護(hù)，必須配置確認(rèn)監(jiān)視器。確認(rèn)監(jiān)視器啟動(dòng)故障切換之前，會(huì)進(jìn)行嚴(yán)格的條件檢查，避免腦裂發(fā)生。守護(hù)進(jìn)程一旦檢測(cè)到腦裂發(fā)生，會(huì)馬上強(qiáng)制退出主庫，等待用戶干預(yù)，避免數(shù)據(jù)差異進(jìn)一步擴(kuò)大。

設(shè)置 dm.ini 參數(shù) ALTER_MODE_STATUS=0，限制用戶進(jìn)行直接通過 SQL 修改數(shù)據(jù)庫模式和狀態(tài)。

提供穩(wěn)定、可靠的網(wǎng)絡(luò)環(huán)境。

配置自動(dòng)切換數(shù)據(jù)守護(hù)時(shí)，將確認(rèn)監(jiān)視器部署在獨(dú)立的第三方機(jī)器上，不要與某一個(gè)數(shù)據(jù)庫實(shí)例部署在一起，避免由于網(wǎng)絡(luò)問題觸發(fā)自動(dòng)故障切換，導(dǎo)致腦裂發(fā)生。

通過人工干預(yù)，將備庫切換為主庫之前，一定要確認(rèn)主庫已經(jīng)發(fā)生故障，避免主庫活動(dòng)情況下，備庫強(qiáng)制接管，人為造成腦裂。

3 DW中術(shù)語定義

數(shù)據(jù)守護(hù)系統(tǒng)包含主庫、備庫、守護(hù)進(jìn)程、監(jiān)視器等諸多部件，在主備庫切換、故障處理等場(chǎng)景下，僅以主庫或者備庫這些稱謂，已經(jīng)無法準(zhǔn)確描述對(duì)應(yīng)部件。為了更加清晰的描述數(shù)據(jù)守護(hù)系統(tǒng)，特別定義以下術(shù)語。

術(shù)語

含義

實(shí)時(shí)主備

配置實(shí)時(shí)歸檔的主備系統(tǒng)

MPP 主備

配置實(shí)時(shí)歸檔的 MPP 集群主備系統(tǒng)

讀寫分離集群

配置即時(shí)歸檔的主備系統(tǒng)

實(shí)時(shí)主庫[實(shí)例名]

實(shí)時(shí)主備系統(tǒng)中 Primary 模式的庫

實(shí)時(shí)備庫[實(shí)例名]

實(shí)時(shí)主備系統(tǒng)中 Standby 模式的庫

MPP 主庫[實(shí)例名]

MPP 主備系統(tǒng)中 Primary 模式的庫

MPP 備庫[實(shí)例名]

MPP 主備系統(tǒng)中 Standby 模式的庫

即時(shí)主庫[實(shí)例名]

讀寫分離主備系統(tǒng)中 Primary 模式的庫

即時(shí)備庫[實(shí)例名]

讀寫分離主備系統(tǒng)中 Standby 模式的庫

異步備庫[實(shí)例名]

異步歸檔目標(biāo)庫，Standby 模式

異步源庫[實(shí)例名]

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

故障主庫[實(shí)例名]

發(fā)生故障的 Primary 模式實(shí)例

故障備庫[實(shí)例名]

發(fā)生故障的 Standby 模式實(shí)例

數(shù)據(jù)一致備庫[實(shí)例名]

主庫到當(dāng)前備庫歸檔處于有效狀態(tài)，備庫與主庫數(shù)據(jù)保持一致

可恢復(fù)備庫[實(shí)例名]

主庫到當(dāng)前備庫歸檔處于失效狀態(tài)，備庫與主庫數(shù)據(jù)存在差異，但主庫歸檔日志涵蓋備庫缺失的數(shù)據(jù)

分裂庫[實(shí)例名]

與主庫數(shù)據(jù)不一致，且無法通過重做歸檔日志將數(shù)據(jù)恢復(fù)到一致狀態(tài)的庫

守護(hù)進(jìn)程組[組名]

配置了相同 OGUID 的兩個(gè)或多個(gè)守護(hù)進(jìn)程，構(gòu)成一個(gè)守護(hù)進(jìn)程組

監(jiān)視器

基于監(jiān)視器接口實(shí)現(xiàn)的命令行工具，用于監(jiān)控、管理數(shù)據(jù)守護(hù)系統(tǒng)

確認(rèn)監(jiān)視器

運(yùn)行在確認(rèn)模式下的監(jiān)視器

網(wǎng)絡(luò)故障

指主備庫之間網(wǎng)絡(luò)斷開，消息無法傳遞

網(wǎng)絡(luò)異常

指主備庫之間網(wǎng)絡(luò)未斷開，消息可以傳遞，但出現(xiàn)速度變慢等情形

備庫故障

指?jìng)鋷斐霈F(xiàn)軟、硬件故障，導(dǎo)致數(shù)據(jù)庫實(shí)例關(guān)閉

備庫異常

指?jìng)鋷斓臄?shù)據(jù)庫實(shí)例正常，但響應(yīng)速度出現(xiàn)異常

配置數(shù)據(jù)守護(hù)時(shí)，數(shù)據(jù)庫實(shí)例名不建議配置為 Primary/Standby，守護(hù)進(jìn)程組名不建議配置成和實(shí)例名相同，避免在描述對(duì)象時(shí)產(chǎn)生歧義。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。