迁移到oceanbase,如何规划和实施-c7电子娱乐
在之前一篇的文章中,我介绍了如何对 oceanbase 进行测试,如果大家按照这些方式进行测试之后,对 oceanbase 数据库应该已经有了一个比较深入的了解了。如果测试非常满意,那么接下来就需要考虑怎么把 oceanbase 替换上去,想要直接把线上数据库替换成 oceanbase,光做这些测试肯定是还不够的,虽然知道了 oceanbase 性能很好,并发很高,压缩比也很高,但是要真正把线上数据库换成 oceanbase,我们还得做很多规划、演练和方案。简单整理如下:
- 生产集群规划
- 集群部署方式
- 一些最佳实践
- 集群高可用方案
- 集群灾备方案
- 集群资源规划
- 集群监控方案
- 上下游数据同步方案
- 生产集群切换及回滚方案
- 日常运维手册及sop整理
生产集群部署方案规划
对于数据库的替换,首先就需要了解目标数据库的一些最佳实践是什么,包括如何部署数据库,高可用怎么实现,如何监控等等。接下来,我就分几个小节,将 oceanbase 的一些最佳实践分享给大家。
集群部署方式
第一项工作,就是需要找到适合自己的部署方式,oceanbase 目前推荐主要有四种生产环境部署方案,分别是通过 obd 图形化页面部署、通过 ocp 平台部署、通过命令行部署以及在 kubernetes 环境中部署。另外还提供使用 systemd 部署和使用容器部署,这两种方案都仅适用于测试和学习,不建议在生产环境部署。在 kubernetes 环境中部署,则是通过 ob-operator 部署 oceanbase 集群。
这么多部署方式,具体应该选择哪种呢?
使用 obd 图形化和命令行部署集群,实际是一样的,都是通过 obd 部署和管理集群,只不过 obd 图形化部署时,我们可以通过图形化页面进行集群的配置,而命令行部署则是需要我们手动编写配置文件。在 kubernetes 中部署,则是看公司是否有这块的需求,然后决定是否在 kubernetes 中部署。
因此我们主要对比 obd 和 ocp 部署集群的区别:
区别一:从资源占用角度,obd是一个命令行工具,因此基本不占用其他资源。ocp 是一个管理平台,需要额外资源部署 ocp。
区别二:从部署便捷程度,相差不大,obd 命令行需要编写配置文件,可能会麻烦些。obd 图形化和 ocp 部署集群,都是通过图形化页面,相对会方便很多。
区别三:从组件角度,obd 部署集群时,可选择是否部署 ocp-express,ocp-express 是一个轻量化的ocp,但是相比 ocp,还是缺少很多功能。目前生产环境也不是特别推荐使用 ocp-express。其次,ocp 自带 config_server 组件,后续如果使用 binlog 服务,则依赖于该组件,当然也可以使用 obd 再单独部署config_server 。如果使用服务名(service_name)功能,则需要依赖于 ocp;使用 oms 做数据迁移时,如果要做反向增量也是依赖于 ocp。
区别四:从运维角度,obd 部署的集群,大多情况下的运维工作只能依赖于 obd 命令行进行日常运维,包括扩缩容、节点替换、升级等,但是操作都相对比较复杂,而 ocp 通过图形化页面可快速完成。ocp 具备备份调度功能,而 obd 无法自动调度备份任务。
区别五:从监控告警角度,ocp 自带监控和告警功能,日常运维所需要的指标有对应的监控,并且告警可支持对接多个通道。提供 topsql、slowsql、可疑 sql 等信息,非常方便帮助 dba 进行问题排查,并且对有问题的 sql 可快速执行限流、绑定执行计划等。obd 部署的集群时可选择部署 prometheus 和 grafana 进行监控,或使用 ocp-express 进行监控。ocp 和 obd 部署的集群,也都支持对接 prometheus。但 ocp 会给出很多 sql 调优的建议。
区别六:从学习成本角度,ocp 上还支持展示集群拓扑图、用户管理、配置资源隔离、会话管理等非常方便的功能,而 obd 是没有的,只有命令行。对于新手来说,有 ocp 的话,可以加快上手 oceanbase 速度,降低整体学习门槛。
因此,基于以上种种因素,我们一般建议使用 ocp 来部署生产集群,后续的监控运维,都在 ocp 上进行。
一些最佳实践
介绍了最佳的部署方式,那么不论用 obd 还是 ocp 部署集群时,我们一般还需要注意哪些信息呢?这里根据社区用户的一些经验,简单做个整理。
实践一:磁盘:oceanbase 数据库存储使用的 lsm tree 架构,并且本身是一套分布式系统,节点的数据同步需要通过日志,因此对于磁盘的要求会相对高一些,这里建议至少使用 ssd 类型的磁盘。其次,oceanbase 部署时,需要指定三个目录,分别为软件安装目录(保存安装的二进制文件及集群运行日志),数据盘路径,日志盘路径(clog,也即redo log),这里也是建议三个路径分别指定到三块磁盘上以达到最高的性能。另外,日志盘我们一般也是建议配置大于oceanbase集群内存参数(memory_limit)内存三倍以上,这里主要是因为我们在分配租户资源的时候,要求租户的 log_disk_size 是租户内存的三倍。磁盘如果使用了raid,缓存模式建议用wt。
实践二:参数:在部署 oceanbase 时我们需要注意哪些参数配置。目前在 ocp4.3.2 版本中,部署集群时,我们可以选择集群的负载类型,主要根据业务场景进行判断和选择,选择对应负载类型后,会自动弹出适配对应负载类型的一些参数。另外在部署时还建议配置一些通用型的参数,具体参数名和含义如下:
参数名 | 参数解释 |
memory_limit | 表示分配给 observer 的内存大小,如果不配置,默认为 0,那么会使用 memory_limit_percentage 参数来控制分配给 observer 内存的比例,这个参数默认为 80,即默认会占用物理服务器内存的 80%。 |
system_memory | 设置 oceanbase 系统预留的内存容量,默认是 30g,对于本身服务器内存比较小的情况,这块也建议手动设置下,例如 memory_limit 和 system_memory 的比例大概可设置为 8:2,32:6,64:10,128:24,256:40。 |
devname | 设置服务进程绑定的网卡设备名,通过命令 ifconfig 可查看 ip 绑定在哪个网卡上,填写对应的网卡名称,如 eth0 |
cpu_count | 设置系统 cpu 总数,默认为 0,系统将自动检测 cpu 数量 |
datafile_size | 设置数据文件的大小,默认为 0,当为 0 的时候,会使用 datafile_disk_percentage 参数控制占用比例,如果数据与日志在同一块盘上,默认占用 60%,不同盘的情况下占用 90%。这里一般建议手动设置下,原因有二:第一,如果不设置,那么会按比例占用,占用比例比较高;第二,oceanbase 数据文件是预占用,并且无法缩小,很多用户部署完成之后会发现磁盘快占满了,但是又缩小不回去 |
datafile_next | 设置数据文件自动扩容的增长步长,默认为 0,表示不增长。如果 datafile_size 设置的比较小,后续数据增长也会比较多,建议手动设置下每次数据文件增长的大小,保证随着数据量增长,数据文件有足够空间写入。 |
datafile_maxsize | 设置数据文件自动扩容的空间最大值,默认为 0。数据文件增长到达设置这个值之后,就不会再增长。 |
log_disk_size | 设置 clog 磁盘的大小,默认 0。如果为 0,则参数 log_disk_percentage 生效,如果与数据盘同盘,则占磁盘总空间的 30%,如果不同盘,则磁盘总空间的 90%。实践一中已经说明建议的大小,可根据 memory_limit 大小进行设置。 |
enable_syslog_recycle | 用于是否打开 oceanbase 运行日志自动回收的开关,和 max_syslog_file_count 配合使用,默认为 false 不开启,不开启情况下,日志文件会不断堆积。如果有 ocp 管理平台,ocp 会自动对运行日志清理,默认在磁盘占用超过 80% 的时候,会去清理错误日志。如果没有 ocp,建议手动开启。 |
max_syslog_file_count | 设置在回收日志文件之前可以容纳的日志文件数量,oceanbase 会自动清理日志文件,最多保留 max_syslog_file_count 设置的数量。每个日志文件大小为 256mb |
ocp部署集群时,可在如下页面进行配置,打开参数设置,手动添加参数配置上面的通用型参数:
使用obd部署ocp集群时,同样也需要注意这些参数。
实践三:巡检:在部署完成生产集群之后,我们一般建议对集群再做一次健康性巡检,再次判断下部署环境是否存在参数设置不合理,或者硬件不符合条件等情况,巡检可使用 obdiag 敏捷诊断工具。具体可参考:。
集群高可用方案
确定了部署方式和一些最佳实践之后,接着就需要确定 oceanbase 集群采用什么样的高可用方案,oceanbase 的集群高可用方案相对比较灵活,因为本身采用了基于无共享(shared-nothing)的多副本架构,让整个系统没有任何单点故障,可以保证系统的持续可用。之前我们也介绍过 zone 的概念,一般我们可以把每个 zone 部署在不同的地方,例如同一个机房不同机架上,实现机架级别容灾;也可以部署在不同的机房,实现不同机房的容灾;甚至可以部署在不同的地域,实现地域级别容灾。因此高可用的建议方案有以下几种,包括:
- 同城三机房三副本
- 三地五中心五副本
- 同城两机房"主-备"部署
- 两地三中心"主-备"部署
因为社区版 oceanbase 不具备仲裁副本的能力,因此无法使用仲裁服务,关于以上几种部署方案,官方文档里有一篇专门的介绍,非常详细,可参考:。
这里需要说明一点,如果是同一个集群跨地域部署,建议地域之间的网络延迟不要太高,否则可能会带来性能问题,最好不要超过 50ms。
集群灾备方案
实际在上面介绍高可用方案的时候,已经介绍到了一种灾备方案,即使用"主-备"方式实现的灾备方案,使用的是目前 oceanbase 自带的主备租户能力,灾备方案的目的,就是当主集群出现不可用的情况下,可以启用灾备集群提供服务。
当然我们还有一些其他方式可以实现灾备方案,例如使用 oms。通过 oms,我们不但可以实现跨地域的容灾,也可以实现容灾双活,并且容灾双活不仅仅支持 oceanbase 之间的双活,还支持 mysql 和 oceanbase 之间的容灾双活。具体如果搭建容灾双活,可参考:
当然,我们还可以用一些第三方的工具来做容灾,将数据同步到其他同机房或者异地机房的oceanbase集群,例如使用 binlog 服务, flink cdc,cloudcanal 等。
集群资源规划
接着就需要规划下我们整个生产集群需要的资源大小,包括机器的数量,每台机器的配置等等。上面已经确认了生产集群的部署方案,因此我们可以根据这个方案一步步梳理下。
第一步:确认是否使用 ocp,如果不使用 ocp,用 obd 部署的话,只需要一台中控机部署 obd 即可。如果使用 ocp,则需要单独规划 ocp 的资源。ocp 包含了 ocp 程序和 ocp 的元数据库,元数据库需要使用 oceanbase 数据库,元数据库中又包含了两个租户,分别是 metadb 租户和 monitordb 租户,因此 ocp 资源的规划,首先需要考虑是否需要高可用部署,即元数据库是否多节点部署,然后 ocp 程序和元数据库是否部署在一起。其次规划每台机器的配置,ocp 的资源需求和 ocp 所接管的主机成相关性,即接管的主机越多,需要的 ocp 资源越多,官方文档在这块有详细介绍,可参考:。
第二步:生产集群磁盘规划,磁盘除了系统盘外,如果有条件,可则再挂三块盘,分别是oceanbase安装盘、数据盘、事务日志盘,当然 oceanbase 也可以安装系统盘上,三块盘大小分别为:
- oceanbase安装盘:一般建议大于 200g,空间越大,可存放的运行日志越多,后续排查问题时,减少日志被清理的概率;
- 数据盘:oceanbase 相比 mysql 具备非常高的压缩比,经过之前测试,用户也都有了一个大致的估算,目前经验值大概在 4:1 到 5:1 之间,按照这个比例,以及未来数据增长情况,可估算出一分完整数据副本大概磁盘空间占用量。另外建议这块也建议至少预留 30% 的空间,因为有些运维操作也是会占用一些磁盘空间,如创建索引、合并等,如果数据量涨到超过磁盘空间的 70%,尽快做集群的扩容;
- 事务日志盘:建议您将事务日志盘的大小设置为 oceanbase 数据库内存的 3 倍到 4 倍及以上,原因之前已经讲过,事务日志也是预占磁盘空间,会循环覆盖写。
第三步:租户 cpu 和内存配置规划,主要依赖于压测数据,上一篇文章讲到 oceanbase 的性能测试中,我们对 oceanbase 做极限的性能压测,最终可整理出一些可靠的数据,例如 8c32g 的租户规格,保证响应延迟在维持在 30ms 内,30% 写流量,70% 读流量时,最大并发数是多少,qps/tps 最高多少。通过这些数据我们就大概能给每个租户一个基本的配置规格。如果集群中规划有多个租户的话,资源需求就是每个租户的和。
第四步:机器数量规划,从两个维度,一个是租户副本数,三副本的话,至少需要三个 zone,五副本则五个 zone。另一个是每个 zone 的机器数,这里主要从每台机器的挂载数据盘大小和最大请求并发数考虑,例如业务数据单副本数据压缩后大小为 100t,每台机器挂载盘大小为 10t,那么按照每台机器数据盘实际存储 7t,单个 zone 就需要至少 15 台机器。从并发角度,如每台机器 32c128g,租户给到 24c96g 大小,压测单台 observer 最大 qps 为 10w,而业务高峰 qps 可能到 60w,假设流量均衡的情况下,那么每个 zone 至少两台observer。总的机器数 = zone 数量 * 每个zone 的 observer 数量。
如果搭建灾备,则还需要评估灾备环境的资源配置,评估的方式也基本遵循上面四步。
除了 oceanbase 集群,我们可能还会用到 oms 工具来做数据的同步,oms 使用 docker 部署,资源包括两个:一个是元数据库,一个是 docker 资源。元数据库可使用oceanbase,也可以使用 mysql,资源需求不大,一般租户或实例 2c4g 的配置即可。其次是 docker 资源,这块要看是否多节点部署,多节点也可以做到负载均衡,docker 资源需求,主要跟我们创建的同步任务数据有很大关系,具体每个任务消耗的资源可参考:。经过这些评估之后,oms 资源需求也大致清楚了。
集群监控方案
业务上线之后,我们需要对整个集群做全面的监控,因此需要提前做好监控的方案。如果使用了 ocp,那么可以直接用 ocp 上的监控,非常方便。如果没有 ocp,oceanbase all in one 包里也带了 prometheus 和 grafana,obd 部署时可选择将这两个组件一起部署上进行监控。
同时 ocp 提供了对接 prometheus 的监控方案,具体可参考:。如果需要对接到其他平台,ocp 也提供了监控的 api 接口,通过调用接口,可实现监控和告警的对接,具体可参考:。
上下游数据同步方案
很多用户的生产数据库,还存在各种数据的同步链路,包括定期向数据库中写入数据,以及将数据库中的数据同步给下游的大数据平台等。这里数据库替换成 oceanbase 之后,仍需要考虑数据的同步。
写入oceanbase数据库:
首先,向 oceanbase 中同步数据,因为 oceanbase 兼容 mysql 协议,因此大多数 mysql 生态的工具,都可以实现向 oceanbase 中同步数据,除了官方的 oms 工具,其他如 flink cdc、canal、datax、seatunnal、chunjun 等等,这块之前在mysql上用的什么工具,基本都是可以继续使用。
如果是定期向 oceanbase 中写入数据,例如将外部 csv、orc、parquet 文件等,写入到 oceanbase 数据库中,则可以使用 oceanbase 官方推荐的工具 obloader ,快速将外部文件数据导入到 oceanbase,这里的导入还支持旁路导入的方式,绕过事务层和sql层,直接将数据写入到存储层,导入速度是传统导入速度的 4-6 倍。obloader 内容,可参考:。
从oceanbase导出:
上面写入提到的工具,也是可以将 oceanbase 数据同步到其他数据库。另外,oceanbase 还提供了oblogproxy 的工具,可以使用 cdc 或者 binlog 模式,将增量数据从 oceanbase 拉取出来,其中 binlog 模式可以将 oceanbase 的日志,直接转换为兼容 mysql binlog 格式的文件,这对于后续增量数据的消费有着非常大的帮助。具体如何使用 binlog 服务,可参考:。
导出到文件,和 obloader 对应的还有 obdumper,可以直接将数据导出成文件,并支持对数据进行加工,用户可通过控制文件,对数据进行处理,具体可参考:。
数据归档需求:
对于一些用户,还会有数据归档需求,例如将线上某些表中超过三个月或者一年的数据,归档到历史库中,或者将不需要的数据进行删除,那么 oceanbase 官方工具 odc 也提供这样的功能,对数据的生命周期进行管理。数据的归档和清理,支持多种数据源,支持设置调度规则,以及归档和清理的限速等等,以下是数据归档的原理图,具体了解可参考:
生产集群切换及回滚方案
上面这些动作做完之后,就要开始动手进行迁移,选择合适的方案进行集群的部署,然后配置好对应的数据同步链路。接着就需要考虑如何将线上的业务切换到 oceanbase 数据库上,对于离线库,我们可能只需要一次数据的全量导入,然后告诉业务怎么连接新的数据库即可。对于在线库的切换,则会比较麻烦,业务停机时间可能非常短,甚至没有停机时间,这个时候就需要我们提前确定好切换步骤,每一步的操作都非常小心,防止造成线上业务不可用。一般在线业务的切换会分几个大的步骤,最好提前列一个切换的清单,在切换过程中,每做完一个操作进行一次确认。同时,还要做好回滚的方案,如果切换失败,能够快速进行回滚。这里我简单列了一个表格,大家可根据自己情况,在这基础上再做修改。
切换步骤 | 具体工作项 | 责任人确认 |
切换前 | ||
和业务再次确认 | 切换之前,再次确认具体切换时间,确认相关业务方人员在岗,建议单独拉群将涉及的人全部加入群里 | |
检查同步链路 | 切换前,检查当前生产数据库向 oceanbase 数据同步链路是否正常,同步延迟是否符合切换条件 | |
检查目标端对象 | 检查表、索引、视图、存储过程、触发器等各类对象是否全部迁移过来,这块可提前写好脚本,迁移之后运行一遍进行比对 | |
开始切换 | ||
业务端停止写入 | 防止在切换过程中,业务写入数据未同步到目标端,导致出现数据丢失 | |
确认数据库事务完成 | 确认业务端事务都执行结束,kill 业务端的连接会话,关闭业务端连接,防止数据写入 | |
确认数据同步完成 | 确认所有数据已经同步到目标端数据库 | |
修改业务连接/修改代理 | 如果使用了 dns 或 vip 等,则修改代理的 ip,使其解析到 obproxy 对应的 ip,如果业务使用 jdbc 连接数据库,则修改业务的连接串 | |
开启反向增量同步 | 为了防止切换后出现异常需要回滚,可将 oceanbase 数据再反向同步到原数据库,oms 支持反向增量功能 | |
业务开始写入 | 切换完成之后,通知业务开始写入数据,然后观察数据库监控,包括 qps、响应延迟、cpu 使用率等,确保数据库运行正常 | |
切换结束后 | ||
确认业务是否正常 | 运行一段时间之后,和业务确认运行状况 | |
再次确认数据库状态 | 检查是否存在慢 sql、日志是否存在错误,可用 obdiag 对日志进行快速分析 | |
失败回滚 | ||
方案1 | 如果使用 oms,并且做了反向增量,这个时候如果业务反馈有问题,需要回滚到原数据库,那么可按照上面的步骤,快速回滚回去 | |
方案2 | 如果因为各方面限制,无法开启反向增量,也可以使用 binlog 模式,将 oceanbase 的增量数据转换为binlog,业务需要回滚的话,可迅速将这部分增量数据写入到原数据库,保证数据一致 |
以上大致是一个在线业务有停机窗口的情况下的切换方案,实际上业务的切换场景可能会比这个更复杂,例如业务可能没有停机窗口的情况下,应该如何切换等等。这里其实最重要的就是提前规划好方案,以及想好如何应对各种突发状况,这样我们在实际切换过程中,才不至于手忙脚乱,造成事故。
日常运维手册及sop整理
在集群上线之后,接下来更多的工作就是对集群的日常维护,包括 sql 优化、日常变更、故障处理、问题定位等等方面的工作,这些工作也是非常体现 dba 价值的,需要我们日常不断的积累。
为了加快大家对 oceanbase 的学习,我在这里也整理了一些材料,方便大家日常的学习:
最直接的就是官方文档:
当然还有很多其他工具的介绍,这里我就不罗列了,感兴趣可以直接登陆网站: 查看,组件文档整理如下:
还有就是一些实践课程,这里官方的同学整理了一套 oceanbase 的入门到实践教程,基于当前最新 4.x 版本的,里面有视频课程,教大家怎么一步步部署、测试、迁移、调优等等,是一个非常不错的入门教程,传送门:oceanbase dba 从入门到实践。
另外就是官方整理的一些日常管理和排错的知识库,里面的内容非常干货,我们日常遇到的很多问题,在上面都可以找到解决办法,平时也可以多浏览浏览,增强我们的运维能力,传送门:。
我也整理了一篇,当集群出现紧急情况时,我们怎么快速恢复服务,减少业务停服时间。我们都知道线上如果出现故障,最先做的就应该是快速恢复业务,然后再去定位问题,最后再复盘查漏补缺,这篇文章是个人的一些总结,大家有更好应急方式,欢迎留言。
oceanbase 官方也提供了考试认证,分了 obca、obcp、obce 三个级别,大家对认证感兴趣的,也可以登陆认证中心进行学习和考试,其中 obca 提供了线上视频课程,传送门:。另外多说一句,这些认证都是可以抵税的哦。