作者简介:
车东兴:于阳光保险就职,深耕保险行业的 IT 领域长达12 年,对保险领域的基础架构实践有深刻的理解与掌握。熟悉多款数据库,具有丰富的数据库运维经验。
王华城:于阳光保险就职,10多年一直从事 MySQL 数据库的运维工作,在本地及云上数据库部署运维经验丰富,近年来对与 MySQL 兼容的数据库进行了深入研究并积累运维经验。
业务背景
阳光保险集团自2005年7月创立以来,已成功发展出包括财产保险、人寿保险、信用保证保险及资产管理等在内的多家专业子公司,其成长速度在全球市场化企业中名列前茅,现在在中国保险行业中稳居前八。随着数字化升级浪潮的持续推进,众多企业纷纷寻求将软硬件升级为满足自主研发需求的产品,作为基础软件的三大支柱之一的数据库,亦成为此次升级热潮中的一项重要内容。
在数字化升级的大背景下,阳光保险集团根据业务需求,展开了数据库选型与升级工作。其一,了解分布式数据库,为未来业务增长做技术储备;其二,在数据库适配且满足业务需求的同时,尽可能降低软件、硬件的开销。
经过深入调研和测试多款产品后,我们选择了 OceanBase。主要有以下四方面原因:
第一,满足关键业务升级需求。OceanBase 是一款完全自研的分布式数据库,且在 2021 年开源了核心代码,非常符合我们当前的关键业务升级需求。
第二,稳定可靠。整套系统稳定运行已经超过 2 年, 数据 0 丢失 ,使用上让我们越发安心和信任。从技术上,OceanBase 基于 Paxos 协议实现的多副本容灾方案,少数派故障时能够达到 RPO = 0,RTO < 8s 的高可用能力;从业务上看, OceanBase 已连续支撑十余年双 11,经过了大量金融领域的核心系统打磨,性能和可靠性已经久经考验。
第三,高度兼容MySQL。兼容性是我们最关注的一点,因为集团业务中很多搭载在 MySQL 上,如果兼容性不足,不仅迁移和改造的成本高,还需要协调业务方配合做改造,非常麻烦。所以引入新技术或替换新产品,要保证无缝、平滑的迁移,尽可能减少改造成本。
第四,多租户管理多套业务。我们在 MySQL 上的业务非常多,虽然业务的访问量和数据量都不是很大,但多套 MySQL 对应多个不同的业务,需要大量的管理和运维工作。OceanBase 的原生多租户能力很好解决了这个问题,大幅降低运维管理复杂度。
业务收益
在经过前期的测试以后,我们将已有的业务逐步迁移到 OceanBase。我们线上 MySQL 环境以 5.6 版本 和 5.7 版本 为主,使用OceanBase数据迁移工具 OMS 可以直接创建同步链路,自动将 MySQL 数据迁移到 OceanBase,且未出现任何兼容性问题,使整个迁移过程非常便捷、顺利,无形中节省了大量迁移成本。
我们部署了 OceanBase 3.1.5 版本,配置为单台物理机器 128C768G 。目前在 OceanBase 开了 22 个租户,把分布在 MySQL 多个实例上的多套业务迁移至 OceanBase 后分配到不同的租户,这样每个业务单独使用自己的租户资源,互不影响。同时实现了高可用,简化了运维管理。
(一)多租户及资源隔离,提升资源利用率,保证数据安全
OceanBase 的多租户特性解决了很多小型业务搭载在 MySQL 上的运维复杂问题。租户是一个逻辑概念,通过租户实现资源隔离,并通过权限控制保证租户的数据安全性,对于系统运维,尤其是对云数据库的运维有着重要的积极影响。租户在一定程度上相当于传统数据库的"实例"概念。OceanBase 的租户间是完全隔离的,从根本上解决跨租户的数据访问风险,以确保用户的数据资产不被其他租户访问。因此,我们可以将多个 MySQL 实例上的业务迁移到一套 OceanBase 上,将不同业务放置于对应租户即可,完全不用担心数据安全。另外,租户是资源分配的单元,可以根据业务情况设置资源规则,使机器资源得到充分利用。下图是我们的租户资源配置。
(二)高可用保障业务稳定运行,数据零丢失,无需人工干预
我们使用 MySQL 时是一主多从架构,其自身没有高可用能力,以至于在一些复杂的大型业务场景,稳定性问题是需要我们格外关注的,特别是当核心业务的主节点异常甚至宕机时,可能需要人工干预处理,比如手动切换,并通过解析 Binlog 补齐数据。这种方式在一定程度上能解决问题,但风险高而且很不方便。使用 OceanBase 后,我们基于 Paxos 协议实现的多副本容灾方案,在三副本情况下,即使挂掉一个副本也不会对上层业务造成影响,少数派故障时能够达到 RPO = 0,RTO < 8s 的高可用能力。
(三)生态丰富/运维方便
对 DBA 来说,数据库运维工具的便捷度影响其工作是否高效的重要因素。OceanBase 运维管理工具 OCP 提供了图形化管理能力,包括数据库及相关资源的全生命周期管理、监控告警、性能诊断、故障恢复、备份恢复等,帮助我们更加高效地管理 OceanBase 数据库,降低企业的 IT 运维成本和学习成本。于我们而言,有三个功能是值得一提的。
其一,通过界面即可概览数据库基本情况及集群性能。对数据库运维人员来说,经常会出现业务 SQL 响应变慢的问题,需要分析是哪个节点的哪个 SQL 变慢了,通过 OCP 可以直观看到 TOP SQL 和慢 SQL,需要的信息都可以快速展示。
其二,扩缩容更简单。在 MySQL 环境上加从节点时需要修改各种参数,甚至可能需要重启服务,而在 OCP 只需要对租户进行简单配置就能实现快速不停机在线扩缩容。
其三,备份恢复更方便。当需要恢复到指定时间点时,MySQL 也能实现,不过操作比较麻烦,需要找到对应 Binlog 文件,然后在命令行里指定解析的文件和需要恢复的时间点;而在 OCP 上只需白屏选中需要恢复的时间点即可。
我们也用过其他企业提供的数据管理平台,最直观感受的就它们大多功能简单,使用复杂,而 OCP 功能丰富,使用简单,真的好用。
实践经验
迁移至 OceanBase 后为企业带来的收益是显而易见,在 OceanBase 的落地过程中也有一些经验分享。
- 自增列使用习惯:OceanBase 3.1.x 版本自增列跳号是不连续的,在 MySQL 数据库中自增列是唯一、递增的值,用来标识数据的唯一性。相比 MySQL 这种集中式数据库,作为分布式数据库的 OceanBase 将数据分布在不同的机器上,为了保证高度兼容 MySQL 的同时不损失分布式系统自增列生成的性能,会出现自增列生成过程中跳号不连续的问题。不过,这对我们的业务影响不大,自增列只要保证唯一即可。
- 原地升级:由于我们使用的是 OceanBase 3.1.5 版本,无法直接原地升级到 4.x 版本,类似 Oracle 早期版本的升级方式,需要在切换环境时迁移、同步数据。
写在最后
我们使用 OceanBase 已经有两年时间,生产系统集群一直稳定运行。随着 OceanBase 4.x 版本的持续更新,我们了解到其 OLAP 能力和数据压缩能力更强,且 MySQL 兼容性大幅提升。因此,我们计划将大数据量的业务迁移到 OceanBase 4.x 版本,使硬件使用成本进一步缩减。未来,也将根据公司关键业务升级需求的推进情况,将更多业务迁移至 OceanBase。