1. 部署前的环境评估与版本选型1.1 社区版与商业版的边界要先搞清楚很多人一上来就直接下载安装包结果装到一半才发现功能不对、架构不匹配浪费大量时间。这里先花两分钟把社区版和商业版的关系捋清楚。OceanBase社区版是开源版本支持MySQL协议具备分布式事务、多副本一致性、水平扩展这些核心能力单机或者多机都能跑。商业版则在性能优化、运维工具链、高级压缩、专有云集成等方面有更多增强。如果你是要做业务系统验证、技术预研、中小规模生产环境社区版完全够用但如果是金融级核心业务建议直接走商业版渠道拿技术支持。版本选择上我自己主用4.x系列相对3.x在部署方式上更友好尤其是OBDOceanBase Deployer这套部署工具的成熟度让整个流程从“手工改一堆配置文件”变成了“写一个yaml、跑一条命令”。如果你拿到的教程还是教你在每个节点上手动执行一堆脚本那基本是旧版本时代的东西建议直接切到4.x。1.2 硬件配置怎么给才不浪费部署前先算算你的机器能不能扛得住。社区版本身不是一个“轻量级玩具”它是分布式数据库即使单机部署对资源也有明确要求。最低配置建议是2核8GB内存、50GB磁盘但这仅仅够“能启动”级别跑跑测试SQL勉强可以。想要比较流畅地跑TPC-C测试、模拟真实业务负载建议4核16GB起步。生产环境三节点集群每个节点8核32GB比较稳妥磁盘用SSD数据目录和日志目录分开挂载。操作系统的选择上社区版对Linux系的兼容性最好CentOS 7/8、Alibaba Cloud Linux、麒麟等都可以内核版本建议3.10以上。我自己实测过CentOS 7.9和Alibaba Cloud Linux 3这两个环境都很顺利。需要注意Oracle Linux如果开了UEK内核某些依赖包会有兼容问题能避开就避开。还有一个容易忽略的点部署前确认glibc版本。OceanBase 4.x对glibc的要求是2.17以上CentOS 7默认就是这个版本但如果你用的是精简版系统可能被裁剪过部署时会出现莫名其妙的段错误。检查方法很简单执行ldd --version看一下即可。1.3 部署工具链为什么选择OBD而不是手工步骤社区版提供了两套部署路径一种是完全手工方式下载rpm包、逐台安装、手工改配置文件、脚本启动这个过程繁琐且容易出错另一种就是OBD一键部署它是官方提供的自动化部署工具把环境检查、依赖安装、配置文件生成、服务启动、集群初始化全部串起来。我强烈推荐用OBD原因是它不光能装还能管。你用OBD部署的集群后续可以通过obd cluster start、obd cluster stop来启停通过obd cluster status来查状态比手工维护systemd服务省心太多。而且OBD有内置的检查项比如磁盘空间不够、端口占用、时区不对它都会在部署前警告把很多坑挡在了前面。2. 单机环境快速部署先让数据库跑起来2.1 下载安装包与配置本地源部署单机环境前先把安装包准备好。我建议直接配置在线源不推荐下载一堆rpm手工装。以CentOS为例你需要在目标机器上创建OceanBase的yum仓库文件。vi /etc/yum.repos.d/oceanbase.repo写入以下内容[oceanbase] nameOceanBase baseurlhttps://mirrors.oceanbase.com/OceanBase/rpm/7/x86_64/ gpgcheck0 enabled1这里提一个细节/rpm/7/代表CentOS 7/RHEL 7系列如果你用的是Alibaba Cloud Linux 3或CentOS 8要改成/rpm/8/否则yum解析会报「找不到包」。这个目录结构不少人在初次部署时栽过跟头。配置好后执行yum install -y oceanbase-ce obdoceanbase-ce是数据库服务端obd是部署工具。安装完成后执行obd --version确认工具就绪。2.2 编写单机部署配置OBD用的配置文件格式是YAML。单机部署的配置比较简单核心是定义一个集群名、指定一台机器的IP、分配组件版本和资源路径。obd cluster autodeploy quick-demo -c oceanbase-ce --version 4.2.1这条命令会自动生成配置并部署一个单机实例适合快速尝鲜。但如果你对目录结构有特殊要求还是建议自己写配置文件。下面是一个我常用的单机配置模板oceanbase-ce: servers: - name: ob1 ip: 192.168.1.100 global: home_path: /data/oceanbase data_dir: /data/oceanbase/data redo_dir: /data/oceanbase/redo devname: eth0 mysql_port: 2881 rpc_port: 2882 root_password: YourStrongPassword2024 ob1: mysql_port: 2881 rpc_port: 2882home_path是OceanBase的安装目录data_dir是数据文件目录redo_dir是redo日志目录。强烈建议把redo目录放到单独的磁盘或者至少独立分区上这直接影响写入性能。devname参数指定网卡名称OBD需要通过它检测IP。如果你的机器有多个网卡务必写准确不然后续observer无法正常通信。配置写好后执行部署命令obd cluster deploy quick-demo -c quick-demo.yamlOBD会先做环境检查然后下载依赖初始化目录安装组件最后启动服务。整个过程视网络速度而定一般五到十分钟能完成。2.3 连接数据库做首次验证部署完成后OBD会自动初始化系统租户sys租户并设置root密码。你可以在部署机的命令行直接用mysql客户端连接mysql -h192.168.1.100 -P2881 -uroot -p但有个小坑CentOS 7默认不带mysql客户端需要先安装yum install -y mysql如果连不上先看2881端口是否监听ss -lntp | grep 2881从实际经验看最常见的连不上原因就两个一是防火墙没放行2881二是配置里mysql_port写错。单机部署的容器化版本还要检查Docker映射物理机部署基本不涉及。连上后执行一条SQL验证基本功能show databases;然后建一个测试库和表随便插入几条数据看看响应是否正常。这一步能过滤掉90%的“部署假成功”问题。3. 生产环境三节点集群部署实践3.1 集群拓扑规划与Zone设计单机跑通之后如果你要部署三节点集群最核心的步骤是做好Zone规划。OceanBase的数据可靠性依赖多副本机制一个Zone是一组逻辑上的节点集合每个Zone内可以有一个或多个observer。三节点生产环境最经典的布局就是三个Zone各放一个节点节点IPZone角色节点A192.168.1.101zone1observer节点B192.168.1.102zone2observer节点C192.168.1.103zone3observer这样的布局下你可以在线容忍任意一个节点故障因为多数派副本仍然存活。官方推荐的同步事务语义也需要多数派至少三副本就是生产级的最低门槛。规划时还要注意磁盘容量。数据目录空间建议按业务数据量的1.5倍预留redo日志目录单独留200GB以上。很多生产事故不是机器挂了而是数据目录写满导致observer异常退出。3.2 集群配置文件参数详解三节点集群的配置和单机相比主要在servers列表、rootserver位置、参数设置上有所升级。下面是我在模拟项目X中实际使用过的配置模板oceanbase-ce: servers: - name: ob1 ip: 192.168.1.101 - name: ob2 ip: 192.168.1.102 - name: ob3 ip: 192.168.1.103 global: home_path: /data/oceanbase data_dir: /data/oceanbase/data redo_dir: /data/oceanbase/redo devname: eth0 mysql_port: 2881 rpc_port: 2882 root_password: YourStrongPassword2024 # 集群级参数 cluster_id: 1001 memory_limit: 16G system_memory: 3G stack_size: 512K cpu_count: 8 ob1: zone: zone1 ob2: zone: zone2 ob3: zone: zone3这里重点说一下几个参数memory_limit是observer进程能从OS申请的总内存上限建议设为物理内存的80%左右。system_memory是留给系统租户的内存不要小于2G否则系统内部任务容易触发OOM。cpu_count如果机器超过16核建议显式设置因为observer默认会用满所有核反而容易造成CPU调度争抢。cluster_id建议设置一个业务相关的唯一ID后续做数据迁移或者多集群管理时会省很多麻烦。配置文件里还需要额外指定rootserver的位置。OBD在4.x版本已经可以自动选举但为了部署的可预期性我习惯手动把第一个节点指定为初始rootserverservers: - name: ob1 ip: 192.168.1.101 role: ROOTSERVICE3.3 执行三节点部署三步曲配置文件就绪后部署流程跟单机差不多obd cluster deploy ob-cluster -c ob-cluster.yaml obd cluster start ob-cluster obd cluster status ob-cluster但三节点部署有一个额外强制步骤初始化Paxos组。实际上OBD在deploy阶段会调用obd cluster init把三个observer成员关系建立起来。如果你漏掉了这一步哪怕三个节点进程都在集群也无法对外提供分布式服务。初始化过程会有类似这样的输出obd cluster init ob-cluster --init-only执行完成后再查状态应该看到类似active的标识。我用一个比喻来解释这个过程deploy相当于把三台服务器的“数据库引擎”安装好并点火init是让三个人互相确认“我们属于同一个团队谁是领导、谁做备份”没有init引擎再多也是一盘散沙。3.4 租户创建与业务接入前的检查集群起来后默认只有sys租户。业务要使用OceanBase需要创建业务租户。这一步很多人会漏因为单机部署时sys租户就能建表测试但生产环境不推荐业务直接使用系统租户。创建业务租户的SQL示例CREATE RESOURCE UNIT u_small_config MAX_CPU 2, MIN_CPU 1, MAX_MEMORY 6G, MIN_MEMORY 4G, MAX_IOPS 1024, MIN_IOPS 1024, LOG_DISK_SIZE 8G; CREATE RESOURCE POOL pool_small UNIT u_small_config, UNIT_NUM 1, ZONE_LIST (zone1,zone2,zone3); CREATE TENANT business_tenant RESOURCE_POOL_LIST (pool_small), PRIMARY_ZONE zone1;zone2,zone3, DEFAULT_TABLEGROUP NULL, CHARACTER_SET utf8mb4;PRIMARY_ZONE的定义会影响强一致读的流量优先调度到哪个Zone。上面写法表示优先用zone1如果zone1故障再使用zone2和zone3。UNIT_NUM 1表示每个Zone放一个资源单元三副本数据落盘就是3份。创建完成后用一下命令确认租户可见SHOW TENANTS;然后就可以通过业务租户的链接来连接了mysql -h192.168.1.101 -P2881 -ubusiness_userbusiness_tenant -p。如果你把用户名写成裸的business_user会连不上这里奥妙在于用户名租户名的结构初次用的人最容易在这里卡住。4. 部署后的健康检查与基础运维4.1 集群状态与分区副本校验部署完成不代表万事大吉。至少要跑一遍系统性的健康检查才能确认集群真的处于“可用且高可用”状态。先用OBD查集群进程状态obd cluster status ob-cluster正常输出会有每个节点的observer进程状态和uptime。然后登录sys租户查看集群的全局视图SELECT * FROM oceanbase.DBA_OB_ZONES; SELECT * FROM oceanbase.DBA_OB_SERVERS;重点关注STATUS是否为ACTIVE以及START_SERVICE_TIME是否已经初始化。如果ZONE显示INACTIVE说明该Zone内的observer没有正常启动或者心跳丢失需要进一步查observer日志。分区副本的校验也很必要尤其在你创建了业务租户并导入测试数据后SELECT COUNT(*) FROM oceanbase.DBA_OB_TABLEGROUPS;这个命令能确认表的副本分发情况。副本不是均匀分布也不代表有问题OceanBase的负载均衡会自动迁移但如果你初始化后立刻检查发现大量副本还在某个Zone里可以等一会儿再看或者手动触发均衡任务。4.2 配置文件与日志体系速查OceanBase的日志主要分两个部分observer.log是核心运行日志记录SQL执行、事务提交、合并等关键事件election.log是选举相关日志多副本环境下排查主备切换问题时特别有用。日志位置默认在home_path/log/我常用的排查命令组合# 查看observer最近的错误日志 grep -i error /data/oceanbase/log/observer.log | tail -n 50 # 查看选举相关日志 tail -n 200 /data/oceanbase/log/election.logOBD本身的日志在~/.obd/log/下如果obd cluster deploy中途失败先看这个目录里的obd.log。这里有一件非常重要的经验不要随意删日志文件。OceanBase的日志系统不是简单的追加文件它内部有log归档和索引机制直接删物理日志文件会导致observer无法启动出现data gap错误。真要清理应该用系统自带的任务或设置日志滚动策略。4.3 备份策略与恢复演练任何数据库部署完备份是第一优先级。OceanBase社区版的备份恢复有两种方式逻辑备份和物理备份。物理备份在社区版里能力有限我更推荐逻辑备份工具obd内置的obclient配合SQL导出。最简单的逻辑备份方式obd cluster tenant backup ob-cluster -t business_tenant -p /backup/tenant_20240101.dump这条命令会把业务租户的数据做逻辑导出。恢复的时候obd cluster tenant restore ob-cluster -t business_tenant -p /backup/tenant_20240101.dump注意恢复目标租户必须已经存在且不能有同名表否则会报错。所以我在实际操作中的习惯是恢复前先建一个临时租户导入完成确认数据无误后再切换。另外备份文件一定要放到独立的存储位置不要放在observer的数据盘上。曾经见过有人把备份放到/data/oceanbase/backup结果那个目录和数据目录同盘磁盘一满整个数据库一起挂掉这属于典型的“备份把自己备份没了”。5. 部署过程中的高频问题与排查实录5.1 依赖缺失与Python版本兼容问题OBD本身是用Python写的对Python版本比较敏感。CentOS 7默认的Python 2.7可以用但如果你用CentOS 8系统默认Python 3.6部分OBD版本会对某些模块不兼容报出类似ModuleNotFoundError的信息。我遇到过一次在新装CentOS 8.5的系统上执行obd cluster deploy报错找不到setuptools。解决方法是yum install -y python3-setuptools还有一次是缺少mysqlclient库会在集群初始化写初始化密码时报错。解决方法是安装yum install -y mysql-devel gcc如果依赖问题反复出现建议直接查看OBD日志中具体是哪个Python模块导入失败然后针对性地安装对应包不要盲目装一堆。5.2 端口占用与防火墙拦截OceanBase默认使用2881MySQL协议端口和2882内部RPC端口三节点部署下每台机器这两个端口都要互通。如果你在同一台机器上跑多个observer实例还会用到2883等端口。端口冲突的最典型报错是Bind failed: Address already in use排查用ss -lntp | grep 288看哪个进程占了。防火墙关闭或放行的问题在部署前就应该处理完。我一般直接确认生产环境使用的节点都已经配置成相应放行firewall-cmd --permanent --add-port2881/tcp firewall-cmd --permanent --add-port2882/tcp firewall-cmd --reload集群内部节点通信如果被安全组或防火墙挡了最直观的现象是observer启动后ZONE状态一直是INACTIVE或者Paxos选举超时。这类问题排查链路长一定要在动手部署前把网络打通验证做掉。5.3 内存配置过大导致OOM内存参数memory_limit如果设置得比物理内存还大observer会在负载上来后频繁触发OOM。这个问题在低配机器上尤其常见比如4G内存的机器memory_limit写成了刚好4G还有操作系统本身占用结果OOM killer直接杀掉observer进程。我习惯的经验公式是物理内存8G以下memory_limit控制在物理内存的60%物理内存16Gmemory_limit设置到物理内存的75%物理内存32G以上memory_limit设置到物理内存的80%同时预留足够空间给OS page cache如果出现OOM登录机器执行dmesg | grep -i oom能看到kernel kill进程的记录。解决方式是调低memory_limit然后重启observer。但注意直接obd cluster restart会把整个集群重启生产环境要先确认维护窗口。5.4 磁盘空间计算失误OceanBase的data目录增长非常快尤其是开启合并后临时文件可能占掉和实际数据差不多的空间。redo日志目录则要支持持续的写入如果redo所在磁盘写满observer会直接进入stopped状态。我踩过一次坑本机测试环境给了数据盘200GB以为够用结果执行了一个大事务导入加上合并和日志归档一天之内磁盘就满了然后集群状态全面飘红。后来我把redo目录挂载到另一块独立的NVMe盘上问题才彻底解决因为这个盘即使写满也不会阻塞数据盘的合并。给新人的建议无论什么环境先执行df -h看看各目录的挂载情况确保data_dir和redo_dir不在同一个分区。如果机器只有一块盘至少在不同目录上预估足够余量并把自动清理日志的定时任务提前配好。5.5 时区不一致引发的诡异问题如果你有多台服务器一台是CST一台是UTC部署完成后查询时间戳可能差8小时。这个问题不会导致启动失败但会导致监控告警、日志时间线错乱。给集群统一时区很简单修改每台机器timedatectl set-timezone Asia/Shanghai同时在OceanBase的配置文件中加上ob_timezone参数统一设定数据库会话时区。这一步在单机部署感受不明显但在多节点生产环境是必须做的。写在后面的一些体会从我反复部署社区版OceanBase的经验看这套系统的部署本身并不难真正考验人的是各种前置规划的细节。硬件评估、网络放行、目录挂载、参数预留这些看起来琐碎的工作决定了后续运行期你是在安稳地写业务还是在半夜起来救火。我个人最想强调的是把部署脚本和配置文件纳入版本管理。很多团队的数据库环境是“一人部署完其他人黑盒使用”一旦要扩容、迁移、重建环境就只能靠记忆猜配置这是最危险的状态。我自己的习惯是为每个集群环境单独建一个目录配置、检查脚本、备份策略说明都放进去任何人拿到就能复现一套新环境。社区版OceanBase在4.x之后越来越成熟部署的复杂度已经大幅下降但生产环境终究不是跑个demo多留一分谨慎少踩一个坑这大概就是运维人最真实的日常。
