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集群初始化不成功都跟机器环境有关。关于机器初始化可以使用官网下载的文件里初始化脚本，具体请参考《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集群每个任务操作的细节步骤。
自动化运维平台做的事情，是把运维人员的重复性的工作标准化、流程化以及并行化执行，规避了运维人员人为错误、人力不足问题。早期对自动化运维产品也有个总结，有兴趣的朋友可以参见《自动化运维产品的命门——元数据库》。

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

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

(直播) OB 2.2 产品功能和部署介绍
(直播) OB 2.2 运维和开发介绍

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

参考

来源：oschina

链接：https://my.oschina.net/u/4343285/blog/3207420

标签

Amp

OCP

Observer