我眼中的 openGauss 數(shù)據(jù)庫十大尬點

本文出處：https://www.modb.pro/db/545567

寫過幾篇標題帶"十大"關鍵字的文章，閱讀量較高，比如昨天這篇PG 數(shù)據(jù)庫十大經(jīng)典案例解說瀏覽量接近一千，于是本文以"十大尬點"作為關鍵字吐槽一下 openGauss。

吐槽有兩方面的原因，首先是為了留念本人之前處理和分析問題的過程，其次也是為了讓大家更好的使用 openGauss，就如小時候我老爸揍我一樣，那也是滿滿的愛。

一、剪不斷的 SSL 依賴

本以為 pg_hba.conf 不使用 SSL 認證就可以不依賴它，后來發(fā)現(xiàn)內(nèi)部工具也有依賴，是我想簡單了。

二、嬌氣的 OM 工具

初次安裝 openGauss 時容易遇到 OM 工具相關的問題，比如 XML 文件格式配置問題，python3 小版本等問題，最后經(jīng)過 preInstall 和 Install 兩大高手的挑戰(zhàn)之后能感受到超級瑪麗通關的體驗。

三、過度的安全機制

首次接觸 1.0 版本，安裝數(shù)據(jù)庫時沒有設置初始用戶的密碼，發(fā)現(xiàn) gsql 登錄之后無法做任何操作，因為必須要修改初始用戶的密碼。

但這確實有點尷尬，或許應該仔細先看看文檔，就明白系統(tǒng)預設了一個軒轅代號。

postgres:# ALTER ROLE omm IDENTIFIED BY 'XXXX' REPLACE 'XuanYuan@2012';

該問題很快就得到了完善，不過在 2.0 時也遇到了新的挑戰(zhàn)，管理用戶不能幫普通用戶重置密碼，必須知道普通用戶的原密碼才能進行修改，后面的版本也快速優(yōu)化了這個問題。

四、不可大意的啟動模式

使用 gs_ctl 啟動服務時在單機場景下不需要關注啟動模式，主備環(huán)境下需要注意區(qū)分。

啟動主庫：

$ gs_ctl start -D data -M primary

啟動備庫：

$ gs_ctl start -D data -M standby

主庫和備庫需要以各自的模式啟動，如果備庫我們忘記了使用啟動模式，除了主備關系會失敗之外，也無法簡單地通過關閉服務來重新操作，只能使用 build 操作來重建備庫。

因此主備環(huán)境下啟動備庫一定要注意使用 standby 模式啟動，切記！

五、public 模式的硬依賴

不可否認 openGauss 對 public 模式增強了安全性，但我們不能強制刪除它，不然備份恢復等場景會遇到一些小麻煩。

六、內(nèi)卷的模板庫

PG 里默認模板庫是 template1，openGauss 里輪換到了 template0。

openGauss# create database mydb template template1;ERROR: ?template1 is not supported for using here, just support template0

七、步調(diào)不一致的 LSN

主備環(huán)境查詢 xlog 接收 LSN 不同階段的兩個函數(shù)返回類型不一致，如果有相關計算，不能運算，需要做一下轉換處理。

八、當自定義表空間遇上外部參數(shù)配置

在做增量備份時，自定義表空間 tablespace-mapping 與外部參數(shù)配置 external-mapping 遇上之后會產(chǎn)生什么化學反應呢？對比測試請參考：pg_probackup 包含新建表空間的備份及恢復

九、被吞噬的 0x00

遇到一個從 MySQL 數(shù)據(jù)庫遷移過來的應用程序解壓數(shù)據(jù)不一致，最終發(fā)現(xiàn) openGauss 吞掉了零字節(jié)，案例參考：openGauss/MogDB 零字節(jié)問題處理

十、元數(shù)據(jù)版本不碰撞

PG 里通過 catalog_version_no 進行系統(tǒng)元數(shù)據(jù)碰撞，檢測數(shù)據(jù)庫的二進制與初始化的 PGDATA 是否匹配來避免可能隱藏的不兼容性問題。openGauss 目前不管是低啟高，還是高啟低都不會 BUMP。