「OceanBase 4.1 体验」｜快速安装部署
文章目錄
- 一、Oceanbase數據庫簡介
- 1.1 核心特性
- 1.2 系統架構
- 1.2.1 存儲層
- 1.2.2 復制層
- 1.2.3 均衡層
- 1.2.4 事務層
- 1.2.4.1 原子性
- 1.2.4.2 隔離性
- 1.2.5 SQL 層
- 1.2.5.1 SQL 層組件
- 1.2.5.2 多種計劃
- 1.2.6 接入層
- 二、OceanBase 數據庫社區版部署
- 2.1 部署方式
- 2.2 基礎環境配置
- 2.3 通過 OBD 白屏部署 OceanBase 集群(小集群單一管理)
- 2.4 通過 OCP 白屏部署 OceanBase 集群（多集群統一管理）
- 三、總結
一、Oceanbase數據庫簡介
??OceanBase 數據庫是一款完全自研的企業級原生分布式數據庫，在普通硬件上實現金融級高可用，首創“三地五中心”城市級故障自動無損容災新標準，刷新 TPC-C 標準測試，單集群規模超過 1500 節點，具有云原生、強一致性、高度兼容 Oracle/MySQL 等特性。
1.1 核心特性
-
高可用
獨創 “三地五中心” 容災架構方案，建立金融行業無損容災新標準。支持同城/異地容災，可實現多地多活，滿足金融行業 6 級容災標準（RPO=0，RTO< 8s），數據零丟失。 -
高兼容
高度兼容 Oracle 和 MySQL，覆蓋絕大多數常見功能，支持過程語言、觸發器等高級特性，提供自動遷移工具，支持遷移評估和反向同步以保障數據遷移安全，可支撐金融、政府、運營商等關鍵行業核心場景替代。 -
水平擴展
實現透明水平擴展，支持業務快速的擴容縮容，同時通過準內存處理架構實現高性能。支持集群節點超過數千個，單集群最大數據量超過 3PB，最大單表行數達萬億級。 -
低成本
基于 LSM-Tree 的高壓縮引擎，存儲成本降低 70% - 90%；原生支持多租戶架構，同集群可為多個獨立業務提供服務，租戶間數據隔離，降低部署和運維成本。 -
實時 HTAP
基于“同一份數據，同一個引擎”，同時支持在線實時交易及實時分析兩種場景，“一份數據”的多個副本可以存儲成多種形態，用于不同工作負載，從根本上保持數據一致性。 -
安全可靠
12 年完全自主研發，代碼級可控，自研單機分布式一體化架構，大規模金融核心場景 9 年可靠性驗證；完備的角色權限管理體系，數據存儲和通信全鏈路透明加密，支持國密算法，通過等保三級專項合規檢測。
1.2 系統架構
??OceanBase 使用通用服務器硬件，依賴本地存儲，分布式部署使用的多個服務器也是對等的，沒有特殊的硬件要求。OceanBase 的分布式數據庫處理采用 Shared Nothing 架構，數據庫內的 SQL 執行引擎具有分布式執行能力。
??OceanBase 在服務器上會運行叫做 observer 的單進程程序作為數據庫的運行實例，使用本地的文件存儲數據和事務 Redo 日志。
??OceanBase 集群部署需要配置可用區（Zone），由若干個服務器組成。可用區是一個邏輯概念，表示集群內具有相似硬件可用性的一組節點，它在不同的部署模式下代表不同的含義。例如，當整個集群部署在同一個數據中心（IDC）內的時候，一個可用區的節點可以屬于同一個機架，同一個交換機等。當集群分布在多個數據中心的時候，每個可用區可以對應于一個數據中心。
??用戶存儲的數據在分布式集群內部可以存儲多個副本，用于故障容災，也可以用于分散讀取壓力。在一個可用區內部數據只有一個副本，不同的可用區可以存儲同一個數據的多個副本，副本之間由共識協議保證數據的一致性。
??OceanBase 內置多租戶特性，每個租戶對于使用者是一個獨立的數據庫，一個租戶能夠在租戶級別設置租戶的分布式部署方式。租戶之間 CPU、內存和 IO 都是隔離的。
OceanBase的數據庫實例內部由不同的組件相互協作，這些組件從底層向上由存儲層、復制層、均衡層、事務層、SQL 層、接入層組成。
1.2.1 存儲層
??存儲層以一張表或者一個分區為粒度提供數據存儲與訪問，每個分區對應一個用于存儲數據的Tablet（分片），用戶定義的非分區表也會對應一個 Tablet。
??Tablet 的內部是分層存儲的結構，總共有 4 層。DML 操作插入、更新、刪除等首先寫入 MemTable，等到 MemTable 達到一定大小時轉儲到磁盤成為 L0 SSTable。L0 SSTable 個數達到閾值后會將多個 L0 SSTable 合并成一個 L1 SSTable。在每天配置的業務低峰期，系統會將所有的 MemTable、L0 SSTable 和 L1 SSTable 合并成一個 Major SSTable。
??每個 SSTable 內部是以 2MB 定長宏塊為基本單位，每個宏塊內部由多個不定長微塊組成。
??Major SSTable 的微塊會在合并過程中用編碼方式進行格式轉換，微塊內的數據會按照列維度分別進行列內的編碼，編碼規則包括字典/游程/常量/差值等，每一列壓縮結束后，還會進一步對多列進行列間等值/子串等規則編碼。編碼能對數據大幅壓縮，同時提煉的列內特征信息還能進一步加速后續的查詢速度。
??在編碼壓縮之后，還可以根據用戶指定的通用壓縮算法進行無損壓縮，進一步提升數據壓縮率。
1.2.2 復制層
??復制層使用日志流（LS、Log Stream）在多副本之間同步狀態。每個 Tablet 都會對應一個確定的日志流，DML 操作寫入 Tablet 的數據所產生的 Redo 日志會持久化在日志流中。日志流的多個副本會分布在不同的可用區中，多個副本之間維持了共識算法，選擇其中一個副本作為主副本，其他的副本皆為從副本。Tablet 的 DML 和強一致性查詢只在其對應的日志流的主副本上進行。
??通常情況下，每個租戶在每臺機器上只會有一個日志流的主副本，可能存在多個其他日志流的從副本。租戶的總日志流個數取決于 Primary Zone 和 Locality 的配置。
??日志流使用自研的 Paxos 協議將 Redo 日志在本服務器持久化，同時通過網絡發送給日志流的從副本，從副本在完成各自持久化后應答主副本，主副本在確認有多數派副本都持久化成功后確認對應的 Redo 日志持久化成功。從副本利用 Redo 日志的內容實時回放，保證自己的狀態與主副本一致。
??日志流的主副本在被選舉成為主后會獲得租約（Lease），正常工作的主副本在租約有效期內會不停的通過選舉協議延長租約期。主副本只會在租約有效時執行主的工作，租約機制保證了數據庫異常處理的能力。
??復制層能夠自動應對服務器故障，保障數據庫服務的持續可用。如果出現少于半數的從副本所在服務器出現問題，因為還有多于半數的副本正常工作，數據庫的服務不受影響。如果主副本所在服務器出現問題，其租約會得不到延續，待其租約失效后，其他從副本會通過選舉協議選舉出新的主副本并授予新的租約，之后即可恢復數據庫的服務。
1.2.3 均衡層
??新建表和新增分區時，系統會按照均衡原則選擇合適的日志流創建 Tablet。當租戶的屬性發生變更，新增了機器資源，或者經過長時間使用后，Tablet 在各臺機器上不再均衡時，均衡層通過日志流的分裂和合并操作，并在這個過程中配合日志流副本的移動，讓數據和服務在多個服務器之間再次均衡。
??當租戶有擴容操作，獲得更多服務器資源時，均衡層會將租戶內已有的日志流進行分裂，并選擇合適數量的 Tablet 一同分裂到新的日志流中，再將新日志流遷移到新增的服務器上，以充分利用擴容后的資源。當租戶有縮容操作時，均衡層會把需要縮減的服務器上的日志流遷移到其他服務器上，并和其他服務器上已有的日志流進行合并，以縮減機器的資源占用。
??當數據庫長期使用后，隨著持續創建刪除表格，并且寫入更多的數據，即使沒有服務器資源數量變化，原本均衡的情況可能被破壞。最常見的情況是，當用戶刪除了一批表格后，刪除的表格可能原本聚集在某一些機器上，刪除后這些機器上的 Tablet 數量就變少了，應該把其他機器的 Tablet 均衡一些到這些少的機器上。均衡層會定期生成均衡計劃，將 Tablet 多的服務器上日志流分裂出臨時日志流并攜帶需要移動的 Tablet，臨時日志流遷移到目的服務器后再和目的服務器上的日志流進行合并，以達成均衡的效果。
1.2.4 事務層
??事務層保證了單個日志流和多個日志流DML操作提交的原子性，也保證了并發事務之間的多版本隔離能力。
1.2.4.1 原子性
??一個日志流上事務的修改，即使涉及多個 Tablet，通過日志流的 write-ahead log 可以保證事務提交的原子性。事務的修改涉及多個日志流時，每個日志流會產生并持久化各自的write-ahead log，事務層通過優化的兩階段提交協議來保證提交的原子性。
??事務層會選擇一個事務修改的一個日志流產生協調者狀態機，協調者會與事務修改的所有日志流通信，判斷 write-ahead log 是否持久化，當所有日志流都完成持久化后，事務進入提交狀態，協調者會再驅動所有日志流寫下這個事務的 Commit 日志，表示事務最終的提交狀態。當從副本回放或者數據庫重啟時，已經完成提交的事務都會通過 Commit 日志確定各自日志流事務的狀態。
??宕機重啟場景下，宕機前還未完成的事務，會出現寫完 write-ahead log 但是還沒有Commit 日志的情況，每個日志流的 write-ahead log 都會包含事務的所有日志流列表，通過此信息可以重新確定哪個日志流是協調者并恢復協調者的狀態，再次推進兩階段狀態機，直到事務最終的 Commit 或 Abort 狀態。
1.2.4.2 隔離性
??GTS 服務是一個租戶內產生連續增長的時間戳的服務，其通過多副本保證可用性，底層機制與上面復制層所描述的日志流副本同步機制是一樣的。
??每個事務在提交時會從 GTS 獲取一個時間戳作為事務的提交版本號并持久化在日志流的write-ahead log 中，事務內所有修改的數據都以此提交版本號標記。
??每個語句開始時（對于 Read Committed 隔離級別）或者每個事務開始時（對于Repeatable Read 和 Serializable 隔離級別）會從 GTS 獲取一個時間戳作為語句或事務的讀取版本號。在讀取數據時，會跳過事務版本號比讀取版本號大的數據，通過這種方式為讀取操作提供了統一的全局數據快照。
1.2.5 SQL 層
??SQL 層將用戶的 SQL 請求轉化成對一個或多個 Tablet 的數據訪問。
1.2.5.1 SQL 層組件
??SQL 層處理一個請求的執行流程是：Parser、Resolver、Transformer、Optimizer、Code Generator、Executor。
??Parser 負責詞法/語法解析，Parser 會將用戶的 SQL 分成一個個的 “Token”，并根據預先設定好的語法規則解析整個請求，轉換成語法樹（Syntax Tree）。
??Resolver 負責語義解析，將根據數據庫元信息將 SQL 請求中的 Token 翻譯成對應的對象（例如庫、表、列、索引等），生成的數據結構叫做 Statement Tree。
??Transformer 負責邏輯改寫，根據內部的規則或代價模型，將 SQL 改寫為與之等價的其他形式，并將其提供給后續的優化器做進一步的優化。Transformer 的工作方式是在原Statement Tree 上做等價變換，變換的結果仍然是一棵 Statement Tree。
??Optimizer（優化器）為 SQL 請求生成最佳的執行計劃，需要綜合考慮 SQL 請求的語義、對象數據特征、對象物理分布等多方面因素，解決訪問路徑選擇、聯接順序選擇、聯接算法選擇、分布式計劃生成等問題，最終生成執行計劃。
??Code Generator（代碼生成器）將執行計劃轉換為可執行的代碼，但是不做任何優化選擇。
??Executor（執行器）啟動 SQL 的執行過程。
??在標準的 SQL 流程之外，SQL 層還有 Plan Cache 能力，將歷史的執行計劃緩存在內存中，后續的執行可以反復執行這個計劃，避免了重復查詢優化的過程。配合 Fast-parser 模塊，僅使用詞法分析對文本串直接參數化，獲取參數化后的文本及常量參數，讓 SQL 直接命中 Plan Cache，加速頻繁執行的 SQL。
1.2.5.2 多種計劃
??SQL 層的執行計劃分為本地、遠程和分布式三種。本地執行計劃只訪問本服務器的數據。遠程執行計劃只訪問非本地的一臺服務器的數據。分布式計劃會訪問超過一臺服務器的數據，執行計劃會分成多個子計劃在多個服務器上執行。
??SQL 層并行化執行能力可以將執行計劃分解成多個部分，由多個執行線程執行，通過一定的調度的方式，實現執行計劃的并行處理。并行化執行可以充分發揮服務器 CPU 和 IO 處理能力，縮短單個查詢的響應時間。并行查詢技術可以用于分布式執行計劃，也可以用于本地執行計劃。
1.2.6 接入層
??obproxy 是 OceanBase 數據庫的接入層，負責將用戶的請求轉發到合適的 OceanBase 實例上進行處理。
??obproxy 是獨立的進程實例，獨立于 OceanBase 的數據庫實例部署。obproxy 監聽網絡端口，兼容 MySQL 網絡協議，支持使用 MySQL 驅動的應用直接連接 OceanBase。
??obproxy 能夠自動發現 OceanBase 集群的數據分布信息，對于代理的每一條 SQL 語句，會盡可能識別出語句將訪問的數據，并將語句直接轉發到數據所在服務器的 OceanBase 實例。
??obproxy 有兩種部署方式，一種是部署在每一個需要訪問數據庫的應用服務器上，另一種是部署在與 OceanBase 相同的機器上。第一種部署方式下，應用程序直接連接部署在同一臺服務器上的 obproxy，所有的請求會由 obproxy 發送到合適的 OceanBase 服務器。第二種部署方式下，需要使用網絡負載均衡服務將多個 obproxy 聚合成同一個對應用提供服務的入口地址。
二、OceanBase 數據庫社區版部署
2.1 部署方式
快速部署
- 對于非原生支持的操作系統（比如 MAC 和 Windows），建議使用 Docker 鏡像的方式進行部署；
- 對于原生支持的操作系統（Linux 系列，具體見支持的操作系統列表），建議使用 OBD 進行部署；
標準部署 - 對于線下環境，建議使用 OBD/OCP 進行標準部署
- 對于 kubernetes 環境，建議使用 ob-operator 的方式部署；
2.2 基礎環境配置
軟硬件要求參考官方文檔：https://www.oceanbase.com/docs/common-oceanbase-database-cn-10000000001692940
所有的機器使用相同的軟硬件配置
設置無密碼 SSH 登錄
配置ntp始終
配置 limits.conf
在 /etc/security/limits.conf 配置文件中添加以下內容：
配置 sysctl.conf
在 /etc/sysctl.conf 配置文件中添加以下內容：
其中，kernel.core_pattern 中的 /data 為 OceanBase 數據庫的 data 目錄。如果您只是測試，您可以只設置 fs.aio-max-nr=1048576。
sysctl -p關閉防火墻和 SELinux
關閉防火墻 systemctl disable firewalld systemctl stop firewalld systemctl status firewalld關閉 SELinux 執行以下命令，打開 /etc/selinux/config 配置文件：vi /etc/selinux/config 在 /etc/selinux/config 配置文件中修改對應配置項為以下內容：SELINUX=disabled 執行以下命令或重啟服務器，使更改生效：setenforce 0 執行以下命令，查看更改是否生效：sestatus關閉透明大頁
echo never > /sys/kernel/mm/transparent_hugepage/enabled關閉防火墻和 SELinux
systemctl disable firewalld systemctl stop firewalld systemctl status firewalld在 /etc/selinux/config 配置文件中修改對應配置項為以下內容： SELINUX=disabled 執行以下命令或重啟服務器，使更改生效： setenforce 0 執行以下命令，查看更改是否生效： sestatus創建用戶
#創建賬戶 admin useradd -U admin -d /home/admin -s /bin/bash mkdir -p /home/admin chown -R admin:admin /home/admin passwd admin在/etc/sudoers添加如下內容： # %wheel ALL=(ALL) NOPASSWD: ALL admin ALL=(ALL) NOPASSWD: ALL修改集群相關文件所屬用戶 #數據盤，數據盤用來存儲基線數據，路徑由配置參數 data_dir 指定。在您首次啟動 OceanBase 集群時，${data_dir}/sstable 將自動創建。數據盤的大小由 datafile_disk_percentage/datafile_size 參數決定。 chown -R admin:admin /data/ob_data #事務日志盤，事務日志盤的路徑由配置參數 redo_dir 指定。建議您將事務日志盤的大小設置為 OceanBase 數據庫內存的 3 倍到 4 倍及以上。事務日志盤包含多個固定大小的文件。這些文件位于安裝目錄 ${redo_dir}/{clog,ilog,slog} 下。您可以根據您的需要自動創建和清除事務日志。事務日志達到磁盤總量的 80% 時，將觸發自動清除。但是，只有在事務日志對應的內存數據已經合并融至基線數據中時，事務日志才能被刪除。在相同數據量的情況下，事務日志的大小約為內存數據大小的三倍。因此事務日志盤所需空間上限與兩次合并后的數據總量成正比。經驗公式：事務日志文件大小 = 增量數據內存上限的 3~4 倍。 chown -R admin:admin /data/ob_redo #OceanBase 數據庫安裝盤，OceanBase 數據庫安裝盤的路徑由配置參數 home_path 指定。建議您為 OceanBase 數據庫安裝盤預留至少 200 G 空間以保存 7 天及以上的日志。OceanBase 數據庫的 RPM 包安裝目錄位于 ${home_path} 下。其中，基線數據文件和事務日志文件會通過軟鏈接分別指向獨立的數據盤和事務日志盤。OceanBase 數據庫的運行日志位于 ${home_path}/log 下。運行日志會不斷增長，并且 OceanBase 數據庫無法自動刪除運行日志，因此您需要定時刪除運行日志。 chown -R admin:admin /data/ob_base安裝java
yum install java-1.8.0-openjdk -y2.3 通過 OBD 白屏部署 OceanBase 集群(小集群單一管理)
#中控機 #下載并安裝 all-in-one https://www.oceanbase.com/softwarecenter tar -xzf oceanbase-all-in-one-*.tar.gz cd oceanbase-all-in-one/bin/ ./install.sh source ~/.oceanbase-all-in-one/bin/env.sh #啟動前端 obd web進行配置
預檢查
部署
OCP Express
2.4 通過 OCP 白屏部署 OceanBase 集群（多集群統一管理）
wget https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/download-center/opensource/ocp/4.0.3/ocp-4.0.3-ce-x86_64.tar.gz tar -xzf ocp-4.0.3-ce-x86_64.tar.gz cd ocp-4.0.3-ce-x86_64 ./ocp_installer.sh launch -p 2379 -k /root/.ssh/id_rsa
面板是OCP Express PLUS，提供多集群管控能力
添加軟件包
添加主機
三、總結
?OceanBase主要提供了兩種部署模式，OBD and OCP，OBD會自動部署OCP Express用來提供監控能力，OCP是一個中心管控平臺，需要一套metadb來存儲數據，可以提供多集群管理、部署和OCP Express的能力。
備注：
-
下載 OceanBase 4.1，請訪問：https://www.oceanbase.com/softwarecenter
-
OceanBase 4.1 版本技術文檔：https://www.oceanbase.com/docs/common-oceanbase-database-cn-10000000001698791）
總結
以上是生活随笔為你收集整理的「OceanBase 4.1 体验」｜快速安装部署的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 东北大学第二场算法题解报告
- 下一篇： 3年级计算机的知识能力,三年级信息技术教