簡介面向企業(yè)級分布式數(shù)據(jù)庫部署場景這份GaussDB 100 1.0.1EulerOS 20 SP8 64位安裝包適用于需要在華為EulerOS環(huán)境中搭建高可用、強一致分布式數(shù)據(jù)庫的運維與開發(fā)人員。包內(nèi)共6個文件以4個Python腳本為主包含安裝引導(dǎo)、版本升級、SSH密鑰配置及公共函數(shù)處理腳本另附運行時安裝包與sha256校驗文件便于核對包體完整性。整個資源僅7.39MB輕量易獲取。目前已有1310人學(xué)習(xí)下載。GaussDB 100采用分布式架構(gòu)、列式存儲與并行執(zhí)行引擎支持ACID事務(wù)與橫向擴展適合高并發(fā)、海量數(shù)據(jù)及在線分析場景。這一壓縮包集中提供了部署所需的腳本與校驗工具可以幫助參考官方文檔快速完成基礎(chǔ)環(huán)境配置也能從中了解該操作系統(tǒng)上的文件組織與部署思路腳本功能劃分清晰便于分類復(fù)用為后續(xù)調(diào)優(yōu)與橫向擴展、構(gòu)建可擴展的數(shù)據(jù)服務(wù)打下基礎(chǔ)。1. 先搞清楚這個包是什么GaussDB 100 能在什么場景幫你省心看到這一長串文件名多數(shù)人第一反應(yīng)是又一個數(shù)據(jù)庫壓縮包解壓裝上不就行了。但如果你真這么急著下手大概率會在初始化階段被各種異常勸退。GaussDB 100 的定位和常見的開源數(shù)據(jù)庫不太一樣它主打輕量、穩(wěn)定、單機高并發(fā)部署完的資源占用比動不動就按 GB 吃內(nèi)存的常規(guī)數(shù)據(jù)庫友好得多特別適合中小規(guī)模業(yè)務(wù)系統(tǒng)、邊緣計算節(jié)點和嵌入式數(shù)據(jù)存儲場景。這個 1.0.1 版本的包針對性也很強文件名里的 EULER20SP8 說明它只保證在對應(yīng)的 64 位系統(tǒng)環(huán)境上平滑運行版本不匹配就是給自己找麻煩。這篇筆記從環(huán)境檢查、安裝、初始化、排錯到驗證把完整的落地路徑走一遍。2. 環(huán)境檢查與安裝準(zhǔn)備版本匹配是第一步別急著解壓2.1 為什么數(shù)據(jù)庫安裝包要綁定系統(tǒng)版本先說我踩過的一個坑。之前在一臺系統(tǒng)版本和包名對不上的設(shè)備上強行解壓過類似產(chǎn)品結(jié)果初始化時反復(fù)報錯翻日志看到的是各種動態(tài)庫加載異常。后來仔細(xì)一看才發(fā)現(xiàn)數(shù)據(jù)庫的二進制程序在編譯階段就鏈接了特定版本的系統(tǒng)基礎(chǔ)庫glibc 版本只要差一個小版本運行表現(xiàn)都可能完全不一樣。文件名里的 EULER20SP8 不是隨手寫的它是在明確告訴你這個壓縮包只針對目標(biāo)系統(tǒng) 20 SP8 64 位環(huán)境做過完整驗證換一個系統(tǒng)版本就不保證能跑。很多從傳統(tǒng)運維轉(zhuǎn)過來的人不理解為什么數(shù)據(jù)庫要綁操作系統(tǒng)版本。其實邏輯很簡單數(shù)據(jù)庫是直接跟操作系統(tǒng)打交道的本地程序文件系統(tǒng)、內(nèi)存分配、線程調(diào)度都依賴底層的系統(tǒng)調(diào)用和系統(tǒng)庫。系統(tǒng)庫版本不匹配輕則報錯重則進程直接閃退。更隱蔽的是有些問題不是初始化階段就暴露而是在業(yè)務(wù)運行一段時間后某個特定 SQL 觸發(fā)到不兼容的分支才崩潰這種問題排起來非常費勁。所以判斷這個包能不能用的第一條件不是數(shù)據(jù)庫版本而是操作系統(tǒng)版本和架構(gòu)。安裝前還要留意內(nèi)核參數(shù)。部分?jǐn)?shù)據(jù)庫安裝過程會修改系統(tǒng)參數(shù)比如文件句柄數(shù)、共享內(nèi)存上限、線程棧大小。先備份原始 sysctl 配置安裝完再對比差異這是很值得做的準(zhǔn)備工作。2.2 系統(tǒng)版本、內(nèi)存、磁盤檢查在服務(wù)器上執(zhí)行下面四行命令先把環(huán)境底數(shù)摸清楚。這四行看起來基礎(chǔ)但能過濾掉一半以上的安裝問題。cat /etc/os-release uname -m free -g df -h /opt第一行打印系統(tǒng)發(fā)行版信息確認(rèn)當(dāng)前系統(tǒng)版本是不是和包名對應(yīng)重點看 VERSION_ID 是否匹配 20 SP8第二行查看 CPU 架構(gòu)確認(rèn)是 x86_64 還是 aarch64第三行顯示內(nèi)存總量我一般要求物理內(nèi)存不低于 2GB否則初始化階段很容易觸發(fā)系統(tǒng) OOM第四行看 /opt 分區(qū)的可用空間數(shù)據(jù)庫安裝目錄、數(shù)據(jù)目錄、日志都放這里低于 10GB 建議先擴容。這里有個容易被忽略的細(xì)節(jié)free -g 看到的是主機內(nèi)存總量但如果你在容器里部署實際可用內(nèi)存要看 cgroup 限制。我見過有人在 2GB 內(nèi)存的容器里裝數(shù)據(jù)庫free 顯示正常初始化還是被系統(tǒng)殺掉就是因為沒注意 cgroup 的配額。另外磁盤空間不能只看 /opt 一個點日志目錄如果單獨掛載也要一起檢查 df -h 的輸出。除了容量還要看文件系統(tǒng)類型。數(shù)據(jù)庫數(shù)據(jù)目錄放在 XFS 或 ext4 上問題不大但如果文件系統(tǒng)不支持某些 POSIX 語義初始化時可能出現(xiàn)奇怪的 I/O 錯誤。檢查方式很簡單df -T /opt 看文件系統(tǒng)類型。數(shù)據(jù)庫這種對 I/O 敏感的程序盡量別放在共享存儲或網(wǎng)絡(luò)文件系統(tǒng)上本地盤最穩(wěn)妥。2.3 創(chuàng)建專用用戶與解壓安裝包安裝數(shù)據(jù)庫有一條老規(guī)矩不要用 root 跑安裝和初始化。用 root 操作會帶來文件權(quán)限隱患數(shù)據(jù)文件一旦被 root 屬主占用后續(xù)切到普通用戶啟動必然報權(quán)限錯誤。這里我習(xí)慣建一個專用賬號比如 gauss把整個安裝目錄交給這個用戶。groupadd gauss useradd -g gauss -m -s /bin/bash gauss mkdir -p /opt/gaussdb tar -zxvf GaussDB_100_1.0.1-DATABASE-EULER20SP8-64bit.tar.gz -C /opt/gaussdb chown -R gauss:gauss /opt/gaussdb命令的執(zhí)行順序是有講究的。先建用戶組和用戶再建安裝目錄和解壓最后統(tǒng)一改屬主這樣能避免解壓過程中文件權(quán)限參差不齊。解壓前我通常用 sha256sum 校驗一下壓縮包完整性傳輸過程中包被截斷的情況不少見而且解壓時不一定報錯很可能一直等到啟動階段才暴露出二進制文件損壞。sha256sum GaussDB_100_1.0.1-DATABASE-EULER20SP8-64bit.tar.gz輸出的一長串哈希值跟下載頁提供的官方哈希做對比。不一致就重新下載別勉強使用。校驗這步和前面的環(huán)境檢查一樣是數(shù)據(jù)庫部署里穩(wěn)賺不賠的動作。另一個常見錯誤是先把 tar 包解壓到家目錄再手動搬運到 /opt搬運過程中容易把可執(zhí)行權(quán)限弄丟后面執(zhí)行安裝腳本時會報 Permission denied非常冤枉。2.4 安裝腳本的常見參數(shù)與日志位置進入解壓目錄后先別急著雙擊運行安裝文件先看包內(nèi)說明或腳本幫助確認(rèn)這個版本支持的參數(shù)。不同小版本的安裝腳本參數(shù)有差異網(wǎng)上教程五花八門直接照抄別人的命令很容易踩到參數(shù)不存在的坑。su - gauss cd /opt/gaussdb ls -l ./install.sh --help切換到 gauss 用戶后進入解壓目錄ls -l 看目錄內(nèi)容然后執(zhí)行 install.sh --help 查看參數(shù)。幫助信息里一般會列出數(shù)據(jù)目錄、端口、字符集、日志路徑等選項。不同版本的參數(shù)寫法可能不同但核心幾項是通用的。安裝腳本執(zhí)行過程中會實時打印日志同時把完整日志寫入安裝目錄下的 log 子目錄報錯時第一反應(yīng)應(yīng)該是翻日志而不是反復(fù)重跑腳本。安裝完成之后有些版本會自動完成實例初始化有些只把目錄鋪好初始化需要額外執(zhí)行。這個階段不要只盯著腳本輸出要確認(rèn)最后幾行有沒有提示后續(xù)步驟。如果腳本提示沒有自動初始化就按下一章的步驟手動執(zhí)行初始化。數(shù)據(jù)庫安裝結(jié)束不意味著立即就能用必須走到初始化并啟動實例成功才算真正交付。另外一個值得養(yǎng)成的習(xí)慣記錄安裝時間、安裝用戶、安裝路徑、版本號哪怕簡單寫在一個部署筆記里。后面升級或故障排查時這些信息能省下大量時間?？雌饋矶啻艘慌e實際用起來很香。3. 初始化和核心配置數(shù)據(jù)目錄、端口和內(nèi)存的合理設(shè)置3.1 初始化實例時到底發(fā)生了什么安裝腳本跑完之后數(shù)據(jù)庫可能還只是一個空殼數(shù)據(jù)目錄里沒有系統(tǒng)表空間和日志。GaussDB 100 的初始化過程本質(zhì)上是往數(shù)據(jù)目錄里寫入一套數(shù)據(jù)庫賴以啟動的元數(shù)據(jù)系統(tǒng)表、參數(shù)文件、控制文件、undo 日志和 redo 日志。有了這些文件實例才具備被啟動的基礎(chǔ)。初始化命令在不同版本里寫法不完全一樣但核心參數(shù)大同小異。常見做法是通過管理工具或腳本指定數(shù)據(jù)目錄路徑下面這條命令是這類工具的典型寫法cd /opt/gaussdb/bin python zctl.py -t init -D /opt/gaussdb/datazctl.py 是 GaussDB 100 常用的管理腳本-t 參數(shù)指定操作類型init 表示初始化-D 后跟數(shù)據(jù)目錄。初始化過程會打印許多內(nèi)部信息重點是結(jié)尾幾行實例 ID、數(shù)據(jù)目錄、初始化耗時。如果看到成功提示說明這一步通過了。假如中途中斷先檢查數(shù)據(jù)目錄的屬主再看磁盤空間。初始化階段特別需要注意的是字符集一經(jīng)生成后期基本改不了。有些版本只允許在初始化時通過參數(shù)指定字符集初始化完成后想再改成 UTF8唯一的辦法是重建實例。所以這一步值得反復(fù)確認(rèn)寧可多花兩分鐘檢查參數(shù)也不要上線后做無謂的重建。這里還要注意數(shù)據(jù)目錄的路徑選擇。很多人習(xí)慣把數(shù)據(jù)目錄放在安裝目錄下比如 /opt/gaussdb/data這樣管理起來順手但假如安裝盤和數(shù)據(jù)盤是同一個分區(qū)日志和數(shù)據(jù)一起增長磁盤很容易滿。有條件的話數(shù)據(jù)目錄單獨掛一塊盤路徑也不要帶空格或中文避免工具解析出錯。提示初始化之前先確認(rèn)數(shù)據(jù)目錄為空或不存在。初始化工具不會主動清空已有目錄如果目錄里有殘留文件可能導(dǎo)致初始化失敗或元數(shù)據(jù)混亂。3.2 核心配置參數(shù)端口、緩沖區(qū)和字符集初始化完成后最重要的配置文件在數(shù)據(jù)目錄下。常見做法是打開配置文件逐項確認(rèn)監(jiān)聽端口、緩沖區(qū)大小和字符集。下面這個表格適應(yīng)大多數(shù)部署場景具體參數(shù)名以實際版本為準(zhǔn)。配置項建議值說明PORT1888數(shù)據(jù)庫監(jiān)聽端口客戶端連接的入口BUFFER_SIZE1G數(shù)據(jù)緩沖區(qū)緩存熱點表數(shù)據(jù)影響查詢性能LOG_BUFFER_SIZE64M日志緩沖區(qū)影響寫入吞吐CHARACTER_SETUTF8字符集涉及中文等非英文字符存儲MAX_SESSIONS1000最大會話數(shù)按業(yè)務(wù)規(guī)模調(diào)整配置里的 BUFFER_SIZE 不是越大越好。這個值要結(jié)合服務(wù)器內(nèi)存總量和業(yè)務(wù)并發(fā)情況來定。內(nèi)存緊張的機器上1G 的緩沖區(qū)配合合理的索引設(shè)計也能撐起不小的業(yè)務(wù)量內(nèi)存富余時調(diào)到 2G 甚至更高對讀密集場景的提升明顯。但要注意亂調(diào)大緩沖區(qū)可能導(dǎo)致啟動時內(nèi)存不足實例起不來。字符集這一項必須在初始化階段就確認(rèn)好。上線之后改字符集基本等于重新部署這是數(shù)據(jù)庫初始化里最昂貴的一次錯誤。日志參數(shù)的調(diào)整同樣需要權(quán)衡對高寫入場景日志緩沖區(qū)太小會導(dǎo)致頻繁刷盤事務(wù)提交延遲明顯調(diào)大后寫入性能有改善代價是異常斷電時恢復(fù)時間變長要根據(jù)業(yè)務(wù)能接受的恢復(fù)時間來決定。修改完配置后重啟實例讓新參數(shù)生效python zctl.py -t restart -D /opt/gaussdb/datazctl.py 的 -t restart 會先停掉當(dāng)前運行的實例再讀取新配置啟動。重啟后建議立刻檢查進程和監(jiān)聽狀態(tài)確認(rèn)實例沒有掉進“啟動失敗但進程還在”的中間狀態(tài)。用 ss -tlnp | grep 1888 或 netstat -tlnp | grep 1888 確認(rèn)端口在監(jiān)聽這一步很重要不能省。3.3 理解數(shù)據(jù)目錄與日志文件類型運行一段時間后數(shù)據(jù)目錄不再是孤零零一個數(shù)據(jù)文件。里面會有系統(tǒng)表空間、用戶表空間、undo 日志、redo 日志和控制文件?？刂莆募喈?dāng)于數(shù)據(jù)庫的儀表盤記錄實例狀態(tài)和數(shù)據(jù)文件路徑啟動時最先讀取一旦損壞實例基本無法啟動。運行日志一般在安裝目錄的 log 子目錄下按日期或大小滾動。建議把日志目錄放在獨立分區(qū)或單獨掛載一塊磁盤避免數(shù)據(jù)庫運行日志把系統(tǒng)盤寫滿。我見過最典型的事故就是日志增長太快把根分區(qū)寫滿數(shù)據(jù)庫直接進入只讀模式業(yè)務(wù)全部受影響。日志單個文件的大小也值得關(guān)注。太小會頻繁切換影響性能太大則排錯不方便。比較穩(wěn)妥的策略是單個日志文件控制在 256MB 左右保留最近 7 天配合定時清理任務(wù)。寫入量大的業(yè)務(wù)日志增長可能超出預(yù)期定期檢查日志目錄大小是不可少的運維習(xí)慣。另一個容易被忽視的點不要把備份文件放到數(shù)據(jù)目錄所在分區(qū)。很多人備份時圖方便把備份集放在 /opt/gaussdb 下面一旦磁盤損壞備份和數(shù)據(jù)一起沒了等于白備。備份文件要放到獨立的備份盤或遠(yuǎn)程存儲上。3.4 修改配置后的驗證與回滾數(shù)據(jù)庫配置不是一次就能調(diào)對的。第一次調(diào)參失敗也很常見這是正常的試錯過程。我的習(xí)慣是每次修改配置前先備份原始配置文件用一條命令快速復(fù)制一份?；貪L時直接用原文件覆蓋重啟實例幾秒就能回到調(diào)參前的狀態(tài)這就是后悔藥。cp /opt/gaussdb/data/config /opt/gaussdb/data/config.bak.$(date %Y%m%d)這條命令把當(dāng)前配置文件備份成帶日期的副本。修改配置之前執(zhí)行一次后面調(diào)崩了就可以一鍵還原。配合前面的重啟命令整個調(diào)參鏈路就完整了備份、修改、重啟、觀察、確認(rèn)必要時回滾。這對新手尤其重要。數(shù)據(jù)庫調(diào)參不是玄學(xué)但不同業(yè)務(wù)負(fù)載對參數(shù)的敏感度不一樣試錯是常態(tài)。留下回滾路徑試錯的成本就低很多。4. 常見問題與避坑安裝啟動中最容易翻車的五個點4.1 初始化報缺少庫文件進程直接退出現(xiàn)象初始化工具執(zhí)行到一半提示某個動態(tài)庫無法加載終端報錯信息指向 .so 文件進程隨即退出。原因多數(shù)情況是系統(tǒng)版本與安裝包要求不一致底層基礎(chǔ)運行庫版本對不上少數(shù)情況是關(guān)鍵依賴未安裝。解決先確認(rèn)系統(tǒng)版本再根據(jù)報錯中的庫名檢查依賴。通過 ldd 可以快速列出可執(zhí)行文件的動態(tài)庫依賴找出 not found 的庫然后安裝對應(yīng)的依賴包。ldd /opt/gaussdb/bin/zctl.py對 zctl.py 執(zhí)行 ldd 時如果輸出里出現(xiàn) not found說明依賴缺失裝好對應(yīng)組件再重試初始化。這一步也驗證了前面說的版本不匹配的包真的不能硬上硬上的后果就是在這里卡住。4.2 內(nèi)存不足導(dǎo)致初始化進程被系統(tǒng)殺掉現(xiàn)象初始化過程中終端提示 Killed或者實例啟動后幾秒就退出日志里沒有明顯數(shù)據(jù)庫錯誤。原因服務(wù)器可用內(nèi)存低于數(shù)據(jù)庫初始化所需的最低值數(shù)據(jù)庫把配置的內(nèi)存映射到共享內(nèi)存時申請被系統(tǒng)拒絕。在容器環(huán)境里cgroup 限制也會導(dǎo)致類似問題。解決先查內(nèi)存總量和共享內(nèi)存限制再決定降配置還是加資源。free -m sysctl -a | grep shm如果物理內(nèi)存只有 1GB建議把緩沖區(qū)配置調(diào)到 512MB 以下或直接加內(nèi)存。共享內(nèi)存相關(guān)的內(nèi)核參數(shù) shmmax 和 shmall 太小也會導(dǎo)致啟動失敗按需調(diào)大即可。容器環(huán)境要檢查 cgroup 的內(nèi)存限制不要只看 free 的輸出。4.3 端口被占用實例反復(fù)重啟現(xiàn)象啟動后日志提示 bind 失敗實例進程反復(fù)拉起又退出。原因端口被其他服務(wù)占用或者前一次異常退出殘留的 socket 沒有清理。解決用 netstat 或 ss 查看端口占用情況找到占用進程再決定改端口還是停進程。ss -tlnp | grep 1888如果確實被占用我一般優(yōu)先改數(shù)據(jù)庫端口因為讓業(yè)務(wù)改連接串的成本比停掉一個正在運行的服務(wù)低。如果端口沒被進程占用但依然報 bind 失敗那多半是殘留 socket 文件刪除對應(yīng)文件后重啟即可。4.4 中文寫入亂碼客戶端連接異常現(xiàn)象通過客戶端插入中文后查詢顯示問號或客戶端工具直接報字符集不支持。原因數(shù)據(jù)庫初始化時的字符集不是 UTF8或者客戶端環(huán)境變量與數(shù)據(jù)庫字符集不一致。解決初始化時指定 UTF8 是最省事的方式。連接前設(shè)置客戶端字符集環(huán)境變量確保兩端一致。export NLS_LANGUTF8這個環(huán)境變量在部分版本的客戶端工具里不叫這個名字具體以工具文檔為準(zhǔn)。關(guān)鍵是理解字符集匹配是雙向的數(shù)據(jù)庫一端和客戶端一端必須一致。初始化已完成又不想重建的情況下只能從客戶端環(huán)境變量和連接參數(shù)上找補救效果有限所以字符集這件事一定要在初始化階段一錘定音。4.5 日志文件把數(shù)據(jù)分區(qū)寫滿現(xiàn)象運行一段時間后實例進入只讀模式應(yīng)用開始報空間不足。原因日志沒有配置輪轉(zhuǎn)策略或者數(shù)據(jù)增長超出預(yù)估分區(qū)被寫滿。解決先檢查日志目錄和表空間使用率確認(rèn)問題出處然后清理過期日志。df -h /opt find /opt/gaussdb/log -type f -mtime 7 -exec rm {} \;第一條命令看分區(qū)使用率第二條清理 7 天前的日志文件。但這只是治標(biāo)真正要做的還是在配置里啟用日志輪轉(zhuǎn)按天切割、保留指定天數(shù)。日志和數(shù)據(jù)文件不要放同一分區(qū)物理隔離能避免日志問題拖垮實例。如果數(shù)據(jù)增長是常態(tài)擴容分區(qū)或調(diào)整表空間數(shù)據(jù)文件大小才是長久之計。5. 驗證與進階把啟停檢查和備份恢復(fù)變成肌肉記憶5.1 第一次啟動后做一次全鏈路驗證初始化配置完成、實例啟動之后不能只看進程在就跑。正確做法是登錄客戶端工具建一張臨時表插入幾行數(shù)據(jù)再查出來。這一套操作能在五分鐘內(nèi)發(fā)現(xiàn)連接、字符集、權(quán)限、表空間是否正常。CREATE TABLE t_check (id INT PRIMARY KEY, name VARCHAR(64)); INSERT INTO t_check VALUES (1, GaussDB); SELECT * FROM t_check;第一句建表如果這里報錯問題通常集中在表空間和權(quán)限第二句插入失敗九成是字符集問題第三句查詢能返回剛才插入的數(shù)據(jù)說明讀寫鏈路通暢。這個驗證腳本我每裝完一套實例都會執(zhí)行一遍能過濾掉絕大多數(shù)潛在問題。5.2 備份恢復(fù)的幾個基本動作備份這事GaussDB 100 有物理備份和邏輯導(dǎo)出兩條路。物理備份針對數(shù)據(jù)目錄做整庫快照適合故障后整機恢復(fù)但只能在相同版本的庫上恢復(fù)。邏輯導(dǎo)出更靈活可以只導(dǎo)出一張表或一個 schema恢復(fù)時指定導(dǎo)入目標(biāo)庫即可。python zctl.py -t backup -D /opt/gaussdb/data -b /opt/backup執(zhí)行備份命令時備份文件不要放在數(shù)據(jù)目錄所在分區(qū)——這一點很多人會忽略真遇到磁盤故障時備份和數(shù)據(jù)一起沒了等于白備?；謴?fù)時也要注意先停實例再恢復(fù)文件不要熱替換運行中的文件。從那以后我每次裝完 GaussDB 100不論多趕都會強制走一遍完整的驗證鏈路確認(rèn)連接、SQL 執(zhí)行、備份目錄存在且可寫全部確認(rèn)完才會把實例交給業(yè)務(wù)方。這不是一套 SQL 的事而是建立一種對交付環(huán)境的把握感。數(shù)據(jù)庫這種基礎(chǔ)設(shè)施提前暴露問題的成本永遠(yuǎn)比上線后補救低。希望幫到你。本文還有配套的精品資源點擊獲取