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