网站设计服务,做泵阀生意到哪个网站,企业建站多站点管理系统,怎么重新装一下wordpress引言#xff1a;自2021年起#xff0c;翼鸥教育便开始应用OceanBase社区版#xff0c;两年间#xff0c;先后部署了总计12套生产集群#xff0c;其中核心集群占比超过四分之三#xff0c;所承载的数据量已突破30TB。自2022年10月#xff0c;OceanBase 社区发布了4.2.x 版…引言自2021年起翼鸥教育便开始应用OceanBase社区版两年间先后部署了总计12套生产集群其中核心集群占比超过四分之三所承载的数据量已突破30TB。自2022年10月OceanBase 社区发布了4.2.x 版本其单机效能、数据压缩实力及AP分析能力等核心功能进行了整体升级深深吸引了我们的目光。于是在4.2.1 LTS版正式面世后我们立刻启动了升级计划目前已经从最初的OceanBase 3.1.4升级到4.2.1 版本。 本文分享我们在版本升级过程中积累的一些经验供大家参考。 家里有孩子的朋友或许对翼鸥教育的核心产品“ClassIn在线教室”比较熟悉。作为应用于150多个国家的全球教与学一体化平台ClassIn 为学生提供从课前到课后的智慧服务以及从软件到硬件的配套设施。此外翼鸥教育旗下还有TeacherIn、NOBOOK 等众多优质的教育科技产品。
翼鸥教育应用OceanBase的起因是想解决MySQL带来的问题。众所周知MySQL读出现瓶颈时可以通过扩展从库轻松解决但遇到写瓶颈的时候就比较难办了。尤其是单机数据增长到2TB以上写能力愈发受限数据处理效率也逐渐变低。这时我们会想到分库分表方案但分库分表无法从根本解决问题。业务连续性也是一个问题MySQL的高可用能力依赖外部组件需要投入专门的人力去维护。因此当我们了解到OceanBase多分区的灵活扩展能力、高数据压缩率以及金融级高可用后我们怎么会不选择它呢
我们为什么选择将OceanBase从 3.1.4版本升级到4.2.1版本
在上线OceanBase 3.1.4版本后我们陆续部署了12套生产集群其中超过3/4的集群是核心集群数据量超30TB。上线之后OceanBase 3.1.4的确为我们解决了不少难题在灵活扩展、数据库压缩和高可用等方面的表现优异。
OceanBase在翼鸥教育的应用场景如下图所示翼鸥教育的应用通过访问SLB服务器负载均衡再连接到OceanBase生产集群。在大数据场景下由于OceanBase 3.1.4版本AP性能较弱我们将上游数据通过OMS工具同步至OceanBase集群在实时场景使用OMS将数据同步至Kafka在离线场景使用Data X将数据抽取到大数据的数仓系统中进行分析。 俗话说没有一款产品是万金油OceanBase 3.1.4在我们的业务场景中逐渐显现出一些不足。
1. DDL支持不完善。OceanBase的DDL速度非常快但在3.x版本支持不够完善比如向上兼容不支持text- medium text再比如不支持int - varchar的列类型修改。
2. 字符集支持不完善。由于历史原因我们使用的字符集没有用OceanBase 支持的 utf8mb4_general_ci而是 utf8mb4_bin字符集导致我们使用OMS在上游加字段时下游的大数据集群就会发生数据迁移任务的中断。
3. 大IN支持不友好。例如在MySQL中 IN 包含 80万个值查询只需10ms而在OceanBase 3.1.4版本中需要5s是因为时间主要消耗在查询解析方面。OceanBase 4.2版本后对这方面做了优化性能提升明显。
4. 分区数太多影响性能。当分区数超过30000后响应时间下降明显。
5. 数据膨胀问题。OceanBase的降本增效的效果非常显著原来MySQL集群中6TB数据迁移到OceanBase后缩减到了1TB。但我们发现集群使用一段时间后数据存在空间放大的问题。比如本来一年增长1.5TB但集群膨胀了4T。
6. 物理备份不支持S3。S3是可以充分利用网络带宽且价格优惠的存储方式但OceanBase 3.1.4版本仅支持nfs未支持S3。
基于上述使用方面的不足我们决定升级到OceanBase 4.x版本。 升级至OceanBase 4.2.1版本的流程和效果
从版本选型到版本升级我们历经四个阶段版本选型、功能和性能测试、组件升级、集群升级。
第一阶段版本选型。
选择版本时我们主要考虑五个因素。
功能新版本能否满足当前业务需求性能新版本性能相较于旧版本性能提升多少稳定性新版本是否足够稳定有没有bug兼容性迁移后与旧的集群是否兼容产品生命周期新版本是否为官方长期支持版本
针对上述问题我们结合应用场景需求对OceanBase 4.x版本特性与升级点进行了分析认为新版本相较于旧版本性能有显著的提升能够更好地满足当前场景的需求。且OceanBase 4.2版本是长期支持版本。长期支持版本经过多次迭代遇到的问题较少创新版本经过几个版本的迭代和修复也会渐趋稳定。兼容性方面因为我们是从OceanBase低版本升级到高版本所以兼容性良好。
第二阶段功能和性能测试。
在MySQL环境中我们可以使用tcpcopy进行流量回放来进行业务验证。然而在OceanBase中业务是以租户为单位的如果直接采集流量会涉及多个租户。为了方便实现我们自己开发了一个代理Agent实时将SQL_audit中的SQL同步到Kafka。在目标端可以启动多个Agent读取select语句来并行进行回放并观察目标端是否受到影响。 我们基于gopacket抓包。再进行mysql ps数据解析经过解析的PS协议及其参数的结果存在Redis最后通过Agent读取Redis回放。这样可以让我们提前发现业务迁移中可能存在的问题比如执行计划是否变慢、是否有不兼容问题等。
在迁移前我们通过sysbench压测观察OceanBase新版本相较于旧版本的性能提升度。我们的服务器规格都是64C/512G但此处仅基于16C/96G的业务租户配置进行压测。从下图可见OceanBase 4.2.1版本较OceanBase 3.1.4版本性能提升3倍左右即使在读写比7:3的场景下新版本的性能更优也更为稳定。 此外保险起见我们基于JMeter使用CSV动态生成参数的方式对生产线接口进行压测线上租户配置为3节点16C/96G 。结果如下图所示OceanBase 4.2.1版本较OceanBase 3.1.4性能提升2倍左右。 第三阶段组件升级。
在确定版本升级后我们先对组件进行升级以下是我们在升级过程中的一些经验总结供大家借鉴
1. 如何解决长期未使用的Agent导致升级OCP时报错的问题
具体而言显示ocp-server-ce:check_operation_task未通过The Server have running task。这是因为我们升级OCP时使用的Agent经久未用导致无法回滚所以我们在它的原数据库中更新状态就可以了update task_instance set stateSUCCESSFUL where id in (父任务id);
2. 如何针对OMS Store 进行性能调优
作为OMS的重度用户OMS store可以理解为一个binlogservice的webservice并且store内部有OB CDC模块。该模块包括数据消费模块和拉取日志模块。消费日志线程cdc会从多个OBServer中拉取clog并排序存储到内存中。此时CDC拉取日志模块会消费内存中数据并将其落盘。然而由于最初使用的是机械硬盘默认的storage即机械盘导致落盘速度较慢。为了进行性能调优我们将参数storage调整为内存并且将OB CDC使用的内存限额从20G调整为40G。此外为了及时更新心跳时间我们还将DDL当前拉取日志的上限progress_limit_sec_for_ddl从3600秒调整为60秒。
3. 如何解决OMS迁移和同步任务延迟问题
在OMS的迁移流程中首先会启动OMS store以保证后续DBA能成功取到增量数据。然后全量迁移流程随之启动待全量迁移和全量校验完成后再启动增量数据迁移和校验流程。在这个流程中我们经常遇到数据迁移慢、校验时间长的问题以及数据同步到Kafka
延迟的问题。究其原因不同场景采用默认参数速度不及预期我们可以通过调整参数来解决上述问题。
在数据迁移和校验场景速度慢的时候我们通常会想到调整线程数或切片大小以读取更多数据。但是读取更多数据就意味着内存需要更大的承载量所以我们要把JVM参数调高。
常用调参
• workerNum | limitator.platform.threads.number
• sliceBatchSize | limitator.select.batch.max
• connectorJvmParam | task.checker_jvm_param
应用场景调参
• sliceByMinMax: falseid不连续
• sliceByMinMax: trueid连续 在数据同步sink到Kafka场景下如果速度较慢可能是由于分片算法的影响导致OBServer的I/O较高。这是slicebyminmax的原因通常情况下我们的跑批操作类似数据库工具pt和ghost它们基于范围100~~10000不断向前滚动。然而有时我们的自身ID包括业务使用的UUID它可能是不连续的这会导致读取I/O较高。在这种情况下需要关闭切片的slicebyminmax设置这样可以提高数据同步速度。如果仍然无法满足预期在机器的支持能力足够的情况下还可以调整批处理的大小每次读取更多的数据。
另外还需要调整JVM的内存。在这个场景下开发人员都知道对于插入操作可以很容易地进行批量处理。但对于更新和删除操作就不那么容易进行批量处理。因此需要根据上游的情况如是否有大事务等动态调整参数尤其是针对insert和update的比例。首先消除最重要的瓶颈然后再调整其它常用的参数特别是在OMS中将增量同步到大数据库的情况下。我们采取了大数据库的lock_time默认值并将OceanBase的ob_query_time参数设置得比较大因为锁的释放时间根据ob_query_time来确定可能会导致长时间被锁住的情况进而使jdbc的writer的点位不更新。实际上数据仍然会持续写入目标端。
常用调参
• workerNum
• maxRecordCapacity
• connectorJvmParam
应用场景调参
• splitThresholdinsert攥批效率高update和delete不能批量拆开效果好
4.如何解决4018错误码报错
在使用OceanBase的过程中让我们最困扰的问题是4018错误码这也是版本升级的直接原因。当出现4018错误码的时候一个zone中两个机器只有一个机器节点报错无法请求导致业务报错。短期解决方法是重启报错的机器节点而从长远来看升级版本才能彻底解决问题。我们升级到OceanBase 4.2.1.3 版本后再没有遇到过4018问题。 第四阶段集群升级。
在集群升级的过程中我们仍然保持谨慎的态度分为准备、生产上线、整体回归、收尾操作四个步骤升级成功后整体效果满足预期
新版本的DDL支持完善解决了旧版本的DDL问题且性能得到较大提升数据被进一步压缩比如300GB数据迁移到新版本后压缩至200GB存储空间得到释放新版本的备份支持S3使我们可以充分利用网络带宽数据从OMS同步到Kafka性能提升7倍。
至于上文提到的字符集支持问题可能是OB server带来的在OMS迁移的部分场景中仍会出现任务中断的现象。
总结与规划
目前我们把8套核心集群都升级到了OceanBase 4.2.1版本升级经验总结如上。而在我们从上线到使用OceanBase期间有五点应用经验可供大家参考。
第一 在我们使用OceanBase的过程中跑批是业务经常做的工作。经验指出跑批或数据更新时尽量指定分区避免跨节点分布式事务。
第二 尽可能使用本地索引以节省开销因为全局索引更新需要分布式事务所以在唯一性或者多维场景下使用全局索引。
第三 针对副本切主OBServer事务查杀有重试逻辑业务同学要能够及时捕获异常利用分布式特性和发挥分区并行的优势避免业务报错。
第四 在OLAP环境下可以充分利用并行提升查询速度建议单个分区小于50GB。
第五 此前人工排查问题时速度比较慢obdiag推出后问题定位和日志分析都变得方便、简单在此推荐大家充分利用这个工具。
后续我们会把剩余OceanBase集群都升级到4.2.1版本。同时随着OceanBase 4.3版本AP能力的提升我们也考虑将大数据集群升级到该版本。 OceanBase 云数据库现已支持免费试用现在申请体验分布式数据库带来全新体验吧 ~
