OceanBase 2.2 安裝部署問題解答
OceanBase 2.2 自官網提供試用下載下傳後，受到不少資料庫愛好者的關注，很多朋友都下載下傳嘗試安裝，有些成功了，有些碰到了一些問題。本文就是總結一下最近大家遇到的問題，以供後來的朋友試用參考。
關于安裝部署的疑問
關于OceanBase的安裝方法的文章可能有多種，這裡解釋一下。
在今年1月份之前官網提供的是OceanBase 1.4版本的相關檔案，裡面也包含了 OCP 1.x版本及其安裝方法。那個版本的OCP安裝可能會因為機器環境問題、資源問題而失敗。是以我基于那個版本寫了一篇文章《
OceanBase資料庫實踐入門——手動搭建OceanBase叢集》。繞開OCP直接手動安裝OceanBase叢集。1.4版本的OB相容MySQL，具備OB大部分的核心能力(高可用、強一緻、水準拆分、可擴充等)，最重要的一點是對機器記憶體資源要求比較低，每個節點機器16G記憶體就可以搭建成功。
機器資源問題是大部分網友試用OB的最大障礙，在2.2版本釋出後這點尤為明顯。官網提供的2.2的相關檔案是按照POC環境或者生産環境要求，無論是OCP還是OB，機器至少要求是128G記憶體才能順利跑成功。如果繞過OCP直接手動部署OB，至少每個節點64G記憶體才可以順利部署。手動部署需要初始化機器、修改一些參數，詳情參見《
OceanBase 2.x體驗：手動搭建OceanBase叢集》。
OceanBase叢集通常至少有三個節點，不過如果是學習研究，也可以搭建一個單副本的OB叢集。單副本的OB叢集除了沒有高可用能力外，水準拆分、可擴充、強一緻等能力還是有的。具體安裝方法請參見《
OceanBase 2.x體驗：搭建OceanBase單副本叢集》。細心的朋友可能會說單副本怎麼也叫叢集。單副本OB叢集可以是一台機器，也可以是2台、3台。因為單副本OB也是可以加機器進行擴容的(所有機器都是同一個Zone)。有興趣的朋友可以試試。搭建單副本OB叢集好處就是不需要那麼多的測試機器。不過官網的安裝方法先搭建OCP，OCP再搭建OB叢集，這個OB叢集不支援單副本，要求是三副本或五副本。針對官網的安裝方法執行過程請參見《
OceanBase 2.x 試用版安裝體驗——OCP 2.3有不少朋友在機器資源不滿足需求的情況下還堅持按官網方法搭建OCP和部署OB，基本上都遇到不少問題。這些問題都是可解的，需要調整一些腳本。本文後面會介紹幾個技巧，供有興趣鑽研OCP的朋友參考。 實際上除了OB 2.2外，OCP也是這次下載下傳檔案裡最有價值的東西。
最後還有個好消息，OceanBase團隊預計在4月初會釋出OceanBase的迷你版，基于Docker部署，一個指令啟動Docker鏡像OB就可以直接用了。敬請期待。
關于機器問題的總結
一直以來，絕大部分OB叢集初始化不成功都跟機器環境有關。關于機器初始化可以使用官網下載下傳的檔案裡初始化腳本，具體請參考《
》中的章節 “3. 機器初始化”。
常見的問題有下面這幾種
- 時間不同步問題
通常隻要把OCP、OB的機器都配置為同一個時間同步伺服器即可。不過可能有些朋友沒有NTP伺服器，有些是NTP不穩定或者配置方法問題，有些就是時間不同步原因不明。關于NTP的原理、診斷技巧我沒有研究。這裡就提供一個能直接解決問題的辦法。在每個機器的root使用者的
crontab
裡配置任務每分鐘更新一次 NTP的時間，用
ntpdate
指令。
- 目錄布局不對問題
官網提供的初始化腳本裡，會自動初始化出目錄
/home
(可選)、
/docker
(隻有OCP用)、
/data/1
、
/data/log1
。如果客戶機器是多盤，建議2個盤做RAID1給作業系統用，其他的盤可以做RAID(建議RAID 5)，也可以不做RAID。可以輸出一個大的實體盤，也可以輸出多個盤。這樣自動初始化腳本會用
LVM
技術重新生成4個獨立的邏輯卷并做檔案系統。這是最好的情形。實際情形通常是隻有一塊盤，還跟作業系統共用。這時候就不能使用自動初始化腳本了。隻能人為建立4個目錄，使用一些軟連結技術。
标準的檔案系統輸出如下。如果不标準，就用軟連結技術做到。
如果是手動部署OB叢集，還需要做初始化OB叢集相關目錄 。 (通過OCP部署OB的不需要執行下面步驟)。
su - admin
mkdir -p /data/1/obdemo/{etc3,sort_dir,sstable}
mkdir -p /data/log1/obdemo/{clog,etc2,ilog,slog,oob_clog}
mkdir -p /home/admin/oceanbase/store/obdemo
for t in {etc3,sort_dir,sstable};do ln -s /data/1/obdemo/$t /home/admin/oceanbase/store/obdemo/$t; done
for t in {clog,etc2,ilog,slog,oob_clog};do ln -s /data/log1/obdemo/$t /home/admin/oceanbase/store/obdemo/$t; done 這個其實就把OB的目錄結構都展示出來，文章裡我我遺漏了檢查步驟，一般隻有目錄結構如下才是正确的：
tree /home/admin/oceanbase/store/
tree /data/ 
有些朋友的問題因為反複重試後，目錄就跟上面不一樣了，其原因是每次失敗重試時，沒有執行下面清理步驟
su - admin
kill -9 `pidof observer`
sleep 3
/bin/rm -rf /data/1/obdemo/
/bin/rm -rf /data/log1/obdemo/
/bin/rm -rf /home/admin/oceanbase/store/obdemo /home/admin/oceanbase/log/* /home/admin/oceanbase/etc/*config*
ps -ef|grep observer
df -h |egrep home\|data 最後切記，所有操作是在使用者
admin
下。相關目錄的
owner
設定為
admin
。如果在
root
使用者下啟動過
observer
程序失敗後，目錄檔案權限可能會被改為
root
了。
- 空間不足問題
OB以及相關軟體的都是運作在
admin
使用者下，其運作日志都在
/home/admin
目錄下。日志的預設級别是
INFO
，是以日志會增長很快，尤其是
OBServer
程序的日志。要避免這個就要調整
observer
和
obproxy
程序的日志級别為
WARN
或
ERROR
。這個手動部署文章裡有介紹。通常除了給OB開發人員查問題外，
INFO
日志對普通使用者用處不大。
第二，
/data/log1
會要求可用空間占檔案系統總空間比例不少于
5%
，否則
OBServer
程序看事務日志空間要滿了就自我保護，拒絕就日志落盤進行表決了。這個會引起OB叢集異常。要規避這個就要在前期目錄規劃的時候盡量讓
/data/1
/data/log1
使用不同的實體盤或者邏輯盤。如果實在要在一起，隻能是限制
/data/1
目錄的空間。在手動部署OB叢集時，啟動
observer
程序中有個參數
datasize=100G
就是起這個作用的。如果沒有這個參數，預設情況下，
observer
程序會把
/data/1
所在卷的90%空間都占去(方法是直接生成一個大檔案
sstable
)。此外
/data/log1
空間大小通常建議為OB記憶體的2-4倍。
- 記憶體不足問題
observer
程序啟動時除了會占去大部分空間，還會占去大部分記憶體(總記憶體的
80%
，由參數
memory_limit_percentage
memory_limit
控制)。是以
observer
程序不适合跟其他軟體共用主機。占去之後OB内部還會預設配置設定30G記憶體用于内部邏輯(由參數
system_memory
控制)。然後内部會很多不同任務初始化一些數目的線程，也需要不少記憶體(OceanBase叢集的設計就是奔着生産環境的資源做的，初始化線程有點多。後面即将釋出的迷你版本會優化這個設計，節省很多記憶體需求)。
是以，一個64G的主機，如果用預設參數啟動2.2的
observer
程序，也是起不來的，需要降低參數
system_memory
的值。這個值也不是随便改，需要多輪測試。我測試最小是10G。
有些朋友從OCP的任務日志裡看出還有些其他記憶體參數，可以嘗試看看，目前我測試看不是必要的。
最後總結一下，不管是實體機還是虛拟機，運作OB的關鍵是資源。如果記憶體低于測試的最低要求，安裝失敗的機率是很高的。
關于OCP的價值
OCP是OB的自動化運維平台，是一個PaaS平台，或者跟雲計算搭點關系叫
雲平台
。實際上所有雲資料庫都有個自動化運維平台，其功能架構設計大同小異。是以OCP除了能降低運維人員使用OB的門檻，還為運維開發人員提供了一個現成的
資料庫雲平台
例子。
同樣，OCP的部署使用的是腳本，結合
docker
技術。所有的腳本都是
shell
開發，也是一個活生生的例子。在腳本裡也能看出機器初始化的細節。檢視OB Docker容器的初始化步驟還能看出安裝和初始化一個OB叢集的詳細過程。
OCP是java開發的，隻能看到類檔案。不過OCP裡自動化運維任務都有詳細的日志。通過研究這些任務設計，以及任務日志，也可以學習到一些PaaS平台的架構設計經驗，以及學習到OB叢集每個任務操作的細節步驟。
自動化運維平台做的事情，是把運維人員的重複性的工作标準化、流程化以及并行化執行，規避了運維人員人為錯誤、人力不足問題。早期對自動化運維産品也有個總結，有興趣的朋友可以參見《
自動化運維産品的命門——中繼資料庫關于OCP失敗任務問題的總結
有關OCP的部署和使用，請先檢視我在雲栖社群的直播：
OB叢集運維常見任務有：
- 新增 OB機器/OBProxy機器/備份機器/恢複機器。
- 新增 RPM包
- 叢集 建立/擴容/重新開機/更新/備份/恢複
- 租戶 建立/擴容
OCP把運維上的操作設計為一個任務，然後任務又細分為很多原子任務。大部分原子任務如果失敗了，支援下面三種操作：
- 重試，重新執行本原子任務。設計上每個原子任務應該支援幂等(可重入)。
- 跳過，放棄本原子任務繼續執行下一個原子任務，可能引起不一緻的狀态或資料。通常會選擇手動做完本子任務的事情，在OCP裡放棄。如打通機器SSH信任關系。不是所有的原子任務都支援跳過操作(即點選無效)。
- 放棄，放棄本原子任務以及後面所有的任務。不會撤銷已執行的原子任務的修改，是以多半會留下不一緻的資料或狀态。
每個任務都有日志在頁面上展示。不過當任務反複執行時，日志量很大，檢視很不友善。可以直接登入OCP容器檢視。方法如下：
登入OCP容器檢視任務日志
- 檢視OCP失敗任務
從這個圖裡能看出失敗的子任務的時間、執行機器、子任務ID等。
- 登入相應的OCP容器。
docker ps
docker exec -it ocp bash - 切換到
admin
/home/admin/logs/task
根據OCP頁面上任務的時間，進入相應的檔案夾，根據子任務ID查找檔案
檢視上面的
*.err
檔案既可以看到詳細的日志。
修改OCP腳本的方法
如果用OCP安裝部署OB叢集，任務正确執行的前提是機器是滿足資源需求，并标準化安裝的。如果機器記憶體隻有64G，通過OCP部署OB叢集一定會報錯。
此時如果要繼續下去就需要修改子任務執行的腳本。OCP的任務日志裡可以看到報錯時所在的腳本檔案名稱以及報錯行。直接進入OCP容器，編輯檔案，調整相關記憶體參數。
比如說調低
observer
程序的啟動參數。
- 在OCP裡找到叢集初始化步驟。
通常是第11個子任務 ：
11 at_bootstrap_observer
，檢視其日志，找到
bin/observer
啟動的指令行
從日志中找到 目前子任務執行的腳本檔案名字
ob_operate_plus
- 進入 OCP容器檢視檔案
[root@xxxxx ~]# su - admin
Last login: 五 3月 13 17:29:17 CST 2020
[admin@xxxxx ~]$ cd /home/admin/obztools
[admin@xxxxx obztools]$ find | grep ob_operate_plus
./src/task/obauto_plus/ob_operate_plus.py
./src/task/obauto_plus/ob_operate_plus.pyc - 編輯檔案
編輯
./src/task/obauto_plus/ob_operate_plus.py
， 搜尋
/bin/observer
。在适當的位置加入參數
system_memory=10G
，注意要跟已有參數用分隔符分隔。
OB叢集安裝成功後做什麼
OB叢集安裝好後，第一個問題就是怎麼連接配接。OceanBase叢集支援多租戶(多執行個體)，開發連接配接的時候實際上是連接配接到叢集裡某個執行個體。預設執行個體叫
sys
，相容MySQL，可以用
mysql
用戶端連接配接。或者用OB自己的用戶端
obclient
連接配接。OB 2.2版本新增對ORACLE相容性，連接配接ORACLE執行個體隻能用
obclient
用戶端。或者使用任意一款依賴java開發的通用資料庫用戶端，比如說
DBeaver
，詳情可以參見《
OceanBase 2.x體驗：推薦用DBeaver工具連接配接資料庫連接配接上資料庫後，可以跑一些OB示例資料庫，這裡為MySQL執行個體和ORACLE執行個體分别準備了一個
tpcc
業務場景的資料庫初始化腳本。詳情可以參見《
OceanBase 2.x 體驗：示例資料庫》。如果OB機器記憶體大于128G，可以對OB做一些性能測試，用
sysbench
(隻支援MySQL執行個體) 或者
BenchmarkSQL
(支援MySQL執行個體和ORACLE執行個體)，後者使用詳情請參見《
OceanBase 2.x體驗：用BenchmarkSQL跑TPC-C如果想把ORACLE或MySQL的資料遷移到OceanBase上來，可以參考《
從ORACLE/MySQL到OceanBase：資料導出&導入