2022年，我们在调研十多款数据库后，将MySQL迁移至OceanBase3.1.4单机版，后续又搭建了OceanBase 4.0集群2节点，因性能问题，提升到了5节点,因操作便捷性，搭建了ODC，OCP。我将此过程中我们遇到的小问题及解决方案总结成文，供大家参考。
将MySQL替换为OceanBase的决心
在使用OceanBase之前，我们的业务主要在MySQL数据库上运行，随着业务数据的增加，MySQL出现了支撑瓶颈，并且查询越来越慢。
单机 MySQL 面临很多问题:
1. 单表太大，比如超过 500w，查询就非常吃力
2. 单库太大，各种资源告急
3.读请求太高，严重影响写请求
我司的主要业务场景之一是数据可视化前台，查询速度慢影响用户体验是不被业务客户所能接受的。因此，我们需要重新寻找一款能够满足实时性要求的数据库。
在调研了OceanBase、TIDB、达梦等国产数据库以及ClickHouse，ElasticSearch等国际热门数据库后，我们用8核16GB的配置做了简单的百万级大表查询测试、MySQL兼容性测试、易用性测试，由于OceanBase查询速度最快，安装方便，且与MySQL兼容度高能降低选型成本，也不会增加研发人员的学习成本，因此在众多选型目标中凸显了出来。此外，OceanBase还满足了我们软件升级的潜在需求，其多年支撑淘宝、“双11”、支付宝与完全自研、开源的特性，加速了我们落地OceanBase的决心。
因项目需求，数据量属于递增型，当时数据库替换已经迫在眉睫，因此优先部署了OceanBase 3.1.4单机版，后续又搭建了OceanBase 4.0集群，安装了OCP、ODC。业务客户为我们提供了四台服务器，其中一台服务器部署OCP，一台服务器用来备份，另外两台服务器各部署一个数据库节点。相比之下，集群版查询更快速，容灾性能更好，目前已配置5节点集群，一台OCP，一台ODC，提高容灾性，主业务数据全部使用OceanBase数据库。
使用一段时间过后，最后确定选择oceanbase4.0版本，原因主要如下：
1.oceanbase4.0相较于3.1.4性能大幅提升
2.我们是纯内网的环境，部署方式便捷性很重要
3.单机性能有限，同时节点数量过少会导致集群崩溃，4.0配置集群5节点，提高容灾性，稳定性
5.数据查询速度方面仍需要优化，想发挥分布式数据库的优点，加快查询速度
6.同事们在经过一段时间实践过后，内部认可OceanBase数据库，一致决定继续使用
通常，我们将业务客户的数据通过Python脚本写入数据库，通过计算与处理，最终将分析报表展示在可视化前台供用户查询。目前，我门在OceanBase中的总数据量已达上千万，单表数据大约六百万，呈持续新增状态，最大的CSV文件超过已2GB，涉及的查询一般是百万级别的表关联十万级别的，速度是认可，同时还在与老师讨论持续优化中。
如今，我们已经稳定使用OceanBase有快1年了，过程中比较顺利，但也遇到过一些小问题。我将这些问题及解决方法汇总分享，希望为广大用户提供参考价值。
使用OceanBase的问题及解决方案
问题1：早在2022年6月，我们就已经接触OceanBase数据库，部署方式选择了Docker模式，当时社区版还未健全，无法实现数据的持久化。我们遇到的主要问题是Docker容器删除重建，会导致数据库的数据丢失。
解决方案：通过查询官网，取得了联系方式，分别加入了社区和两个钉钉支撑区，经过与老师讨论过后，在社区发帖求助，老师提供了指导，第一次是通过重启容器后，执行手动数据恢复操作。后面老师制作了新的镜像，已实现数据的持久化。
感兴趣的朋友可查看https://ask.oceanbase.com/t/topic/35600293
问题2：同样的sql语句，在MySQL下查询比OceanBase快。
解决方案：开始使用OceanBase时，对特性不是很了解，文档没有读的很仔细，不了解OceanBase的查询模式及Hint模式，经过社区和钉钉群老师的指导，添加了老师的钉钉，远程指导操作sql查询，一步一步调试，查看执行计划，分析索引命中，老师的排查结果是抽了temptable后大表上的索引失效走了全表扫描，在相关的select语句中加上no_rewrite的 hint可以先绕过
在官方的协调帮助下，通过配置/*+paraller(32)*/,/*+NO_REWRITE*/，一步一步优化sql执行计划，最终查询速度显著提升，了解了分布式数据库的并发模式。
优化可参考https://ask.oceanbase.com/t/topic/35601802/11
问题3：OceanBase集群运行报错后自动停服。在OCP观察发现有严重警告，然后就自动停止服务了。重启后正常了。操作记录是使用Python连接数据库执行select然后是update，update更新表是百万级别。
解决方案：在钉钉群与老师沟通过后，在社区发帖，并补全老师排查需要的log日志，得到老师反馈后，
执行
cd /home/admin/oceanbase/etc
strings observer.config.bin
通过查看集群配置和日志后发现，是执行sql过程中，内存溢出了。
排查节点服务器的日志，出现OOM
主要原因为节点的内存配置超过了机器的内存上限，机器内存16G，节点配置24G，导致真正使用大内存时超过内存限制，集群只有2个zone,每个zone下一台observer,当其中一个节点因oom被kill后，不满足多数派，整个集群对外不可服务，停服。
合理调整集群的配置。方案地址如下
https://ask.oceanbase.com/t/topic/35601894/24
https://ask.oceanbase.com/t/topic/35601848
问题4：OceanBase集群执行插入百万数据，运行十多分钟， 我们以为是数据库兼容问题，导致插入慢。
解决方案：最开始排查问题时，通过对比mysql的本地插入，我们怀疑是OceanBase数据库问题，也可能是我们使用问题，事不宜迟，立马发帖和钉钉联系老师，双管齐下。
老师提出了优化的意见，开启并发并行。我们这边使用的是Java中的JPA插入操作，以为是JPA与OceanBase数据库的兼容问题，在与老师讨论，并且直播留言模块反馈过后，确认是兼容的。
后面开始排查代码，发现并行的rewriteBatchedStatements和JPA的batch_size并未生效，从来更改代码测试，反复与老师协商过程中，更改代码并优化。
最后该问题经历一周的时间，终于在多位老师的协助下，开启并发批量提交插入的方式，实现百万插入几分钟完成，极大的提升了效率，解决方案见https://ask.oceanbase.com/t/topic/35601950/35在此感谢帮助过我们的社区老师，辛苦了。
总结
目前，我们还没有发挥出分布式数据库的特性，只能在单一节点进行运算，已经再进行表分区尝试，安装了ODC，实现分布式运算，加快查询速度。同时执行OCP上的备份尝试，实现数据自动备份。
我们一路从OceanBase 3.1.4单机，转到OceanBase4.0集群，从OCP管控2节点集群，扩容至5节点集群，遇到了很多小问题，但大多数都已得到处理。体验很好，我们也欣然接受OceanBase给我们带来的便利。
特别感谢各位OceanBase 社区的朋友和钉钉答疑群的群友，感谢每一位的付出与帮助。愿OceanBase越来越好，我们也会支持用户社区，拥抱开源。
