：從零構建高可用數(shù)據庫架構)
1. 項目概述為什么需要達夢8主備集群在數(shù)據庫運維的日常里高可用性High Availability是一個繞不開的核心命題。想象一下承載著核心業(yè)務數(shù)據的數(shù)據庫服務器突然宕機業(yè)務中斷、數(shù)據丟失的風險隨之而來這種場景對任何一家企業(yè)來說都是不可承受之重。達夢數(shù)據庫DM8作為一款成熟的企業(yè)級國產數(shù)據庫其內置的高可用解決方案——數(shù)據守護Data Watch集群就是我們應對這類風險的“定心丸”。它本質上是一個主備Primary-Standby架構通過日志同步機制確保主庫的數(shù)據變更能夠近乎實時地傳遞到備庫。一旦主庫發(fā)生故障備庫可以迅速接管服務實現(xiàn)業(yè)務的快速恢復將停機時間RTO和數(shù)據丟失量RPO降到最低。這不僅僅是技術上的“有備無患”更是業(yè)務連續(xù)性的基石。無論是金融交易、政務服務還是在線業(yè)務對數(shù)據庫7x24小時穩(wěn)定運行的要求越來越高。搭建達夢8主備集群就是將單點故障的風險分散構建一個具備自動故障切換能力的數(shù)據庫服務環(huán)境。對于DBA和系統(tǒng)架構師而言掌握這套體系的搭建與運維是從業(yè)者核心技能庫中不可或缺的一環(huán)。接下來我將結合多次實戰(zhàn)部署的經驗從頭到尾拆解達夢8主備集群的搭建過程并分享那些官方文檔可能不會細說的“踩坑”心得。2. 集群架構設計與核心組件解析2.1 數(shù)據守護Data Watch架構全景達夢8的數(shù)據守護集群并非一個孤立的組件而是由多個協(xié)同工作的進程和配置文件構成的有機整體。理解其架構是成功部署和后期排錯的關鍵。一個典型的主備集群這里以最基本的1主1備為例通常包含以下核心角色主庫Primary承擔所有讀寫業(yè)務的生產數(shù)據庫實例。所有數(shù)據修改DML和結構變更DDL都發(fā)生在這里。備庫Standby實時接收并重做Redo主庫產生的歸檔日志Archive Log從而保持與主庫數(shù)據的一致性。正常情況下備庫處于只讀Read-Only狀態(tài)可用于分擔報表查詢等只讀業(yè)務這也是提升資源利用率的一個常見做法。守護進程dmwatcher這是集群的“大腦”和“神經”。每個數(shù)據庫實例主庫和備庫都會配套運行一個守護進程。它的核心職責是監(jiān)控本地數(shù)據庫實例的運行狀態(tài)是否運行、是否掛起并通過網絡與其他節(jié)點的守護進程進行心跳通信共同決策集群狀態(tài)。當檢測到主庫故障時各守護進程會協(xié)商發(fā)起自動故障切換Failover。監(jiān)視器dmmonitor一個可選的、但強烈建議部署的圖形化或命令行監(jiān)控工具。它以一個獨立進程的形式運行可以連接集群中的所有守護進程提供一個全局視角來查看集群狀態(tài)、執(zhí)行手工切換等管理操作。在生產環(huán)境中部署監(jiān)視器能極大提升運維便利性。這些組件之間的網絡通信關系至關重要。主備庫之間需要開通端口進行歸檔日志的傳輸默認ARCHIVE_PORT如5236所有守護進程之間需要開通端口進行心跳和信息交互默認DW_PORT如5237監(jiān)視器則需要能連接到所有守護進程的端口默認MONITOR_PORT如5238。在規(guī)劃階段就必須在防火墻或安全組規(guī)則中放行這些端口的雙向通信。2.2 同步模式的選擇實時與即時達夢數(shù)據守護提供了兩種主要的日志同步模式選擇哪種模式直接影響了數(shù)據一致性和性能的權衡實時同步Realtime Sync這是最嚴格的數(shù)據保護模式。主庫事務提交前必須等待對應的事務日志Redo Log被備庫的日志寫入線程RLOG_SEND成功寫入備庫的本地日志文件。只有收到備庫的確認消息后主庫的事務才會提交成功。這種模式能確保備庫與主庫的數(shù)據強一致實現(xiàn)RPO0零數(shù)據丟失但會略微增加主庫事務的響應時間因為增加了網絡往返延遲。即時同步Immediate Sync一種折衷方案。主庫事務提交時只需確保日志被發(fā)送到備庫的日志接收緩沖區(qū)即可返回成功無需等待備庫寫入磁盤。這比實時同步更快但存在極小的數(shù)據丟失窗口期如果主庫在發(fā)送日志后、備庫寫入磁盤前發(fā)生故障且網絡也同時中斷則這部分已提交的事務數(shù)據可能會丟失。實操心得對于絕大多數(shù)對數(shù)據一致性要求極高的金融、交易類核心業(yè)務推薦使用實時同步模式。雖然犧牲一點性能但換來的是數(shù)據的絕對安全?，F(xiàn)在的網絡質量普遍較好帶來的延遲增加通常在可接受范圍內。只有在網絡延遲確實成為瓶頸且業(yè)務可以容忍秒級數(shù)據丟失的場景下才考慮即時同步。3. 搭建前的關鍵準備工作3.1 環(huán)境規(guī)劃與資源評估“工欲善其事必先利其器”。搭建前的規(guī)劃直接決定了后續(xù)部署的順利程度和集群的穩(wěn)定性。服務器規(guī)劃至少需要兩臺物理服務器或虛擬機。強烈建議主備服務器硬件配置CPU、內存、磁盤IO性能盡可能保持一致避免因性能差異導致備庫重做日志速度跟不上產生嚴重的日志堆積Archive Lag。操作系統(tǒng)需使用達夢官方認證的版本如CentOS 7/8、RedHat 7/8、麒麟V10等。網絡規(guī)劃IP與主機名為每臺服務器配置靜態(tài)IP并在/etc/hosts文件中做好主機名解析確保主備機之間可以通過主機名互相ping通。使用主機名而非IP進行配置可以提高配置的可讀性和可維護性。端口開放如前所述需要規(guī)劃并開放5236歸檔、5237守護、5238監(jiān)視器端口。如果部署在云上還需配置安全組規(guī)則。網絡質量主備機之間的網絡延遲和帶寬至關重要。建議部署在同一機房或可用區(qū)內網絡延遲應穩(wěn)定在1ms以下帶寬至少千兆。高延遲或抖動的網絡是數(shù)據守護集群穩(wěn)定運行的大敵。存儲規(guī)劃達夢數(shù)據庫的數(shù)據文件、日志文件、備份文件等需要獨立的存儲空間。建議使用高性能的SSD或NVMe磁盤。特別注意歸檔日志路徑ARCHIVE_DEST要有充足的空間并設置合理的歸檔日志刪除策略防止磁盤被撐滿。3.2 軟件安裝與基礎配置這部分工作需要在主備兩臺服務器上分別進行。達夢數(shù)據庫安裝從達夢官網下載對應操作系統(tǒng)版本的安裝包如dm8_setup_xxx.iso。使用root用戶掛載并執(zhí)行安裝程序。安裝過程中建議選擇“典型安裝”并指定一個獨立的用戶如dmdba和用戶組如dinstall來運行數(shù)據庫這是出于安全和管理的最佳實踐。安裝路徑如/opt/dmdbms建議保持一致。初始化數(shù)據庫實例使用dminit工具初始化兩個數(shù)據庫實例。這里有一個關鍵步驟備庫的數(shù)據庫參數(shù)必須與主庫兼容。最穩(wěn)妥的做法是先初始化主庫然后使用主庫的配置文件dm.ini作為參考再去初始化備庫確保關鍵參數(shù)如PAGE_SIZE、CASE_SENSITIVE等完全一致。# 在主庫服務器初始化實例假設實例名為DMSERVER /opt/dmdbms/bin/dminit PATH/dm8/data DB_NAMEDMSERVER INSTANCE_NAMEDMSERVER PAGE_SIZE32 CASE_SENSITIVE1 # 將生成的主庫dm.ini拷貝到備庫服務器用于參考初始化備庫配置環(huán)境變量與用戶權限為dmdba用戶配置.bash_profile添加DM_HOME和PATH。確保dmdba用戶對數(shù)據庫安裝目錄、數(shù)據目錄有完全的讀寫權限。4. 主備集群配置與搭建實操全流程4.1 主庫配置詳解主庫的配置是起點所有配置都集中在數(shù)據庫實例目錄下的dm.ini和dmarch.ini文件中。配置dm.ini打開主庫數(shù)據目錄下的dm.ini文件修改或確認以下關鍵參數(shù)INSTANCE_NAME DMSERVER_PRIMARY # 實例名便于識別 PORT_NUM 5236 # 數(shù)據庫服務端口默認5236 MAL_INI 1 # 啟用MAL系統(tǒng)這是守護集群通信的基礎 ARCH_INI 1 # 啟用歸檔配置 RLOG_SEND_APPLY_MON 64 # 設置發(fā)送歸檔日志時是否等待備庫確認。64為實時同步配置dmarch.ini歸檔配置文件這是最核心的配置之一。在該文件中定義歸檔目的地為備庫。[ARCHIVE_LOCAL] ARCH_TYPE LOCAL # 本地歸檔 ARCH_DEST /dm8/arch_local # 本地歸檔路徑用于備份和時間點恢復 ARCH_FILE_SIZE 1024 # 單個歸檔文件大小單位MB ARCH_SPACE_LIMIT 102400 # 歸檔空間上限單位MB0表示無限制 [ARCHIVE_REALTIME] ARCH_TYPE REALTIME # 實時歸檔類型 ARCH_DEST STANDBY_SERVER # 目標備庫的MAL鏈路名稱需與dmmal.ini對應 ARCH_FILE_SIZE 1024 ARCH_SPACE_LIMIT 0配置dmmal.iniMAL系統(tǒng)配置文件MALMail Address List是守護進程間通信的地址列表。主備庫的此文件內容必須嚴格一致。[MAL_INST1] MAL_INST_NAME DMSERVER_PRIMARY # 實例名與dm.ini中一致 MAL_HOST primary_host # 主庫服務器主機名或IP MAL_PORT 5337 # MAL通信端口通常用5337與守護端口不同 MAL_INST_HOST primary_host MAL_INST_PORT 5236 # 對應數(shù)據庫實例的服務端口 [MAL_INST2] MAL_INST_NAME DMSERVER_STANDBY MAL_HOST standby_host MAL_PORT 5337 MAL_INST_HOST standby_host MAL_INST_PORT 5236配置dmwatcher.ini守護進程配置文件[GRP1] DW_TYPE LOCAL # 本地守護類型 DW_MODE AUTO # 自動模式 DW_ERROR_TIME 10 # 認定遠程守護故障的時間(秒) INST_RECOVER_TIME 60 # 主庫重啟后等待備庫重新連接的時間 INST_ERROR_TIME 10 # 認定本地實例故障的時間 INST_OGUID 453331 # 守護組唯一標識主備必須相同建議使用dmkey工具生成 INST_INI /dm8/data/DMSERVER/dm.ini # 本地數(shù)據庫實例配置文件路徑 INST_AUTO_RESTART 1 # 實例故障后自動重啟 INST_STARTUP_CMD /opt/dmdbms/bin/dmserver # 實例啟動命令關鍵提示INST_OGUID守護組OGUID是集群的“身份證”主備庫及所有配置文件中必須完全相同?？梢允褂眠_夢提供的dmkey工具生成一個隨機且唯一的數(shù)字。4.2 備庫配置與數(shù)據同步初始化備庫的dm.ini、dmmal.ini、dmwatcher.ini配置文件內容與主庫高度相似但略有不同必須仔細核對。修改備庫dm.ini將INSTANCE_NAME改為DMSERVER_STANDBY并將ALTER_MODE_STATUS和ENABLE_OFFLINE_TS參數(shù)設置為0備庫默認只讀不允許修改表空間狀態(tài)。確保配置文件一致將主庫配置好的dmmal.ini和dmwatcher.ini拷貝到備庫對應位置。無需修改dmwatcher.ini中的INST_OGUID必須與主庫保持一致。檢查dmwatcher.ini中的INST_INI路徑是否正確指向備庫自己的dm.ini。初始化備庫數(shù)據關鍵步驟備庫不能直接初始化空庫必須通過主庫的備份來還原。這是保證數(shù)據起點一致性的唯一方法。在主庫執(zhí)行脫機備份關閉主庫服務使用dmrman工具進行備份。./dmrman CTLSTMTBACKUP DATABASE /dm8/data/DMSERVER/dm.ini FULL TO BACKUP_FILE BACKUPSET /dm8/backup/full_bak將備份集傳輸?shù)絺鋷焓褂胹cp或rsync將整個備份集目錄拷貝到備庫服務器。在備庫執(zhí)行還原與恢復在備庫服務器上使用dmrman執(zhí)行還原。./dmrman CTLSTMTRESTORE DATABASE /dm8/data/DMSERVER/dm.ini FROM BACKUPSET /dm8/backup/full_bak ./dmrman CTLSTMTRECOVER DATABASE /dm8/data/DMSERVER/dm.ini FROM BACKUPSET /dm8/backup/full_bak ./dmrman CTLSTMTRECOVER DATABASE /dm8/data/DMSERVER/dm.ini UPDATE DB_MAGIC最后一步UPDATE DB_MAGIC至關重要它更新了數(shù)據庫的內部標識使其能夠以備庫身份加入守護組。4.3 啟動集群與驗證配置完成后需要按照嚴格的順序啟動各個組件順序錯誤會導致集群無法正常建立。啟動順序第一步啟動主庫數(shù)據庫實例服務 (dmserver)。第二步啟動主庫的守護進程 (dmwatcher)。第三步啟動備庫數(shù)據庫實例服務 (dmserver)。此時備庫會嘗試連接主庫同步備份后的增量日志。第四步啟動備庫的守護進程 (dmwatcher)。兩個守護進程建立連接集群開始正常監(jiān)控。第五步可選啟動監(jiān)視器 (dmmonitor)用于圖形化監(jiān)控。驗證集群狀態(tài)連接到主庫執(zhí)行SQLSELECT * FROM V$DMARCH_INI;查看歸檔狀態(tài)確認ARCH_DEST指向的備庫狀態(tài)為VALID。連接到備庫執(zhí)行SQLSELECT * FROM V$DATABASE;查看DATABASE_MODE字段應為STANDBY備庫模式。使用監(jiān)視器或通過命令行查看守護進程狀態(tài)./dmmonitor /dm8/data/dmmonitor.ini在監(jiān)視器界面輸入show命令應看到主備庫狀態(tài)均為OPEN守護進程狀態(tài)為STARTUP集群狀態(tài)為NORMAL。模擬故障切換測試這是上線前必須進行的“消防演練”。在業(yè)務低峰期手動停止主庫的dmserver進程。觀察守護進程的日志 (dmwatcher.log) 和監(jiān)視器應該在數(shù)十秒內自動檢測到故障并完成切換。此時備庫應提升為新的主庫狀態(tài)變?yōu)镻RIMARY。驗證業(yè)務連接能否自動或手動切換到新的主庫IP或VIP上。5. 運維要點與深度避坑指南5.1 日常監(jiān)控與健康檢查集群搭建成功只是第一步持續(xù)的監(jiān)控是穩(wěn)定運行的保障。日志監(jiān)控定期檢查dmwatcher.log守護進程日志和數(shù)據庫的dmserver.log。關注是否有ERROR或WARNING級別的報錯特別是網絡超時、歸檔失敗等信息。歸檔延遲監(jiān)控在備庫執(zhí)行SELECT ARCH_LAG FROM V$ARCH_STATUS;可以查看歸檔延遲單位秒。一個健康的集群延遲應該穩(wěn)定在秒級甚至毫秒級。如果延遲持續(xù)增長需要排查網絡帶寬、備庫IO性能或主庫寫入壓力。系統(tǒng)視圖查詢熟練使用以下動態(tài)性能視圖是DBA的基本功V$DMARCH_INI查看歸檔配置和狀態(tài)。V$DATABASE查看數(shù)據庫模式PRIMARY/STANDBY。V$DMWATCHER查看本地守護進程信息。V$DMWATCHER_STAT查看守護進程統(tǒng)計信息。5.2 常見故障場景與應急處理即使規(guī)劃得再完善生產環(huán)境也難免遇到問題。以下是幾種典型故障的處理思路故障現(xiàn)象可能原因排查步驟與解決方案備庫歸檔狀態(tài)為INVALID1. 網絡不通或防火墻阻斷。2. 主庫dmarch.ini配置錯誤如MAL鏈路名不對。3. 備庫數(shù)據庫未啟動或處于非MOUNT狀態(tài)。1. 使用telnet或nc命令測試主備間ARCHIVE_PORT和MAL_PORT連通性。2. 核對主庫dmarch.ini中ARCH_DEST與備庫dmmal.ini中MAL_INST_NAME是否一致。3. 檢查備庫數(shù)據庫實例是否正常啟動。守護進程無法STARTUP狀態(tài)一直為CONFIRM1. 主備庫INST_OGUID不一致。2. 主備庫數(shù)據不同源即備庫不是從當前主庫備份恢復的。3. 備庫的dm.ini中ALTER_MODE_STATUS未設置為0。1. 仔細檢查主備所有dmwatcher.ini中的INST_OGUID必須完全相同。2. 這是一個致命錯誤需用主庫最新備份重新初始化備庫。3. 修改備庫dm.ini重啟實例。自動切換失敗1. 守護進程DW_ERROR_TIME或INST_ERROR_TIME設置過短在網絡抖動時誤判。2. 備庫重做日志速度慢有大量日志堆積不符合接管條件。3. 監(jiān)視器未配置或配置錯誤缺少仲裁節(jié)點。1. 適當調大超時參數(shù)但需權衡故障發(fā)現(xiàn)速度。2. 優(yōu)化備庫服務器性能特別是磁盤IO。檢查備庫是否有長時間運行的查詢阻塞了重做。3. 正確配置并啟動dmmonitor它在多數(shù)情況下是故障切換的仲裁者。主備數(shù)據不一致1. 有人在備庫執(zhí)行了DML或DDL操作備庫應為只讀。2. 歸檔日志在傳輸過程中損壞極罕見。1. 嚴格管理備庫賬號權限禁止非SELECT操作。通過觸發(fā)器或審計功能監(jiān)控。2. 對比主備庫關鍵表的校驗和或記錄數(shù)。如果出現(xiàn)不一致必須從主庫重新搭建備庫。5.3 備份恢復與集群擴容備份策略即使在有備庫的情況下定期的物理備份依然必不可少。備庫保護的是高可用備份保護的是邏輯錯誤或災難恢復。建議在主庫或備庫上定期執(zhí)行脫機或聯(lián)機全量備份并歸檔到異地。備庫重建當備庫服務器硬件故障或數(shù)據不一致無法修復時需要重建備庫。流程與初始搭建類似停止舊備庫 - 從當前主庫獲取最新備份 - 在新服務器上安裝軟件、還原數(shù)據 - 修改配置文件 - 重新加入集群。關鍵在于還原恢復后一定要執(zhí)行UPDATE DB_MAGIC。集群擴容數(shù)據守護支持一主多備。增加第二個備庫的流程與搭建第一個備庫幾乎完全相同準備新服務器 - 從主庫備份還原初始化 - 配置dmmal.ini需添加新備庫的MAL配置并同步到所有節(jié)點 - 配置新備庫的dmwatcher.ini- 按順序啟動。需要確保所有節(jié)點的dmmal.ini文件內容完全同步。6. 性能調優(yōu)與高級配置建議當集群穩(wěn)定運行后我們可以從一些高級角度進行優(yōu)化使其更貼合業(yè)務需求。歸檔路徑優(yōu)化將歸檔日志放在與數(shù)據文件不同的物理磁盤上可以避免IO爭用提升主庫事務處理能力和日志傳輸效率。使用高性能的NVMe SSD作為歸檔盤效果顯著。網絡優(yōu)化如果條件允許為守護集群的通信MAL和歸檔傳輸配置獨立的、高優(yōu)先級的網絡鏈路或VLAN與業(yè)務流量隔離避免網絡擁塞影響心跳和日志同步。備庫資源利用將備庫設置為READ ONLY模式后可以安全地在其上執(zhí)行報表查詢、數(shù)據抽取等只讀業(yè)務充分利用硬件資源。但需要注意復雜的查詢可能會消耗大量CPU和內存進而影響日志重做速度需要監(jiān)控ARCH_LAG。監(jiān)視器高可用生產環(huán)境建議部署2個或更多監(jiān)視器節(jié)點并配置在dmmonitor.ini中。多個監(jiān)視器通過投票機制避免單點故障確保在單個監(jiān)視器宕機時集群的自動切換仲裁機制依然有效。參數(shù)精細調校RLOG_SEND_THRESHOLD控制主庫發(fā)送日志的閾值。適當調大可以減少網絡報文數(shù)量但可能略微增加延遲。RLOG_APPLY_THRESHOLD控制備庫重做日志的閾值。影響備庫重做批處理的大小。這些參數(shù)沒有銀彈需要結合業(yè)務壓力、網絡條件和服務器性能通過監(jiān)控歸檔延遲和系統(tǒng)負載進行動態(tài)調整。搭建達夢8主備集群就像為你的數(shù)據核心構建了一個“雙活心臟”。整個過程涉及系統(tǒng)、網絡、存儲、數(shù)據庫多個層面的知識是對運維人員綜合能力的一次考驗。配置文件中的每一個參數(shù)都值得推敲啟動順序的每一步都關乎成敗。我最深的一點體會是“測試驅動部署”——在正式上線前務必在模擬環(huán)境中進行完整的搭建流程演練、故障切換測試和壓力測試。把可能遇到的問題都在測試階段暴露和解決比如防火墻規(guī)則、主機名解析、權限問題等這樣才能在生產部署時心中有數(shù)手到擒來。當看到監(jiān)視器上集群狀態(tài)穩(wěn)定地顯示為NORMAL主備庫之間歸檔流暢無延遲時那種由技術帶來的確定性和安全感正是我們從事這份工作的價值所在。 達夢8主備集群搭建與運維實戰(zhàn)：從零構建高可用數(shù)據庫架構
1. 項目概述為什么需要達夢8主備集群在數(shù)據庫運維的日常里高可用性High Availability是一個繞不開的核心命題。想象一下承載著核心業(yè)務數(shù)據的數(shù)據庫服務器突然宕機業(yè)務中斷、數(shù)據丟失的風險隨之而來這種場景對任何一家企業(yè)來說都是不可承受之重。達夢數(shù)據庫DM8作為一款成熟的企業(yè)級國產數(shù)據庫其內置的高可用解決方案——數(shù)據守護Data Watch集群就是我們應對這類風險的“定心丸”。它本質上是一個主備Primary-Standby架構通過日志同步機制確保主庫的數(shù)據變更能夠近乎實時地傳遞到備庫。一旦主庫發(fā)生故障備庫可以迅速接管服務實現(xiàn)業(yè)務的快速恢復將停機時間RTO和數(shù)據丟失量RPO降到最低。這不僅僅是技術上的“有備無患”更是業(yè)務連續(xù)性的基石。無論是金融交易、政務服務還是在線業(yè)務對數(shù)據庫7x24小時穩(wěn)定運行的要求越來越高。搭建達夢8主備集群就是將單點故障的風險分散構建一個具備自動故障切換能力的數(shù)據庫服務環(huán)境。對于DBA和系統(tǒng)架構師而言掌握這套體系的搭建與運維是從業(yè)者核心技能庫中不可或缺的一環(huán)。接下來我將結合多次實戰(zhàn)部署的經驗從頭到尾拆解達夢8主備集群的搭建過程并分享那些官方文檔可能不會細說的“踩坑”心得。2. 集群架構設計與核心組件解析2.1 數(shù)據守護Data Watch架構全景達夢8的數(shù)據守護集群并非一個孤立的組件而是由多個協(xié)同工作的進程和配置文件構成的有機整體。理解其架構是成功部署和后期排錯的關鍵。一個典型的主備集群這里以最基本的1主1備為例通常包含以下核心角色主庫Primary承擔所有讀寫業(yè)務的生產數(shù)據庫實例。所有數(shù)據修改DML和結構變更DDL都發(fā)生在這里。備庫Standby實時接收并重做Redo主庫產生的歸檔日志Archive Log從而保持與主庫數(shù)據的一致性。正常情況下備庫處于只讀Read-Only狀態(tài)可用于分擔報表查詢等只讀業(yè)務這也是提升資源利用率的一個常見做法。守護進程dmwatcher這是集群的“大腦”和“神經”。每個數(shù)據庫實例主庫和備庫都會配套運行一個守護進程。它的核心職責是監(jiān)控本地數(shù)據庫實例的運行狀態(tài)是否運行、是否掛起并通過網絡與其他節(jié)點的守護進程進行心跳通信共同決策集群狀態(tài)。當檢測到主庫故障時各守護進程會協(xié)商發(fā)起自動故障切換Failover。監(jiān)視器dmmonitor一個可選的、但強烈建議部署的圖形化或命令行監(jiān)控工具。它以一個獨立進程的形式運行可以連接集群中的所有守護進程提供一個全局視角來查看集群狀態(tài)、執(zhí)行手工切換等管理操作。在生產環(huán)境中部署監(jiān)視器能極大提升運維便利性。這些組件之間的網絡通信關系至關重要。主備庫之間需要開通端口進行歸檔日志的傳輸默認ARCHIVE_PORT如5236所有守護進程之間需要開通端口進行心跳和信息交互默認DW_PORT如5237監(jiān)視器則需要能連接到所有守護進程的端口默認MONITOR_PORT如5238。在規(guī)劃階段就必須在防火墻或安全組規(guī)則中放行這些端口的雙向通信。2.2 同步模式的選擇實時與即時達夢數(shù)據守護提供了兩種主要的日志同步模式選擇哪種模式直接影響了數(shù)據一致性和性能的權衡實時同步Realtime Sync這是最嚴格的數(shù)據保護模式。主庫事務提交前必須等待對應的事務日志Redo Log被備庫的日志寫入線程RLOG_SEND成功寫入備庫的本地日志文件。只有收到備庫的確認消息后主庫的事務才會提交成功。這種模式能確保備庫與主庫的數(shù)據強一致實現(xiàn)RPO0零數(shù)據丟失但會略微增加主庫事務的響應時間因為增加了網絡往返延遲。即時同步Immediate Sync一種折衷方案。主庫事務提交時只需確保日志被發(fā)送到備庫的日志接收緩沖區(qū)即可返回成功無需等待備庫寫入磁盤。這比實時同步更快但存在極小的數(shù)據丟失窗口期如果主庫在發(fā)送日志后、備庫寫入磁盤前發(fā)生故障且網絡也同時中斷則這部分已提交的事務數(shù)據可能會丟失。實操心得對于絕大多數(shù)對數(shù)據一致性要求極高的金融、交易類核心業(yè)務推薦使用實時同步模式。雖然犧牲一點性能但換來的是數(shù)據的絕對安全?，F(xiàn)在的網絡質量普遍較好帶來的延遲增加通常在可接受范圍內。只有在網絡延遲確實成為瓶頸且業(yè)務可以容忍秒級數(shù)據丟失的場景下才考慮即時同步。3. 搭建前的關鍵準備工作3.1 環(huán)境規(guī)劃與資源評估“工欲善其事必先利其器”。搭建前的規(guī)劃直接決定了后續(xù)部署的順利程度和集群的穩(wěn)定性。服務器規(guī)劃至少需要兩臺物理服務器或虛擬機。強烈建議主備服務器硬件配置CPU、內存、磁盤IO性能盡可能保持一致避免因性能差異導致備庫重做日志速度跟不上產生嚴重的日志堆積Archive Lag。操作系統(tǒng)需使用達夢官方認證的版本如CentOS 7/8、RedHat 7/8、麒麟V10等。網絡規(guī)劃IP與主機名為每臺服務器配置靜態(tài)IP并在/etc/hosts文件中做好主機名解析確保主備機之間可以通過主機名互相ping通。使用主機名而非IP進行配置可以提高配置的可讀性和可維護性。端口開放如前所述需要規(guī)劃并開放5236歸檔、5237守護、5238監(jiān)視器端口。如果部署在云上還需配置安全組規(guī)則。網絡質量主備機之間的網絡延遲和帶寬至關重要。建議部署在同一機房或可用區(qū)內網絡延遲應穩(wěn)定在1ms以下帶寬至少千兆。高延遲或抖動的網絡是數(shù)據守護集群穩(wěn)定運行的大敵。存儲規(guī)劃達夢數(shù)據庫的數(shù)據文件、日志文件、備份文件等需要獨立的存儲空間。建議使用高性能的SSD或NVMe磁盤。特別注意歸檔日志路徑ARCHIVE_DEST要有充足的空間并設置合理的歸檔日志刪除策略防止磁盤被撐滿。3.2 軟件安裝與基礎配置這部分工作需要在主備兩臺服務器上分別進行。達夢數(shù)據庫安裝從達夢官網下載對應操作系統(tǒng)版本的安裝包如dm8_setup_xxx.iso。使用root用戶掛載并執(zhí)行安裝程序。安裝過程中建議選擇“典型安裝”并指定一個獨立的用戶如dmdba和用戶組如dinstall來運行數(shù)據庫這是出于安全和管理的最佳實踐。安裝路徑如/opt/dmdbms建議保持一致。初始化數(shù)據庫實例使用dminit工具初始化兩個數(shù)據庫實例。這里有一個關鍵步驟備庫的數(shù)據庫參數(shù)必須與主庫兼容。最穩(wěn)妥的做法是先初始化主庫然后使用主庫的配置文件dm.ini作為參考再去初始化備庫確保關鍵參數(shù)如PAGE_SIZE、CASE_SENSITIVE等完全一致。# 在主庫服務器初始化實例假設實例名為DMSERVER /opt/dmdbms/bin/dminit PATH/dm8/data DB_NAMEDMSERVER INSTANCE_NAMEDMSERVER PAGE_SIZE32 CASE_SENSITIVE1 # 將生成的主庫dm.ini拷貝到備庫服務器用于參考初始化備庫配置環(huán)境變量與用戶權限為dmdba用戶配置.bash_profile添加DM_HOME和PATH。確保dmdba用戶對數(shù)據庫安裝目錄、數(shù)據目錄有完全的讀寫權限。4. 主備集群配置與搭建實操全流程4.1 主庫配置詳解主庫的配置是起點所有配置都集中在數(shù)據庫實例目錄下的dm.ini和dmarch.ini文件中。配置dm.ini打開主庫數(shù)據目錄下的dm.ini文件修改或確認以下關鍵參數(shù)INSTANCE_NAME DMSERVER_PRIMARY # 實例名便于識別 PORT_NUM 5236 # 數(shù)據庫服務端口默認5236 MAL_INI 1 # 啟用MAL系統(tǒng)這是守護集群通信的基礎 ARCH_INI 1 # 啟用歸檔配置 RLOG_SEND_APPLY_MON 64 # 設置發(fā)送歸檔日志時是否等待備庫確認。64為實時同步配置dmarch.ini歸檔配置文件這是最核心的配置之一。在該文件中定義歸檔目的地為備庫。[ARCHIVE_LOCAL] ARCH_TYPE LOCAL # 本地歸檔 ARCH_DEST /dm8/arch_local # 本地歸檔路徑用于備份和時間點恢復 ARCH_FILE_SIZE 1024 # 單個歸檔文件大小單位MB ARCH_SPACE_LIMIT 102400 # 歸檔空間上限單位MB0表示無限制 [ARCHIVE_REALTIME] ARCH_TYPE REALTIME # 實時歸檔類型 ARCH_DEST STANDBY_SERVER # 目標備庫的MAL鏈路名稱需與dmmal.ini對應 ARCH_FILE_SIZE 1024 ARCH_SPACE_LIMIT 0配置dmmal.iniMAL系統(tǒng)配置文件MALMail Address List是守護進程間通信的地址列表。主備庫的此文件內容必須嚴格一致。[MAL_INST1] MAL_INST_NAME DMSERVER_PRIMARY # 實例名與dm.ini中一致 MAL_HOST primary_host # 主庫服務器主機名或IP MAL_PORT 5337 # MAL通信端口通常用5337與守護端口不同 MAL_INST_HOST primary_host MAL_INST_PORT 5236 # 對應數(shù)據庫實例的服務端口 [MAL_INST2] MAL_INST_NAME DMSERVER_STANDBY MAL_HOST standby_host MAL_PORT 5337 MAL_INST_HOST standby_host MAL_INST_PORT 5236配置dmwatcher.ini守護進程配置文件[GRP1] DW_TYPE LOCAL # 本地守護類型 DW_MODE AUTO # 自動模式 DW_ERROR_TIME 10 # 認定遠程守護故障的時間(秒) INST_RECOVER_TIME 60 # 主庫重啟后等待備庫重新連接的時間 INST_ERROR_TIME 10 # 認定本地實例故障的時間 INST_OGUID 453331 # 守護組唯一標識主備必須相同建議使用dmkey工具生成 INST_INI /dm8/data/DMSERVER/dm.ini # 本地數(shù)據庫實例配置文件路徑 INST_AUTO_RESTART 1 # 實例故障后自動重啟 INST_STARTUP_CMD /opt/dmdbms/bin/dmserver # 實例啟動命令關鍵提示INST_OGUID守護組OGUID是集群的“身份證”主備庫及所有配置文件中必須完全相同?？梢允褂眠_夢提供的dmkey工具生成一個隨機且唯一的數(shù)字。4.2 備庫配置與數(shù)據同步初始化備庫的dm.ini、dmmal.ini、dmwatcher.ini配置文件內容與主庫高度相似但略有不同必須仔細核對。修改備庫dm.ini將INSTANCE_NAME改為DMSERVER_STANDBY并將ALTER_MODE_STATUS和ENABLE_OFFLINE_TS參數(shù)設置為0備庫默認只讀不允許修改表空間狀態(tài)。確保配置文件一致將主庫配置好的dmmal.ini和dmwatcher.ini拷貝到備庫對應位置。無需修改dmwatcher.ini中的INST_OGUID必須與主庫保持一致。檢查dmwatcher.ini中的INST_INI路徑是否正確指向備庫自己的dm.ini。初始化備庫數(shù)據關鍵步驟備庫不能直接初始化空庫必須通過主庫的備份來還原。這是保證數(shù)據起點一致性的唯一方法。在主庫執(zhí)行脫機備份關閉主庫服務使用dmrman工具進行備份。./dmrman CTLSTMTBACKUP DATABASE /dm8/data/DMSERVER/dm.ini FULL TO BACKUP_FILE BACKUPSET /dm8/backup/full_bak將備份集傳輸?shù)絺鋷焓褂胹cp或rsync將整個備份集目錄拷貝到備庫服務器。在備庫執(zhí)行還原與恢復在備庫服務器上使用dmrman執(zhí)行還原。./dmrman CTLSTMTRESTORE DATABASE /dm8/data/DMSERVER/dm.ini FROM BACKUPSET /dm8/backup/full_bak ./dmrman CTLSTMTRECOVER DATABASE /dm8/data/DMSERVER/dm.ini FROM BACKUPSET /dm8/backup/full_bak ./dmrman CTLSTMTRECOVER DATABASE /dm8/data/DMSERVER/dm.ini UPDATE DB_MAGIC最后一步UPDATE DB_MAGIC至關重要它更新了數(shù)據庫的內部標識使其能夠以備庫身份加入守護組。4.3 啟動集群與驗證配置完成后需要按照嚴格的順序啟動各個組件順序錯誤會導致集群無法正常建立。啟動順序第一步啟動主庫數(shù)據庫實例服務 (dmserver)。第二步啟動主庫的守護進程 (dmwatcher)。第三步啟動備庫數(shù)據庫實例服務 (dmserver)。此時備庫會嘗試連接主庫同步備份后的增量日志。第四步啟動備庫的守護進程 (dmwatcher)。兩個守護進程建立連接集群開始正常監(jiān)控。第五步可選啟動監(jiān)視器 (dmmonitor)用于圖形化監(jiān)控。驗證集群狀態(tài)連接到主庫執(zhí)行SQLSELECT * FROM V$DMARCH_INI;查看歸檔狀態(tài)確認ARCH_DEST指向的備庫狀態(tài)為VALID。連接到備庫執(zhí)行SQLSELECT * FROM V$DATABASE;查看DATABASE_MODE字段應為STANDBY備庫模式。使用監(jiān)視器或通過命令行查看守護進程狀態(tài)./dmmonitor /dm8/data/dmmonitor.ini在監(jiān)視器界面輸入show命令應看到主備庫狀態(tài)均為OPEN守護進程狀態(tài)為STARTUP集群狀態(tài)為NORMAL。模擬故障切換測試這是上線前必須進行的“消防演練”。在業(yè)務低峰期手動停止主庫的dmserver進程。觀察守護進程的日志 (dmwatcher.log) 和監(jiān)視器應該在數(shù)十秒內自動檢測到故障并完成切換。此時備庫應提升為新的主庫狀態(tài)變?yōu)镻RIMARY。驗證業(yè)務連接能否自動或手動切換到新的主庫IP或VIP上。5. 運維要點與深度避坑指南5.1 日常監(jiān)控與健康檢查集群搭建成功只是第一步持續(xù)的監(jiān)控是穩(wěn)定運行的保障。日志監(jiān)控定期檢查dmwatcher.log守護進程日志和數(shù)據庫的dmserver.log。關注是否有ERROR或WARNING級別的報錯特別是網絡超時、歸檔失敗等信息。歸檔延遲監(jiān)控在備庫執(zhí)行SELECT ARCH_LAG FROM V$ARCH_STATUS;可以查看歸檔延遲單位秒。一個健康的集群延遲應該穩(wěn)定在秒級甚至毫秒級。如果延遲持續(xù)增長需要排查網絡帶寬、備庫IO性能或主庫寫入壓力。系統(tǒng)視圖查詢熟練使用以下動態(tài)性能視圖是DBA的基本功V$DMARCH_INI查看歸檔配置和狀態(tài)。V$DATABASE查看數(shù)據庫模式PRIMARY/STANDBY。V$DMWATCHER查看本地守護進程信息。V$DMWATCHER_STAT查看守護進程統(tǒng)計信息。5.2 常見故障場景與應急處理即使規(guī)劃得再完善生產環(huán)境也難免遇到問題。以下是幾種典型故障的處理思路故障現(xiàn)象可能原因排查步驟與解決方案備庫歸檔狀態(tài)為INVALID1. 網絡不通或防火墻阻斷。2. 主庫dmarch.ini配置錯誤如MAL鏈路名不對。3. 備庫數(shù)據庫未啟動或處于非MOUNT狀態(tài)。1. 使用telnet或nc命令測試主備間ARCHIVE_PORT和MAL_PORT連通性。2. 核對主庫dmarch.ini中ARCH_DEST與備庫dmmal.ini中MAL_INST_NAME是否一致。3. 檢查備庫數(shù)據庫實例是否正常啟動。守護進程無法STARTUP狀態(tài)一直為CONFIRM1. 主備庫INST_OGUID不一致。2. 主備庫數(shù)據不同源即備庫不是從當前主庫備份恢復的。3. 備庫的dm.ini中ALTER_MODE_STATUS未設置為0。1. 仔細檢查主備所有dmwatcher.ini中的INST_OGUID必須完全相同。2. 這是一個致命錯誤需用主庫最新備份重新初始化備庫。3. 修改備庫dm.ini重啟實例。自動切換失敗1. 守護進程DW_ERROR_TIME或INST_ERROR_TIME設置過短在網絡抖動時誤判。2. 備庫重做日志速度慢有大量日志堆積不符合接管條件。3. 監(jiān)視器未配置或配置錯誤缺少仲裁節(jié)點。1. 適當調大超時參數(shù)但需權衡故障發(fā)現(xiàn)速度。2. 優(yōu)化備庫服務器性能特別是磁盤IO。檢查備庫是否有長時間運行的查詢阻塞了重做。3. 正確配置并啟動dmmonitor它在多數(shù)情況下是故障切換的仲裁者。主備數(shù)據不一致1. 有人在備庫執(zhí)行了DML或DDL操作備庫應為只讀。2. 歸檔日志在傳輸過程中損壞極罕見。1. 嚴格管理備庫賬號權限禁止非SELECT操作。通過觸發(fā)器或審計功能監(jiān)控。2. 對比主備庫關鍵表的校驗和或記錄數(shù)。如果出現(xiàn)不一致必須從主庫重新搭建備庫。5.3 備份恢復與集群擴容備份策略即使在有備庫的情況下定期的物理備份依然必不可少。備庫保護的是高可用備份保護的是邏輯錯誤或災難恢復。建議在主庫或備庫上定期執(zhí)行脫機或聯(lián)機全量備份并歸檔到異地。備庫重建當備庫服務器硬件故障或數(shù)據不一致無法修復時需要重建備庫。流程與初始搭建類似停止舊備庫 - 從當前主庫獲取最新備份 - 在新服務器上安裝軟件、還原數(shù)據 - 修改配置文件 - 重新加入集群。關鍵在于還原恢復后一定要執(zhí)行UPDATE DB_MAGIC。集群擴容數(shù)據守護支持一主多備。增加第二個備庫的流程與搭建第一個備庫幾乎完全相同準備新服務器 - 從主庫備份還原初始化 - 配置dmmal.ini需添加新備庫的MAL配置并同步到所有節(jié)點 - 配置新備庫的dmwatcher.ini- 按順序啟動。需要確保所有節(jié)點的dmmal.ini文件內容完全同步。6. 性能調優(yōu)與高級配置建議當集群穩(wěn)定運行后我們可以從一些高級角度進行優(yōu)化使其更貼合業(yè)務需求。歸檔路徑優(yōu)化將歸檔日志放在與數(shù)據文件不同的物理磁盤上可以避免IO爭用提升主庫事務處理能力和日志傳輸效率。使用高性能的NVMe SSD作為歸檔盤效果顯著。網絡優(yōu)化如果條件允許為守護集群的通信MAL和歸檔傳輸配置獨立的、高優(yōu)先級的網絡鏈路或VLAN與業(yè)務流量隔離避免網絡擁塞影響心跳和日志同步。備庫資源利用將備庫設置為READ ONLY模式后可以安全地在其上執(zhí)行報表查詢、數(shù)據抽取等只讀業(yè)務充分利用硬件資源。但需要注意復雜的查詢可能會消耗大量CPU和內存進而影響日志重做速度需要監(jiān)控ARCH_LAG。監(jiān)視器高可用生產環(huán)境建議部署2個或更多監(jiān)視器節(jié)點并配置在dmmonitor.ini中。多個監(jiān)視器通過投票機制避免單點故障確保在單個監(jiān)視器宕機時集群的自動切換仲裁機制依然有效。參數(shù)精細調校RLOG_SEND_THRESHOLD控制主庫發(fā)送日志的閾值。適當調大可以減少網絡報文數(shù)量但可能略微增加延遲。RLOG_APPLY_THRESHOLD控制備庫重做日志的閾值。影響備庫重做批處理的大小。這些參數(shù)沒有銀彈需要結合業(yè)務壓力、網絡條件和服務器性能通過監(jiān)控歸檔延遲和系統(tǒng)負載進行動態(tài)調整。搭建達夢8主備集群就像為你的數(shù)據核心構建了一個“雙活心臟”。整個過程涉及系統(tǒng)、網絡、存儲、數(shù)據庫多個層面的知識是對運維人員綜合能力的一次考驗。配置文件中的每一個參數(shù)都值得推敲啟動順序的每一步都關乎成敗。我最深的一點體會是“測試驅動部署”——在正式上線前務必在模擬環(huán)境中進行完整的搭建流程演練、故障切換測試和壓力測試。把可能遇到的問題都在測試階段暴露和解決比如防火墻規(guī)則、主機名解析、權限問題等這樣才能在生產部署時心中有數(shù)手到擒來。當看到監(jiān)視器上集群狀態(tài)穩(wěn)定地顯示為NORMAL主備庫之間歸檔流暢無延遲時那種由技術帶來的確定性和安全感正是我們從事這份工作的價值所在。