OceanBase v4.3特性解析：新功能“租户克隆”的场景与应用指南

OceanBase数据库官方博客

于 2024-05-14 12:05:10 发布

阅读量1.3k

点赞数 17

CC 4.0 BY-SA版权

文章标签： oceanbase 分布式数据库技术原理租户克隆

本文链接：https://blog.csdn.net/OceanBaseGFBK/article/details/138729064

熟悉或曾用过OceanBase的朋友，对于“多租户”这一理念定不陌生。OceanBase的租户概念，与我们熟知的传统数据库实例颇为相似。举例来说，OceanBase的租户支持MySQL兼容模式，对于用户而言，选用一个MySQL兼容模式的租户，就如同用一个MySQL数据库实例。

OceanBase 4.3 版本在已有的多租户架构基础上，新增了功能——租户克隆，本文将向大家介绍租户克隆的应用场景和使用方法。

租户克隆功能是什么？

当我们需要使用 OceanBase 数据库时，会在一台或多台机器上拉起 OceanBase 进程，这些进程会组成 OceanBase 集群。在这个集群中，我们可以创建出需要的租户。单个 OceanBase 集群中可以创建出多个租户，租户间互相隔离。

如下图所示，在 OceanBase 的系统租户下执行该克隆语句，就可以对指定的源租户快速克隆出一个新租户。新克隆租户在初始时刻包含的数据，就是源租户在语句执行时刻的一个快照。

1715306009

租户克隆操作可以快速把源租户的元数据信息，拷贝一份，给到新克隆租户来使用。初始时刻，新克隆租户访问的是和源租户完全相同的物理宏块。宏块，就是上图中画的 Macro Block，是 OceanBase 中基础的数据存储单元。

因为克隆过程只拷贝了元数据，而不是拷贝数据，克隆操作可以快速完成。

该新克隆租户与源租户是两个独立的租户，他们之间保持了 OceanBase 一直以来的租户隔离特性，存在严格的数据隔离和资源隔离。新克隆租户的任何数据改动，都不会影响到源租户；源租户的数据改动，也不会影响到新克隆租户。新克隆租户与源租户具有自己独占的 CPU、内存、IOPS 资源，不相互抢占。

租户克隆功能可以做什么？

如果大家在使用OceanBase的过程中遇到以下六种场景，租户克隆功能就会发挥它的价值。

1715306018

场景一：报表任务。

业务正在大促，卖得非常好，数据库运行平稳，但已处于满载状态。老板非常高兴，走到值班室，问技术团队要一个当前整体销售情况的报表。这时候，是选择冒着被“广进”的风险跑这个报表任务呢？还是选择对满脸期待的老板进行下预期管理呢？如果最终决定运行这个报表任务，当前这种情况下，又该开多大的并发度来跑大查询呢？

这时就可以利用租户克隆技术，快速基于生产租户克隆出一个新的报表租户，用新克隆出来的报表租户执行在线数据分析任务。

从 OceanBase 4.3 版本开始，支持行列混合存储，如果源租户是行列混存结构，克隆得到的新租户也是行列混存结构，可以良好支持 AP 负载。

场景二：快弹只读备租户。

生产租户压力很大，同时内部运营系统，还会发送不那么确定的复杂查询负载。我们希望将这些来自内部的复杂查询负载，从生产租户上快速移走。

这时就可以利用租户克隆技术，快速基于生产租户克隆出一个新租户，让这个新租户作为生产租户的备租户。新租户会主动去生产租户上拉取日志，提供一个准实时的弱读服务。

如此一来，我们就可以将内部运营系统的复杂查询负载，快速转移到这个新的只读备租户中。

场景三：应用版本发布。

不少应用的版本发布流程，都是先备份数据库，再更新应用版本。若这次应用版本发布出现问题，就用发布前的那个数据库备份，来还原数据库，最终实现整体版本发布的回退。备份数据库及用备份来恢复数据库，在数据量增大后都变得特别慢，导致整个版本发布过程执行时间特别长。

为了最小化版本发布对生产经营的影响，版本发布大多选择在凌晨进行，同时为了应对各类突发情况，整个版本发布过程时常需要相关同学现场值守。发版时间太长，一方面对业务生产经营产生影响，另一方面会让参与同学倍感疲倦。

租户克隆技术就可以在一定程度上解决这个问题。首先在版本正式发布前，可以基于生产租户克隆出一个预发测试租户，用这个预发测试租户来做最后的版本预发验证。版本发布的第一个流程，利用租户克隆技术，对生产租户克隆出一个小规格的临时备份租户。如果版本发布出现问题，就可以用这个临时备份租户，克隆出新的生产租户，来将数据库还原到版本发布之前。

因为租户克隆过程执行得很快，可以大幅度减少版本发布需要的执行时间。