作者简介：
**车东兴：**于阳光保险就职，深耕保险行业的 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。