万字长文，如何正确测试oceanbase-c7电子娱乐

目前社区很多用户在调研了 oceanbase 之后，对 oceanbase 的架构以及理念有比较高的认同，因此也想尝试进行测试，以及后续将部分业务迁移到 oceanbase 上。但是对于很多 dba 来说，这里想要进行异构数据库的替换，并不是件容易的事，如果没有完整的测试以及回滚方案的设计，可能会导致业务切换到新的数据库上之后，出现意想不到的问题，那个时候再回滚，也得是伤筋动骨，甚至导致业务短期不可用。所以怎么能确保业务上线后不出问题，这就需要进行完整的测试，包括兼容性、功能、性能等各个方面。另外，在业务上线之前，如果做了比较好的回滚预案，即使迁移到新的数据库之后出现问题，也能快速平滑切回到原数据库，保证业务不出现长时间不可用。

那么如何才能一步一步稳扎稳打，把数据库从之前的 mysql、postgresql、tidb 等，做到低风险甚至无风险的切换到 oceanbase 呢？这里我分了两遍文章来做一个介绍，第一篇主要介绍如何对 oceanbase 进行全面测试；第二篇则介绍如何进行生产集群方案设计、生产切换及回滚方案设计等。具体总结为以下重要环节，大家基本只要做好这些环节，我想替换数据库的风险可以降低不少。主要整理如下：

第一篇：

• 熟悉oceanbase数据库
• 适用场景
• 架构特点
• 设计完整的测试方案
• 兼容性测试
• 功能性测试
• 性能测试
• 高可用能力测试
• 弹性伸缩能力测试
• 灾备能力测试
• 相关工具测试
• 管理工具测试
• 迁移工具测试
• 开发者工具测试

第二篇：

• 生产集群规划
• 集群部署方式
• 一些最佳实践
• 集群高可用方案
• 集群灾备方案
• 集群资源规划
• 集群监控方案
• 上下游数据同步方案
• 生产集群切换及回滚方案
• 日常运维手册及 sop 整理

接下来，我们就先进入第一篇文章，一步一步展开介绍，如何去做 oceanbase 的测试工作。

熟悉oceanbase数据库

使用一款数据库，首先就需要了解这款数据库能帮我解决什么问题，或者能否实现成本降低、效率的提升等，否则数据库的替换纯属浪费时间。因此，这里首先从两方面做个概括，一个是适用场景，介绍 oceanbase 能帮助我们解决什么样的问题；一个是架构特点，介绍 oceanbase 的一些基础概念，在后续测试的时候，就不是完全黑盒的进行测试了。在了解了这些之后，我想是否需要进行替换就有了清晰的目标。

适用场景

oceanbase 目前主打七大场景c7电子娱乐的解决方案，分别是以下七个方案：

1. 历史库：oceanbase 使用 lsm tree 的存储架构，底层采用行列混存的模式，可以在保证高性能情况下，有效对数据进行高比例的压缩，节省大量磁盘空间，对比传统关系型数据库，如 mysql、postgresql 等，磁盘占用量单副本最低可以达到 mysql 的 10% - 20%；
2. 多租户：社区很多用户在使用 mysql 的时候，会选择在一台大服务器上部署多个 mysql 实例，从而提升服务器的资源使用率，但是存在一个问题就是多个实例之间无法做资源的约束，可能导致一个 mysql 实例资源使用过量而影响到其他 mysql 实例。oceanbase 在这里提供了多租户的能力，租户之间实现了 cpu、内存、iops 的硬隔离，从而保证租户之间不受影响，保证业务稳定性，并且租户资源可灵活调整；
3. 原生高可用：oceanbase 基于 paxos 分布式一致性协议，在部署时可选择两地三中心三副本或者三地五中心的方式部署，paxos 协议可以保证在少数副本出现故障的情况下，对业务无影响，自动实现 leader 的切换，并且可以做到 rpo = 0、rto < 8s。而 mysql 等数据库的高可用，需要使用第三方工具来实现，引入复杂的架构，并且切换时效等方面，无法和原生高可用比拟。
4. 高并发能力：oceanbase 作为一款分布式关系型数据库，具备很好的线性扩展能力，包括计算和存储能力。通过在集群的 zone 中添加服务器，或者增加更多的 zone，都可以很好的扩展集群。理论可以达到无限个节点，目前最大集群也超过千台。
5. 实时数仓：oceanbase 4.3 版本推出列存能力，以及 2.0 版本的向量化查询执行引擎，可以有效提升 ap 分析的效率，clickbench 性能测试超越 clickhouse。并且推出了更多 ap 能力，包括物化视图、旁路导入、外表&联邦查询、列存副本、大查询队列、资源组等，帮助用户更方便的做 ap 分析。对比传统 ap 分析，需要将 tp 数据库数据同步到 ap 数据库之后再做计算，这种数据时效性也存在很大问题，而一套 oceanbase集群即可以跑 tp、也可以跑 ap ，因此可以做到数据实时的查询分析。
6. 多模能力：oceanbase 支持多模能力，即 obkv，obkv 是构建在 oceanbase 分布式存储引擎之上的 nosql 产品系列，支持 obkv-table、obkv-hbase、obkv-redis 三种产品形态，原生继承了 oceanbase 的高性能、事务、分布式、多租户、高可靠的基础能力。在不引入新的组件情况下，可平滑替换hbase、redis、kv 等。
7. 向量检索：oceanbase 4.3 版本引入了向量检索能力，可平滑替换 milvus 等向量数据库，在不引入新的组件情况下，完全复用现有 ob 运维平台和工具，提供 sql 接口和 python api 接口，支持多种索引类型，目前在性能方面，ann-benchmarksgist-960 排名第一。

针对以上场景的介绍，我想各位在数据库替换这块应该已经有一些预期了，如果目前在实际生产中遇到了这些场景中的问题，例如归档库数据量太大、业务要求的高可用达不到要求、或者高并发场景数据库撑不住、目前数据库团队维护的数据库种类太多等等，都可以考虑使用 oceanbase 来进行替换。

架构特点

进一步需要了解下 oceanbase 的架构特点，这样在后续测试、业务设计的时候，就能很好的做出选择，从而充分发挥 oceanbase 的性能，让大家真正感觉到好用。

oceanbase 的主体架构如下图，主要包含两个组件：轻量化无状态的路由组件 obproxy，以及包含计算和存储能力的 observer，oceanbase 采用的无共享（shared-nothing）分布式集群架构。下图是一个典型的三副本部署架构，包含三个 obproxy、三个 zone，每个 zone 包含两台 observer。

oceanbase 的概念相对较多，这里需要介绍几个概念帮助大家尽快熟悉：

zone：zone 是一个逻辑概念，一个 zone 里可以包含一台或多台 observer，每个 zone 可以部署在不同的机架、机房或者地域；

tenant：tenant 即租户，每个租户可以理解为一个 mysql 实例。租户的数据分布在集群的 observer 节点上，一个 zone 最多只能包含该租户的一份完整的数据副本，如果租户是三副本，则需要至少三个 zone 的集群。

unit：租户在 observer 节点上的容器，描述租户在 observer 上的可用资源（cpu、memory 等）。一个租户在一个 observer 只能同时存在一个 unit。

unit_num：即租户的数据在每个 zone 中 unit 数量，同时也可以理解为占 zone 中 observer 的数量，如果为1，则只在该 zone 中的一个 observer 上有这个租户的数据，以此类推。租户需要扩容时，可调大该参数。

partition：表分区的逻辑概念，是划分和管理表数据的一种机制。用户可以进行多种分区管理操作，包括：创建、删除、truncate、分裂、合并、交换等。

tablet：分片，表示实际的数据存储对象。它支持在机器之间迁移（transfer），是数据均衡的最小单位。tablet 与分区一一对应，单分区表会创建一个 tablet，多分区表会为每个分区创建一个 tablet。索引表的每个分区也会对应一个 tablet，包括局部索引表和全局索引表。特别地，局部索引表的 tablet 与主表 tablet 会强制绑定，保证存储在一台机器上。

logstream：日志流（logstream，ls）是由 oceanbase 数据库自动创建和管理的实体，它代表了一批数据的集合，包括若干 tablet 和有序的 redo 日志流。它通过 paxos 协议实现了多副本日志同步，保证副本间数据的一致性，实现了数据的高可用。日志流副本支持在不同机器之间迁移（migration）和复制（replication），以达到机器管理和系统容灾的目的。

从数据存储的角度来看，日志流可以抽象为 tablet 容器，支持添加和管理 tablet 数据，允许 tablet 在不同日志流之间转移（transfer），以达到数据均衡和水平扩展的目的。

从事务的角度来看，日志流是事务的提交单位。事务修改在单个日志流内完成时可以采用一阶段原子提交；事务修改跨多个日志流时，采用 oceanbase 数据库优化的两阶段提交协议完成原子提交，日志流是分布式事务参与者。

locatity：租户的日志流在各个 zone 上的副本分布和类型称为 locality，可以通过建租户指定 locality 的方式决定租户下日志流初始的副本类型和分布。

primary zone：即租户下日志流的 leader 分布，用户可指定分布在特定的 zone 内，也可以设置为 random，表示 leader 均匀分布在多个 zone 上，日志流内所有 leader 副本会接受所有的强一致性读写，将 leader 打散分布之后，可以有效将并发流量均衡到多台 observer 上，但是对于跨表或跨分区事务，可能导致更多的分布式事务。

介绍了这么多概念，可能有些头晕，这里我们其实最终要达到的目的，就是怎么样使用 oceanbase，才能发挥出它最好的性能。

这里举一个例子，让大家对这些概念有个更清晰的认识。现有一个业务想迁移到 oceanbase，之前在mysql，使用了分库分表中间件进行了数据的拆分，希望迁移到 oceanbase 之后，期望成本能够降低，高可用和扩展能力增强，并且不再维护分库分表中间件。

首先为了保证高可用，需要部署至少三个 zone 的集群，每个 zone 可以选择部署在相同或不同的地理位置，从而保证数据多副本的高可用能力。其次每个 zone 中至少包含一台 observer。集群部署完成之后，默认会有个 sys 租户，这里不建议用 sys 租户跑业务，需要手动创建一个业务租户。创建租户时，总共分三步：

第一步需要先创建租户的 unit 配置，即租户的 cpu、memory、log_disk、iops 等参数。

第二步接着创建资源池 resource_pool，创建资源池时，需要指定使用哪个 unit 配置模版、unit_num 数量、以及资源池分布在哪些 zone 中，即 zone_list。

第三步再创建租户，指定租户的 primary zone、使用哪个资源池、租户的 locality 信息、连接白名单等信息。

primary zone 表示日志流 leader 分布，日志流包含了 tablet，tablet 和 partition 一一对应，因此日志流的 leader 就代表了分区的 leader。如果 primary zone 使用的 random 模式，那么三个 zone 中的分区 leader 数量基本是均衡的。例如原 mysql 业务总共有 100 张表，那么每个 zone 中的表 leader 数据大致就是 33 个左右，同时如果每个 zone 只有一台 observer，默认情况下，这 33 张表 leader 也会在同一个日志流里，那么三个 zone 就会有三个日志流。

但是这样会存在一个问题，因为有的表很大，上亿行，而有的表很小，只有几千行，这就会导致 leader 虽然均衡了，但是数据访问的请求并没有均衡，如果大表的并发量很高，而小表的并发量很少，那么从监控中就可以看到业务的访问貌似集中到一个 zone 的某个 observer 上。另外这样也会导致后续想对集群扩容，一个 zone 里有多台 observer 的时候，想把这张大表数据拆分到多个 observer 上的想法成为了不可能。

因此，这里在使用 oceanbase 的时候，我们就会建议对表做分区（关于如何优雅的分区，这里会有另一篇文章来介绍）。对表做了分区之后，因为数据的均衡是以分区为粒度，假设一张大表分了 24 个分区，那么这里 24 个分区的 leader，会自动打散到三个 zone 中，每个 zone 就会有 8 个分区 leader，当 zone 中只有一个 observer 的时候，这 8 个 leader 都在这个 observer 上。如果集群扩容，每个 zone 中添加一个 observer，那么这 8 个 leader，会均衡到同 zone 中的两台 observer 上，即每个 observer 上 4 个分区 leader。这样的话，就很好的实现了集群的线性扩展。同时因为数据分布到了多个 observer 上，也能充分发挥 oceanbase 集群的并行计算的能力。

obproxy 的作用，就是帮助业务请求快速定位到具体的 observer，obproxy 会缓存分区 leader 信息，特别对于点查这种场景，可以快速的将业务请求转发到对应分区 leader 所在的 observer 上。

以上就是对 oceanbase 的架构和概念做了一个简单介绍，有了这些概念之后，后续我们业务测试，就能根据业务特点，清楚知道如何去做规划租户和表分区。当然这里还有很多其他概念，包括 table group、lsm tree、执行计划缓存等等，感兴趣的话，大家可以登录 oceanbase c7电子娱乐官网进一步了解。

设计完整的测试方案

好了，上面介绍了一大堆概念性的东西，接着就要开始真正的对 oceanbase 进行测试验证了，要测试一款数据库，首先就是要考虑到兼容性的测试。

兼容性测试

宏观层面，兼容性主要讲的协议层面的兼容，具体是兼容 mysql、oracle、还是 postgresql 等协议层面。目前 oceanbase 社区版，主要兼容的是 mysql 协议。而 oceanbase 企业版，既兼容了 mysql 协议，也兼容了 oracle 协议。考虑到社区大多用户都是 mysql，因此下面的测试主要对比 mysql。

微观层面，兼容性则讲的是对数据类型、sql 语法、字符集等基本类型，以及各种数据库对象，包括视图、存储过程、触发器、函数、包、序列等对象的兼容能力。

兼容性的测试其实相对比较简单，我们不需要非常详细的去对比 mysql 和 oceanbase-mysql 在每个细节上的不同，这个工作量也非常庞大，目前 oceanbase-mysql实际上和 mysql 的兼容能力已经超过95%。但是我们一般还是会对这块去做下测试，这样心里才有底，特别是从非 mysql 协议的数据库迁移过来的。

兼容性测试这里有两个方案：

方案一：将源数据库的数据和对象，通过数据迁移工具，同步到 oceanbase 一份，然后检查是否存在数据库字符集、数据类型、索引、视图、表结构等方面兼容情况。数据迁移工具这块，目前 oceanbase 官方提供 oms 工具，可实现数据的全量迁移、增量同步、全量校验以及正向切换、反向同步功能，使得整体的迁移会变得非常简单，同时也支持部分对象的迁移，如视图等。另外还有很多其他的工具也可以做这块的迁移，例如 datax、flink cdc、canal、seatunnel 等。对于其他对象，可在源端数据库收集各类对象的 sql，然后再目标端手动创建，来判断是否兼容。

方案二：使用官方提供的 oma 工具，连接源端数据库，对源端数据库所有对象的兼容性进行评估，最终出具一份评估报告。

这里我用一张表格的方式，详细介绍下 oceanbase 和 mysql 数据库的兼容情况，以及如果遇到兼容性问题，如何解决，好让大家有个大致了解：

与mysql兼容性对比，官方文档也有一篇文章做了专门的介绍，感兴趣可以参考下：

功能性测试

接下来就需要对数据库的功能进行测试，功能性的测试涵盖范围也比较广，这里和兼容性测试一样，根据业务实际情况来进行测试，有些功能不涉及的，可以不需要去完整测试。

同样我也以表格的方式，列出一些我们日常对数据库做功能测试时，会涉及到的一些项目，供各位参考。功能方面的验证，目前在工具层面会相对较少，因此大多情况下，需要人工去一项项验证：

当然，功能的验证还会有很多，包括数据压缩、读写分离、全链路诊断、集群监控等等，这里不再单独展开介绍。但是因为 oceanbase 架构原因，以及特有的一些能力，包括多租户、列存、obkv 等，这些功能的验证，大家可以参考官方文档，进行一步步的验证。

性能测试

兼容性和功能验证结束之后，就是大家比较关心的性能测试。替换一款数据库，很多时候性能因素可能占比超过 90% 的比例，性能主要关注的就是响应延迟、请求并发。

响应延迟，即一条 sql 从业务请求到返回业务的耗时，对比原数据库是否有明显的减少。另外也会关注响应延迟的 p99 或 p95 分位是否稳定，如果不稳定，就说明数据库的延迟抖动明显，这会导致业务时快时慢，有时难以接受。

请求并发，则表示同一时刻，数据库可以处理的请求数，请求并发跟很多因素都有关系，数据库隔离级别，业务模型是否存在大量锁冲突等等。并发越高，响应延迟越低，则说明数据库的性能越好。

性能的测试，目前主要有几种方式：

第一种：使用通用的测试方案，这几种测试方案，可以快速的对数据库性能做出一个评价。

第二种：使用压测平台对数据库进行压测。一般稍大一些的公司都会有测试团队和压测平台，那么就可以联系测试团队配合，模拟一个业务场景，模拟实际生产的流量，然后不断按比例增长请求的并发数，直到数据库出现明显的响应延迟增长。然后记录对应的响应延迟和最大并发。

当然这样还不是结束，因为数据库的架构不同，有些 sql 可能到新的数据库上就会存在一些性能问题，一般情况下，我们还需要对整个压测进行复盘，检查压测期间各资源使用情况，包括 cpu 使用率、磁盘 io 情况、请求队列情况、等待事件类型、等待事件耗时等等，来判断具体是什么原因导致了在当前最高并发情况下，响应延迟的明显增加。

另外还需要检查数据库的 topsql 和 slowsql 情况，看下这些 sql 的执行是否符合预期，包括 sql 的执行计划、扫描行数、扫描分区数、rpc 请求次数等等，然后针对不符合预期的 sql 检查是否有可优化的地方。

当然以上复盘的这些指标，在 ocp 平台上都可以很方便的看到，因此还是强烈建议大家使用 ocp。这里我简单截了两张图，可以一目了然看到整个压测期间的性能指标。

最后，oceanbase 官方还提供了 obdiag 敏捷诊断工具，支持对 oceanbase 集群进行巡检，检查是否存在配置不合理的地方，并且支持一件信息收集和一件根因诊断，这对我们排查性能问题有很大帮助，关于工具的介绍和使用，可参考：

第三种：就是业务从接入层复制一份流量，然后通过双写的方式对数据库性能进行测试。这块的话需要业务的开发人员来配合一起完成。然后将一部分读流量转发到 oceanbase 数据库上，来对比两个数据库的性能差异。同样，针对 slowsql，也需要进行分析和优化。

通过上面不断的压测和复盘，经过几轮下来，基本可以得到一个真实的性能测试结果。同时我想大家对 oceanbase 数据库的熟悉程度也会有很大的提升。在这过程中，也可以不断总结一些运维经验，后续上线遇到之后就不会手忙脚乱。

高可用能力测试

oceanbase 作为一款分布式数据库，高可用能力可谓是它的强项，不需要依赖第三方组件，原生就具备高可用能力。oceanbase 底层基于 multi-paxos 实现多副本数据同步以及集群的高可用，可保证 rpo=0，rto<8s，即在少数派副本出现故障的情况下，可以做到数据不丢失，8s 之内完成副本选举并提供服务。关于 oceanbase 的高可用能力介绍，可参考：

高可用的测试场景相对简单，并且因为 oceanbase 只有 obproxy 和 observer 两个组件，我们只需要模拟日常我们会遇到的一些场景，然后分别对 obproxy 和 observer 进行测试即可，我想到的有以下这些场景可作为参考：

• 进程异常退出，拉起进程
• 进程异常挂起，重启进程
• 服务器故障，重启或替换服务器
• 磁盘故障，替换节点或替换磁盘
• 交换机故障，重启交换机
• 机房故障，机房恢复
• ...

那么在模拟这些故障同时，则需要对数据库高可用能力进行判断，我简单列举几个判断标准作为参考：

• 出现故障后，业务受损范围和恢复时长
• 出现故障后，请求并发和响应延迟受到的影响
• 出现故障后，数据是否出现丢失情况
• 故障恢复后，响应延迟和并发能否恢复
• 故障恢复后，受损的数据副本能否继续同步数据并在同步完成后提供服务
• ...

通过上面几个标准的判断，大概就能评估出这套数据库系统整体的高可用能力。

弹性伸缩能力测试

弹性伸缩能力即数据库的可扩展能力。从业务方的角度来看，就是随着我业务不断增长，能否在不影响响应延迟的情况下，提供更高的并发能力和存储能力；亦或是在一些类似大促场景时，能够快速扩展整个集群的并发访问能力，在大促结束后，可以快速缩回去。而对于 dba 来说，这种需求就是能否快速通过加减机器或调整租户资源的方式，实现数据库的计算和存储资源线性可扩展。

oceanbase 的扩展能力主要体现在几个方面：

1. 集群级别的扩展能力，集群的每个 zone 通过添加 observer 的方式，或者直接通过添加 zone 的方式，实现集群资源池级别的扩展。特别是在多租户场景下，集群资源扩展之后，可将一部分租户的资源均衡到新的机器上，从而降低集群中原 observer 上的压力；
2. 租户级别的扩展能力，首先在当前集群资源足够的情况下，可通过修改租户的 unit 配置或者 unit_num，快速实现租户的资源扩展。其次，若是集群资源已经分配完毕，可以通过增加机器，将租户的一部分数据均衡到新的机器上，实现租户的计算和存储能力线性扩展。
3. 还有就是 oceanbase 目前支持单机部署，后续业务量上涨之后，可平滑扩展为分布式数据库。

这些扩展的操作，官方文档中都有详细的操作步骤，可按照这些步骤对集群进行扩缩容测试，主要步骤有：

• 添加和删除 observer
• 添加和删除 zone
• 修改租户 unit 配置
• 修改租户 unit_num
• 单机扩展分布式

而我们主要关注的则应该是这些操作对业务的影响，主要指标可总结如下：

• qps/tps 影响：扩缩容操作是否会导致并发降低
• 响应延迟影响：扩缩容操作是否影响 sql 响应延迟抖动
• 请求失败率：扩缩容操作是否会明显增加业务请求失败率
• 扩展能力：扩容之后，请求并发是否可以线性增长
• 自动化程度：扩缩容操作的步骤是否复杂，以及是否平滑
• ...

通过上面这些标准，就可以基本判断出一个数据库的扩缩容能力是否符合我们预期

灾备能力测试

灾备能力一般则指的是数据库的故障逃逸能力，虽然 oceanbase 是一款分布式数据库，但是在一些极端情况下，可能会导致集群不可用，例如多数派故障。这个时候，业务又急于恢复，依赖于备份恢复可能由于数据量大的情况，恢复时间比较久，甚至小时级别。因此就需要有一个备的集群，能够快速拉起提供服务。

那么 oceanbase 就提供了一个物理备库的能力，类似于 mysql 的主从复制，不过这里不同的是，oceanbase 实时同步是物理的 redo 日志，而 mysql 同步的是 binlog，因此 oceanbase 的同步效率会比 mysql 高很多，延迟要低。

物理备库是租户级别的，如下图，两个集群之间的租户是可以互为主备的。

物理备库还提供了无损切换（rpo = 0）和有损切换（rpo > 0）两种容灾能力。

具体物理备库的搭建和切换，可参考官方文档：，另外 obproxy 层也提供了服务名(service_name) 功能，业务连接数据库的时候，可通过服务名进行连接，屏蔽后面的主备租户关系，当发生主备租户切换后，业务可以无感知的连接到新的主租户上继续访问。之前我也写过一篇文章介绍，可参考：

灾备的测试场景相对比较简单，即集群正常情况下的无损切换(switchover)和集群异常情况下的切换(failover)，判断标准主要是以下两个：

• 业务恢复时长，rto
• 数据丢失情况，rpo

另外灾备的搭建，也可以依赖于 oceanbase 官方提供的 oms 工具，实时将数据从一个集群同步到另一个远程机房的集群中。

相关工具测试

一款数据库周边工具的完善程度，可以侧面反应出这款数据库的成熟程度。oceanbase 为用户提供了几个非常好用的工具，这些工具的测试不是必须的，但是对后续帮助我们使用 oceanbase 起到了非常大的作用，分别是企业级管理平台 ocp、一站式数据传输和同步工具 oms、企业级数据库协同开发工具 odc，另外还有导数工具 ob-loader-dumper 和敏捷诊断工具 obdiag。

工具平台的测试方法，没有什么特殊之处，主要体现在功能性和易用性，需要我们自己部署起来，然后一个一个的去测试，每个功能具体操作步骤，官方文档都已经有详细说明，这里就不展开讲了，主要介绍下功能。

管理工具

企业级管理平台 ocp 平台，是一个可视化的图形管理平台，提供 oceanbase 集群的全生命周期管理。下面用表格方式列了一下整体的功能：

详细关于ocp平台了解，可参考：

迁移工具

一站式数据传输和同步工具 oms，可将异构数据库数据，通过 oms 同步到 oceanbase 数据库，也可将 oceanbase 数据同步到其他异构数据库或消息队列。oms 的测试，对于我们后续设计迁移方案会有很大的影响，因此一般也是测试的重点。功能特点如下：

详细关于 oms的 介绍，可参考：

数据迁移的测试，需要我们手动去搭建工具和创建迁移任务。这块我们的测试目标主要就是功能的验证和测试迁移速度是否满足我们的需求，从而为后续业务真正上线做准备。这里我之前也写过一篇关于《》的博客，如有遇到迁移大表特别慢的情况，可以参考下

开发者工具

企业级数据库协同开发工具 odc，帮助我们快速进行数据库开发。这里面的功能也非常丰富，包括各种 sql开发的功能，数据导入导出，测试数据模拟，数据的生命周期管理，数据脱敏与审计，数据归档等等。

这里因为和我们数据库选型关系不是很大，所以就不展开介绍，感兴趣可以直接查看官方文档：。

以上这些内容就是在替换 oceanbase 之前，如何对 oceanbase 进行全面测试的一个整理，当然这里只是根据个人经验总结的一些测试方法，因此也非常欢迎大家一起来补充和完善这个测试流程，帮助后续想要迁移到 oceanbase 数据库的社区小伙伴们有一个非常好的参考资料。接下来，我会再写一篇介绍如何规划生产集群以及介绍一些切换方案。感兴趣的同学可以继续移步下一篇文章。