簡介這是一份面向華為HCIE-GaussDB認(rèn)證考生的筆試題解析資料適合有一定工作經(jīng)驗(yàn)的數(shù)據(jù)庫工程師、運(yùn)維及技術(shù)管理人員使用也適用于備考沖刺與日常架構(gòu)復(fù)盤。內(nèi)容圍繞考試高頻考點(diǎn)展開涵蓋GTM、CM、CN、DN等核心組件的功能與部署形態(tài)同城高可用、跨Region雙集群容災(zāi)、流式容災(zāi)與備份恢復(fù)流程并涉及動(dòng)態(tài)數(shù)據(jù)脫敏、統(tǒng)一審計(jì)、索引推薦、NUMA-Aware優(yōu)化及CGroup資源管理等高級特性。資源包為單個(gè)PDF文件共1份、大小623KB具備便攜閱讀與檢索便利性。目前已有219人學(xué)習(xí)題目解析結(jié)合具體案例與參數(shù)配置展開有助于考生理解GaussDB高可用設(shè)計(jì)、故障切換、容災(zāi)預(yù)案與性能調(diào)優(yōu)思路對生產(chǎn)環(huán)境中的系統(tǒng)健壯性建設(shè)也有參考價(jià)值。1. HCIE-GaussDB筆試題到底難在哪不只是數(shù)據(jù)庫知識是故障決策HCIE-GaussDB筆試的掛點(diǎn)往往不在SQL語法而在“高可用容災(zāi)”這一整塊你不僅要背出主備復(fù)制、故障切換的原理還得在幾十道場景題里判斷“這時(shí)該執(zhí)行哪條命令、先做哪一步、丟不丟數(shù)據(jù)”。這個(gè)認(rèn)證對應(yīng)的是 GaussDB 體系里偏核心技術(shù)和運(yùn)維架構(gòu)的能力面向正在做數(shù)據(jù)庫交付、要獨(dú)立設(shè)計(jì)容災(zāi)方案的DBA或解決方案工程師。很多人把精力花在調(diào)優(yōu)上結(jié)果容災(zāi)題翻車這是最虧的。本文就按筆試真正會考的維度把核心機(jī)制和高可用切換的細(xì)節(jié)拆開每條結(jié)論都給出能落地的判斷依據(jù)和命令。2. GaussDB核心技術(shù)怎么考存儲引擎、MVCC、索引和執(zhí)行計(jì)劃的邊界2.1 行存表與列存表的選型判斷筆試常拿場景讓你二選一GaussDB 里建表要先想清楚orientationrow還是orientationcolumn這是第一個(gè)高頻考點(diǎn)。行存表按行組織數(shù)據(jù)適合點(diǎn)查、頻繁增刪改的OLTP場景列存表按列批量存儲數(shù)據(jù)壓縮比高適合分析型查詢和批量導(dǎo)入但在高頻小事務(wù) update 上的代價(jià)很高。筆試題不會直接問你“什么是行存”而是給你一段業(yè)務(wù)描述一張訂單流水表每天有千萬級導(dǎo)入查詢經(jīng)常按客戶維度做聚合分析問建表應(yīng)該選哪種。答案應(yīng)當(dāng)是列存。另一種考法反著來一張并發(fā)更新很高的賬戶表用列存建出來后性能反而下降問原因。這類題的關(guān)鍵判斷點(diǎn)是“更新粒度”和“掃描范圍”。建表命令長這樣筆試?yán)锍霈F(xiàn)WITH (orientationcolumn)時(shí)你要反應(yīng)過來這是在建列存表CREATE TABLE order_line ( order_id bigint, cust_id bigint, amount numeric(10,2), create_time timestamp ) WITH (orientationcolumn) DISTRIBUTE BY HASH(order_id);上面DISTRIBUTE BY HASH(order_id)是分布式 GaussDB 的分片鍵決定數(shù)據(jù)分布在哪些 DN 上。選分片鍵要選數(shù)據(jù)均勻、常用作關(guān)聯(lián)條件的列選了order_id這種高基數(shù)列數(shù)據(jù)才鋪得開。如果你的題目里沒有分片相關(guān)描述說明考的是單機(jī)語義別主動(dòng)引入分布式概念。列存表還有一個(gè)容易被忽略的坑不是所有索引都能像行存表那樣建。列存按 CUCompression Unit組織數(shù)據(jù)普通 B-tree 索引在很多版本上不支持或收益極低它更依賴 CU 內(nèi)部的 zonemap 做掃描剪枝。所以當(dāng)題目里出現(xiàn)“列存表上建了 B-tree 索引加速點(diǎn)查”的描述時(shí)多數(shù)時(shí)候是錯(cuò)誤選項(xiàng)。2.2 MVCC與事務(wù)隔離級別快照在什么位置失效MVCC 是 GaussDB 筆試題里的送分題也是丟分題。GaussDB 采用多版本并發(fā)控制讀操作不阻塞寫操作這好理解。但關(guān)于“快照什么時(shí)候固定”的判斷很多人記混。讀已提交Read Committed下事務(wù)內(nèi)每條語句執(zhí)行時(shí)重新獲取快照所以同一個(gè)事務(wù)里兩次查詢可能看到不同結(jié)果?？芍貜?fù)讀Repeatable Read下事務(wù)第一次執(zhí)行查詢時(shí)獲取快照之后整個(gè)事務(wù)都讀這個(gè)快照。GaussDB 默認(rèn)隔離級別通常是讀已提交這一點(diǎn)經(jīng)常出現(xiàn)在場景題里。典型題目是這樣的事務(wù) A 開啟后查了 count()事務(wù) B 插入一行并提交事務(wù) A 再次查 count()問看到的結(jié)果。如果題目沒特別聲明隔離級別按讀已提交理解答案是“兩次可能不一樣”。如果題目寫明SET TRANSACTION ISOLATION LEVEL REPEATABLE READ答案就是“一樣”。另一個(gè)高頻混淆點(diǎn)是更新沖突。兩個(gè)事務(wù)同時(shí) update 同一行后執(zhí)行的那個(gè)會等待鎖而不是立刻報(bào)錯(cuò)如果等待超時(shí)會看到鎖等待超時(shí)錯(cuò)誤。很多人把“不可重復(fù)讀”和“更新沖突”混在一起答其實(shí)前者是快照讀后者是當(dāng)前讀加鎖的行為。筆試?yán)镒⒁饪搭}目描述的是“select”還是“update”這決定了答案方向。2.3 索引與執(zhí)行計(jì)劃EXPLAIN 輸出要從里往外讀索引題如果只考“唯一索引、普通索引”就太淺了HCIE 筆試會疊加執(zhí)行計(jì)劃一起考。GaussDB 的 EXPLAIN 輸出從上到下是執(zhí)行算子的嵌套關(guān)系正確的讀法是從最內(nèi)層、縮進(jìn)最深的算子開始看逐層向外。比如一段計(jì)劃里有Index Scan套著Bitmap Heap Scan說明索引只用來定位還是要回表取數(shù)。三類常見斷言的題目長這樣第一WHERE name LIKE %張三%這種前后模糊查詢B-tree 索引會失效。因?yàn)樗饕荒馨辞熬Y匹配定位前導(dǎo)通配符導(dǎo)致無法從索引根節(jié)點(diǎn)向下二分查找。這種情況要答“順序掃描”而不是“索引掃描”。第二分區(qū)表查詢不帶分區(qū)鍵分區(qū)裁剪失效掃描范圍變成全分區(qū)。比如一張按create_time做范圍分區(qū)的表查詢條件是WHERE cust_id 100不帶時(shí)間條件優(yōu)化器只能掃所有分區(qū)。題目會讓你判斷“是否能用分區(qū)裁剪”答“不能”。第三執(zhí)行計(jì)劃里出現(xiàn)CStore Scan說明查詢打在列存表上看到Seq Scan則說明全表掃描。如果題目給了一個(gè)慢 SQL問為什么沒走索引優(yōu)先檢查條件列的隱式類型轉(zhuǎn)換比如WHERE phone 13800000000讓字符串列和數(shù)值常量比較索引就廢了。2.4 安全與權(quán)限模型三權(quán)分立和審計(jì)是另一個(gè)考點(diǎn)GaussDB 的安全模型你至少要記住三權(quán)分立安全管理員負(fù)責(zé)安全策略配置審計(jì)管理員負(fù)責(zé)審計(jì)日志數(shù)據(jù)庫管理員只負(fù)責(zé)數(shù)據(jù)庫運(yùn)維三權(quán)互相不能越界。題目會問“為什么不能用超級管理員跑日常業(yè)務(wù)”答案指向最小權(quán)限原則和可審計(jì)性。審計(jì)日志的查詢?nèi)肟谝彩歉哳l點(diǎn)。GaussDB 提供審計(jì)管理員視角的查詢接口能看到登錄、DDL、DML 等操作記錄。常見的坑是業(yè)務(wù)賬號給得太寬審計(jì)日志被業(yè)務(wù)噪音淹沒導(dǎo)致出問題后追溯不到是誰干的。答案方向是“權(quán)限收斂 按需開啟審計(jì)項(xiàng)”而不是把審計(jì)日志一直全量開著畢竟全量審計(jì)本身會拖性能。安全這塊的筆試題大量靠記憶難的是區(qū)分“透明加密”“SSL加密”的適用位置。透明加密解決的是存儲側(cè)文件被拖走之后的數(shù)據(jù)泄露SSL解決的是客戶端和服務(wù)器之間傳輸被截獲的問題。兩道題經(jīng)常并排出現(xiàn)別選反。3. 高可用容災(zāi)架構(gòu)選型從一主一備到跨機(jī)房每一層都有代價(jià)3.1 同步復(fù)制、半同步與異步RPO 和性能的取舍關(guān)系GaussDB 主備復(fù)制按同步程度分三檔筆試考的最多是“同步復(fù)制是不是一定比異步好”。答案是否定的。同步復(fù)制要求主庫提交事務(wù)時(shí)等待備庫日志落盤才返回成功RPO 接近零但主庫的響應(yīng)時(shí)延會被備庫拖長異步復(fù)制主庫不等備庫性能好但主庫故障的一瞬間備庫可能缺最后一段日志。半同步是個(gè)中間態(tài)主庫等備庫把日志接收過來但不一定等它落盤。它的 RPO 比異步小性能損耗比同步小。真正的考點(diǎn)出現(xiàn)在判斷題里同步備機(jī)故障主庫會怎樣很多實(shí)現(xiàn)會主動(dòng)降級把同步復(fù)制臨時(shí)退化成異步保證主庫可用但這時(shí) RPO 就不再是零。如果你答“主庫拒絕寫入”不一定錯(cuò)但要看清題目說的是什么部署模式GaussDB 常見策略是主庫繼續(xù)服務(wù)、日志堆積備庫恢復(fù)后再追平。涉及參數(shù)時(shí)你能記住synchronous_standby_names是控制同步備機(jī)名單的就夠了。筆試給的場景往往是“一主一備要求故障時(shí)零丟失”這時(shí)你要一眼看出零丟失需要同步復(fù)制并且單個(gè)同步備機(jī)沒有冗余能力備機(jī)故障會讓保護(hù)降級。3.2 級聯(lián)備跨機(jī)房容災(zāi)的標(biāo)準(zhǔn)解法跨機(jī)房復(fù)制最常見的翻車點(diǎn)是以為“備庫離主庫越近越好”。如果容災(zāi)機(jī)房離生產(chǎn)機(jī)房幾十上百公里讓主庫直接把日志推給異地備庫鏈路時(shí)延會直接拖慢每一筆事務(wù)。級聯(lián)備的意思是在生產(chǎn)機(jī)房放一個(gè)本地備庫異地備庫再從本地備庫拉日志鏈路從“主庫→異地備庫”變成“主庫→本地備庫→異地備庫”。這么做的好處是主庫只對本地備庫負(fù)責(zé)異地同步的時(shí)延由本地備庫承擔(dān)主庫事務(wù)RT不受長鏈路拖累。筆試給的判斷題通常是級聯(lián)備庫能不能繼續(xù)向下級聯(lián)答案是可以但級聯(lián)層數(shù)越多數(shù)據(jù)追平和切換驗(yàn)證的復(fù)雜度越高不能為了省帶寬無限加級聯(lián)。級聯(lián)備的另一種考法是算 RPO。主庫故障瞬間數(shù)據(jù)可能已經(jīng)傳到本地備庫但還沒傳往異地備庫這時(shí)異地備庫的數(shù)據(jù)滯后量取決于兩級之間最近一次同步的進(jìn)度。你能畫出數(shù)據(jù)流向就能算出“最后一條日志到底卡在哪一環(huán)”這就是題目的答案。3.3 分布式架構(gòu)下的高可用CN、DN 和多數(shù)派選主HCIE-GaussDB 的分布式形態(tài)比單機(jī)多一層協(xié)調(diào)節(jié)點(diǎn) CN 負(fù)責(zé)接收SQL和生成執(zhí)行計(jì)劃數(shù)據(jù)節(jié)點(diǎn) DN 負(fù)責(zé)實(shí)際存儲事務(wù)管理由全局事務(wù)管理器負(fù)責(zé)。筆試?yán)锔呖捎妙}會從“一個(gè)實(shí)例掛了”升級成“一個(gè) DN 的主備切換了業(yè)務(wù)為什么出現(xiàn)短時(shí)報(bào)錯(cuò)”。分布式高可用的粒度是分片。用戶表按分片鍵拆到多個(gè) DN 上每個(gè) DN 自己帶一主一備。某個(gè) DN 主節(jié)點(diǎn)故障時(shí)該 DN 的備節(jié)點(diǎn)通過多數(shù)派選舉升主其他 DN 不受影響業(yè)務(wù)只感覺到這一時(shí)刻部分事務(wù)報(bào)錯(cuò)或重試。如果你答“整個(gè)集群不可用”說明沒理解分片容災(zāi)的邊界。多數(shù)派選主是另一個(gè)必考點(diǎn)一個(gè)分片兩副本只有一主一備網(wǎng)絡(luò)被切斷后備節(jié)點(diǎn)不會自動(dòng)升主。因?yàn)閮晒?jié)點(diǎn)無法形成多數(shù)派強(qiáng)行升主會產(chǎn)生雙主腦裂。三個(gè)節(jié)點(diǎn)時(shí)需要至少兩票。題目如果問“為什么斷網(wǎng)后集群沒有選出新主”先數(shù)節(jié)點(diǎn)數(shù)再判斷是否有超過半數(shù)的存活節(jié)點(diǎn)這是快速得分點(diǎn)。3.4 容災(zāi)方案選型對照實(shí)例級、集群級、Region級怎么選筆試題特別愛給一段成本約束讓你選容災(zāi)方案。你要記住三個(gè)檔位實(shí)例級高可用解決單機(jī)故障用主備復(fù)制RPO 取決于同步級別集群級容災(zāi)解決機(jī)房內(nèi)部分節(jié)點(diǎn)批量故障涉及多副本跨機(jī)架部署GaussDB 的副本可以跨 AZRegion 級容災(zāi)解決整個(gè)機(jī)房不可用的問題常見做法是跨 Region 復(fù)制和定期備份。對比時(shí)用這張表快速定位答案容災(zāi)層級應(yīng)對故障常用手段RPO 預(yù)期RTO 預(yù)期實(shí)例級單進(jìn)程/單機(jī)故障主備復(fù)制、自動(dòng)切換同步近0異步分鐘級分鐘級集群級機(jī)架/部分節(jié)點(diǎn)故障跨AZ多副本同步近0分鐘級Region級整機(jī)房故障跨Region復(fù)制 備份分鐘到小時(shí)級分鐘到小時(shí)級判斷題里出現(xiàn)“跨 Region 復(fù)制要配同步復(fù)制保證零丟失”這種說法基本是錯(cuò)的?？?Region 長鏈路下強(qiáng)同步會讓性能差到不可接受實(shí)際方案一般是異步復(fù)制加定期備份RPO 小時(shí)級可接受。選型題的核心邏輯是故障域越大保護(hù)的冗余度越高但性能損耗和數(shù)據(jù)丟失的容忍度也越高三者必須匹配不能既要零丟失又要高性能。4. 容災(zāi)切換與故障處理命令、順序和代價(jià)4.1 RPO/RTO 計(jì)算題先畫日志時(shí)間線容災(zāi)題里最怕給具體時(shí)間點(diǎn)讓算 RPO。這類題一旦畫錯(cuò)時(shí)間線一題分就沒了。RPO 是“主庫故障時(shí)會丟多少時(shí)間的數(shù)據(jù)”RTO 是“恢復(fù)業(yè)務(wù)花了多久”。給你個(gè)具體場景練手主庫 10:00 宕機(jī)備庫日志回放到 09:55那么 RPO5 分鐘丟了這 5 分鐘的數(shù)據(jù)。如果業(yè)務(wù)在 10:20 恢復(fù)RTO20 分鐘。題目里如果還給了“備庫在 10:05 完成日志回放并對外提供服務(wù)”那么回放那 5 分鐘算在 RTO 里因?yàn)闃I(yè)務(wù)從 10:00 中斷到 10:20。容易漏的是“檢測時(shí)間”和“人工介入時(shí)間”。自動(dòng)切換比手動(dòng)切換省掉的就是這部分。只要題目特別提到“管理員確認(rèn)后才切換”RTO 就要把確認(rèn)時(shí)間算進(jìn)去。做題時(shí)建議把時(shí)間軸寫在草稿紙上故障點(diǎn)、數(shù)據(jù)最新點(diǎn)、業(yè)務(wù)恢復(fù)點(diǎn)三個(gè)點(diǎn)之間的差值就是答案。4.2 switchover 和 failover正常切換和強(qiáng)制切換別用反命令正常切換叫 switchover用在計(jì)劃維護(hù)先把主庫優(yōu)雅停止再把備庫升主原主庫降級為備庫全程不丟數(shù)據(jù)日志不中斷。強(qiáng)制切換叫 failover用在主庫無法正常停止或已宕機(jī)直接讓備庫接管原主庫即使恢復(fù)也必須降級重建否則就是雙主。筆試常給一段命令讓你判斷對錯(cuò)。正常切換的命令順序如下這套操作在維護(hù)窗口里非常標(biāo)準(zhǔn)# 1. 登錄主庫執(zhí)行節(jié)點(diǎn)切換前先檢查集群整體狀態(tài) cm_ctl query -v # 2. 把原主庫優(yōu)雅停止-m fast 表示快速停實(shí)例回滾未完成事務(wù) gs_ctl stop -D /data/data_dn1 -m fast # 3. 在備庫上執(zhí)行切換把備庫提升為新主庫 gs_ctl switchover -D /data/data_dn2 -m primary # 4. 確認(rèn)新主庫狀態(tài)再?zèng)Q定原主庫是直接重建還是重新拉起 cm_ctl query -v-m fast和-m clean的區(qū)別要分清fast 會做事務(wù)回滾clean 直接?？赡艽嬖谖绰浔P數(shù)據(jù)。計(jì)劃內(nèi)維護(hù)選 fast并發(fā)量大時(shí)回滾時(shí)間會長故障時(shí)不走正常停止直接跳步。強(qiáng)制切換的命令是gs_ctl failover -D /data/data_dn2不需要先停原主庫因?yàn)樵鲙炜赡芤呀?jīng)失聯(lián)。failover 之后原主庫一旦恢復(fù)必須用gs_ctl build -D /data/data_dn1 -b standby重建為備庫從新主庫拉全量數(shù)據(jù)追平。這里的坑是如果先把原主庫以主庫身份啟動(dòng)兩個(gè)節(jié)點(diǎn)數(shù)據(jù)會分叉后續(xù)再也無法建立復(fù)制關(guān)系。4.3 腦裂和雙主最嚴(yán)重的分布式故障怎么發(fā)現(xiàn)和收斂腦裂場景題在筆試?yán)锍霈F(xiàn)頻率很高?，F(xiàn)象是網(wǎng)絡(luò)發(fā)生分區(qū)備庫和主庫彼此失聯(lián)但業(yè)務(wù)節(jié)點(diǎn)還能訪問其中某些節(jié)點(diǎn)于是兩個(gè)節(jié)點(diǎn)都認(rèn)為自己是主、都接受寫入。數(shù)據(jù)從此分叉。GaussDB 的多數(shù)派選舉機(jī)制能防住有仲裁節(jié)點(diǎn)的場景但兩副本斷網(wǎng)場景保護(hù)不了這正是第 3 章說的“兩節(jié)點(diǎn)無法形成多數(shù)派備庫不應(yīng)升主”。如果題目描述里出現(xiàn)了“備庫強(qiáng)制升主后原主庫恢復(fù)”后續(xù)就會進(jìn)入雙主狀態(tài)。處理腦裂的方法是先隔離后重建用集群狀態(tài)查詢命令確認(rèn)兩個(gè)節(jié)點(diǎn)的角色確定哪邊的數(shù)據(jù)更新或哪邊是業(yè)務(wù)真正連接的把人少或無業(yè)務(wù)的一邊先停掉把它的角色降為備再從保留的主庫重新 build。這里沒有一鍵恢復(fù)的“后悔藥”必須人工判斷數(shù)據(jù)取舍所以筆試題往往卡在“先停誰”上。原則是保主庫數(shù)據(jù)、保業(yè)務(wù)正在寫的一側(cè)。4.4 一套可落地的切換檢查清單真正做切換最怕漏檢查項(xiàng)。筆試?yán)镫m然沒有“請你列檢查清單”這種題但故障場景題里的錯(cuò)誤選項(xiàng)大多是“沒檢查日志斷點(diǎn)就切換”或“沒改應(yīng)用連接串”。我習(xí)慣按這個(gè)順序來給你做個(gè)參考檢查項(xiàng)具體動(dòng)作角色確認(rèn)切換前執(zhí)行狀態(tài)查詢確認(rèn)當(dāng)前主備角色數(shù)據(jù)斷點(diǎn)對比主備最新 LSN/日志位點(diǎn)確認(rèn)沒有未同步日志連接檢查確認(rèn)應(yīng)用連接串是否會隨切換自動(dòng)切換到新主庫實(shí)例狀態(tài)新主庫是否完成 redo 回放能否正常接受讀寫重建準(zhǔn)備原主庫恢復(fù)后規(guī)劃 build 方向和窗口切換后不要急著讓應(yīng)用立刻跑全量業(yè)務(wù)先做讀寫冒煙測試再放量。這個(gè)順序在題目里也常見備庫升主后立刻涌入大量業(yè)務(wù)導(dǎo)致新主庫卡死原因就是沒留出日志回放和緩存預(yù)熱的時(shí)間這個(gè)教訓(xùn)值一次考試分。5. GaussDB筆試題型避坑筆記五類高頻雷區(qū)與判斷思路5.1 同步備機(jī)為什么 RTO 反而更高現(xiàn)象題目里說某系統(tǒng)用同步復(fù)制RPO 為零但故障切換后業(yè)務(wù)中斷時(shí)間很長問原因。很多人覺得同步復(fù)制既保護(hù)數(shù)據(jù)又應(yīng)該切換快答案是反的。原因同步復(fù)制讓主庫每筆事務(wù)都等備機(jī)落盤備機(jī)負(fù)載高時(shí)會拖慢主庫寫入故障發(fā)生后備機(jī)要回放全量日志日志量越大回放越久這是 RTO 的主要構(gòu)成。RPO 管丟多少RTO 管恢復(fù)多久兩者沒有正相關(guān)不能因?yàn)?RPO 零就覺得 RTO 一定短。解決答題時(shí)把“備用回放日志耗時(shí)”和“應(yīng)用重新路由耗時(shí)”兩塊說清楚就能對上得分點(diǎn)。設(shè)計(jì)上要縮短 RTO需要加長備機(jī)預(yù)先處理日志的能力或做資源預(yù)留而不是盲目改同步方式。5.2 隔離級別和快照讀混淆導(dǎo)致 count 結(jié)果判斷錯(cuò)現(xiàn)象一道題里兩個(gè)事務(wù)并發(fā)一個(gè)查 count一個(gè)插入提交問事務(wù) A 兩次 count 是否相同。很多人下意識答“可重復(fù)讀兩次一樣”丟了默認(rèn)隔離級別這個(gè)前提。原因GaussDB 默認(rèn)隔離級別是讀已提交事務(wù)內(nèi)每語句單獨(dú)取快照兩次 count 可能不一樣。只有顯式聲明可重復(fù)讀快照才會在整個(gè)事務(wù)期間固定。解決做題先找事務(wù)控制語句?？吹紹EGIN; SELECT ...; COMMIT;沒寫隔離級別一律按讀已提交處理題目寫SET TRANSACTION ISOLATION LEVEL REPEATABLE READ才按可重復(fù)讀答。這個(gè)判斷十秒能完成卻年年有人錯(cuò)。5.3 列存表能不能建普通 B-tree 索引現(xiàn)象判斷“對列存表創(chuàng)建普通 B-tree 索引來加快點(diǎn)查”是否正確答案是錯(cuò)的。原因列存表數(shù)據(jù)按 CU 批量組織每一列的 CU 內(nèi)部自帶 zonemap可以跳過不滿足條件的存儲塊。普通行級 B-tree 索引與這種存儲結(jié)構(gòu)不匹配而且列存表的高壓縮場景下索引維護(hù)成本極高。解決遇到列存場景的點(diǎn)查需求優(yōu)先判斷題目設(shè)計(jì)是否合理。如果非要快速點(diǎn)查要么改成行存表要么讓查詢走分區(qū)裁剪和列存掃描的剪枝能力而不是強(qiáng)加 B-tree。這條在多個(gè)版本的筆試題中反復(fù)出現(xiàn)屬于反復(fù)翻車的經(jīng)典題。5.4 failover 后原主庫直接啟動(dòng)造成數(shù)據(jù)分叉現(xiàn)象強(qiáng)制切換完成后原主庫恢復(fù)網(wǎng)絡(luò)管理員沒做降備重建直接啟動(dòng)原主庫隨后發(fā)現(xiàn)兩側(cè)數(shù)據(jù)不一致應(yīng)用讀寫混沌。原因failover 之后新主庫已經(jīng)接受了新的寫入原主庫停留在故障前的數(shù)據(jù)狀態(tài)兩份數(shù)據(jù)已經(jīng)分叉。這時(shí)候原主庫只能作為備庫或者導(dǎo)數(shù)據(jù)不能充當(dāng)主庫繼續(xù)服務(wù)。解決答題套路是“failover 后原主庫必須執(zhí)行 build 重建以新主庫為準(zhǔn)”。如果題目問“如何讓原主庫重新加入集群”答案不是 start而是先把角色改 standby再全量重建。把“啟動(dòng)”當(dāng)成“恢復(fù)”是最危險(xiǎn)的直覺。5.5 多數(shù)派與法定票數(shù)為什么集群“沒主”比“雙主”好現(xiàn)象三節(jié)點(diǎn)集群里一個(gè)節(jié)點(diǎn)宕機(jī)剩下兩個(gè)節(jié)點(diǎn)網(wǎng)絡(luò)分區(qū)集群沒有選出新主業(yè)務(wù)不可用。問該方案是否合理。原因多數(shù)派選舉要求超過半數(shù)節(jié)點(diǎn)可用。三節(jié)點(diǎn)兩兩斷網(wǎng)后任何一側(cè)都無法湊足兩票決定“不產(chǎn)生新主”是為了避免雙主和數(shù)據(jù)分叉。寧可不可用不可亂用這是分布式系統(tǒng)的一致性原則。解決題目里出現(xiàn)“少數(shù)節(jié)點(diǎn)強(qiáng)制升主”的選項(xiàng)都是錯(cuò)誤答案。真正做題時(shí)要看副本數(shù)和存活數(shù)兩副本至少一票三副本要兩票四副本要三票以此類推。沒有拿到多數(shù)票就升主后續(xù)必然出腦裂事故。6. 用社區(qū)版復(fù)現(xiàn)HCIE筆試的關(guān)鍵實(shí)驗(yàn)從安裝到故障注入用華為 GaussDB 社區(qū)版openGauss 內(nèi)核把主備復(fù)制跑通是對付筆試最好的背書。整個(gè)操作只在一臺或多臺虛機(jī)上完成不需要額外硬件。先準(zhǔn)備至少兩臺虛機(jī)IP 分別記為 192.0.2.10 和 192.0.2.20操作系統(tǒng)選 openEuler 或 CentOS 7 系內(nèi)存 2GB 以上。社區(qū)版安裝通常分三步下載安裝包并解壓用gs_initdb初始化數(shù)據(jù)目錄再用gs_ctl start啟動(dòng)。安裝完成后把主備庫的配置串起來主備復(fù)制核心是postgresql.conf里的replconninfo連接串它告訴主備之間如何互相通信。配好之后啟動(dòng)備庫并執(zhí)行一次 build備庫就會自動(dòng)把主庫的全量數(shù)據(jù)拉過來。搭好之后在備庫上執(zhí)行狀態(tài)查詢看到sync_state為Sync時(shí)說明同步復(fù)制已經(jīng)生效。這個(gè)字段是筆試判斷“同步還是異步”的最直接證據(jù)也是你對概念從“背下來”變成“看得見”的分水嶺。# 在備庫執(zhí)行查看本節(jié)點(diǎn)與主庫的復(fù)制關(guān)系 gs_ctl query -D /data/data_dn2 # 示例輸出里的 KEY 部分會顯示同步狀態(tài) # Per-node state: # 1 192.0.2.10 PRIMARY # 2 192.0.2.20 STANDBY接著做故障注入直接殺掉主庫進(jìn)程模擬宕機(jī)然后到備庫執(zhí)行 failover。你會發(fā)現(xiàn)備庫立刻升主但業(yè)務(wù)連接如果在原主庫需要重新配置或依賴中間件重試。這個(gè)實(shí)驗(yàn)做完你對第 4.2 節(jié)里 switchover 和 failover 的差異就不再是死記而是親眼看到“原主庫沒有干凈退出”這條路徑的代價(jià)。最后把原主庫重新拉起執(zhí)行 build 降為備庫兩邊數(shù)據(jù)追平。你親手走一遍“宕機(jī)→強(qiáng)切→重建”閉環(huán)回看筆試題里那些關(guān)于 RPO、雙主、多數(shù)派的選項(xiàng)會清晰很多。我當(dāng)年就是這么把錯(cuò)題弄明白的先查清楚每道題對應(yīng)哪條命令、哪個(gè)日志位點(diǎn)再去虛機(jī)上敲一遍產(chǎn)生的行為比反復(fù)看解析有效得多希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取