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 1.4版本)。细心的朋友可能会说单副本怎么也叫集群。单副本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部署，8G内存就可以，一个命令启动Docker镜像OB就可以直接用了。敬请期待。

关于机器问题的总结

一直以来，绝大部分OB集群初始化不成功都跟机器环境有关。关于机器初始化可以使用官网下载的文件里初始化脚本，具体请参考《​​OceanBase 2.x 试用版安装体验——OCP 2.3​​》中的章节 “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集群每个任务操作的细节步骤。

如果想开发基于OceanBase的性能采集监控告警系统，乃至OB运维系统，可以通过开启OB的SQL的​​全量审计​​功能研究OCP的相关SQL和OB内部视图。

自动化运维平台做的事情，是把运维人员的重复性的工作标准化、流程化以及并行化执行，规避了运维人员人为错误、人力不足问题。早期对自动化运维产品也有个总结，有兴趣的朋友可以参见《​​自动化运维产品的命门——元数据库​​》。

关于OCP失败任务问题的总结

有关OCP的部署和使用，请先查看我在云栖社区的直播：

• ​​OB 2.2 产品功能和部署介绍 https://yq.aliyun.com/live/2009?spm=a2c4e.11153940.0.0.78937a7cONA9zX​​。
• ​​OB 2.2 运维和开发介绍 https://yq.aliyun.com/live/2010?spm=5176.13950896.J_4584709990.9.2dd514080Yd0Cp​​

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：数据导出&导入​​》。

参考

• ​​OceanBase数据库实践入门——手动搭建OceanBase集群​​
• ​​OceanBase 2.x体验：手动搭建OceanBase集群​​
• ​​OceanBase 2.x 试用版安装体验——OCP 2.3​​
• ​​OceanBase 2.x 体验：示例数据库​​
• ​​OceanBase 2.x体验：用BenchmarkSQL跑TPC-C​​
• ​​OceanBase 运维平台(OCP)使用基础：Docker技术​​
• ​​OceanBase 2.x体验：推荐用DBeaver工具连接数据库​​
• ​​(直播) OB 2.2 产品功能和部署介绍 https://yq.aliyun.com/live/2009?spm=a2c4e.11153940.0.0.78937a7cONA9zX​​

• ​​(直播) OB 2.2 运维和开发介绍 https://yq.aliyun.com/live/2010?spm=5176.13950896.J_4584709990.9.2dd514080Yd0Cp​​