。

OceanBase的租户概念#xff0c;与我们熟知的传统数据库实例颇为相似。

举例来说#xff0c;OceanBase的租户支持MySQL兼容模式#xff0c;对于用户而言#xff0c;选用一个MySQL兼容模式的租户对于“多租户”这一理念定不陌生。

OceanBase的租户概念与我们熟知的传统数据库实例颇为相似。

举例来说OceanBase的租户支持MySQL兼容模式对于用户而言选用一个MySQL兼容模式的租户就如同用一个MySQL数据库实例。

OceanBase

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

当我们需要使用

的系统租户下执行该克隆语句就可以对指定的源租户快速克隆出一个新租户。

新克隆租户在初始时刻包含的数据就是源租户在语句执行时刻的一个快照。

租户克隆操作可以快速把源租户的元数据信息拷贝一份给到新克隆租户来使用。

初始时刻新克隆租户访问的是和源租户完全相同的物理宏块。

宏块就是上图中画的

Macro

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

OceanBase

一直以来的租户隔离特性存在严格的数据隔离和资源隔离。

新克隆租户的任何数据改动都不会影响到源租户源租户的数据改动也不会影响到新克隆租户。

新克隆租户与源租户具有自己独占的

CPU、内存、IOPS

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

业务正在大促卖得非常好数据库运行平稳但已处于满载状态。

老板非常高兴走到值班室问技术团队要一个当前整体销售情况的报表。

这时候是选择冒着被“广进”的风险跑这个报表任务呢还是选择对满脸期待的老板进行下预期管理呢如果最终决定运行这个报表任务当前这种情况下又该开多大的并发度来跑大查询呢

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

OceanBase

版本开始支持行列混合存储如果源租户是行列混存结构克隆得到的新租户也是行列混存结构可以良好支持

生产租户压力很大同时内部运营系统还会发送不那么确定的复杂查询负载。

我们希望将这些来自内部的复杂查询负载从生产租户上快速移走。

这时就可以利用租户克隆技术快速基于生产租户克隆出一个新租户让这个新租户作为生产租户的备租户。

新租户会主动去生产租户上拉取日志提供一个准实时的弱读服务。

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

不少应用的版本发布流程都是先备份数据库再更新应用版本。

若这次应用版本发布出现问题就用发布前的那个数据库备份来还原数据库最终实现整体版本发布的回退。

备份数据库及用备份来恢复数据库在数据量增大后都变得特别慢导致整个版本发布过程执行时间特别长。

为了最小化版本发布对生产经营的影响版本发布大多选择在凌晨进行同时为了应对各类突发情况整个版本发布过程时常需要相关同学现场值守。

发版时间太长一方面对业务生产经营产生影响另一方面会让参与同学倍感疲倦。

租户克隆技术就可以在一定程度上解决这个问题。

首先在版本正式发布前可以基于生产租户克隆出一个预发测试租户用这个预发测试租户来做最后的版本预发验证。

版本发布的第一个流程利用租户克隆技术对生产租户克隆出一个小规格的临时备份租户。

如果版本发布出现问题就可以用这个临时备份租户克隆出新的生产租户来将数据库还原到版本发布之前。

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

DBA

同学经常遇到的场景。

比如研发同学找到你帮忙调整一个索引并且告诉你这个变更在测试环境已经验证了很久了绝对没问题。

结果你一执行完索引变更数据库

CPU

直接就飙到100%同时你发现如果要将之前的索引重新构建出来至少要6个小时。

这时租户克隆机制就可以帮你解决这个问题具体做法和应用版本发布的操作类似。

git

分支并在分支上编写代码。

但是整个研发过程不光是编码还有测试验证。

测试验证时常需要基于主干测试库构建出一个分支测试库。

主干测试库可能很大进而构建这个分支测试库耗时很长最终导致编码

分钟搭建测试环境

租户克隆技术就可以解决这个问题快速从主干测试租户中克隆一个分支测试租户以支持分支的测试验证。

csv

格式导出到对象存储中以供下游的大数据分析系统使用。

由于担心影响线上生产服务不敢开太大的导出并发导致导出速度缓慢。

这时可以利用克隆功能克隆出一个新的导出租户用这个新的导出租户来执行数据导出任务尽可能地减少对生产租户的影响。

租户克隆如何实现

snapshot如下图所示在分布式数据库基础模型中单个数据库具有多个完全对等的节点。

每个节点都有自己的内存缓存持久化的日志文件及持久化的数据文件。

正常更新的时候数据修改都是在内存中进行并在必要时将日志持久化到日志文件中。

后台会有定时的checkpoint

任务将内存中修改过的数据刷写到数据文件中同时记录下宕机重启时回放日志的起始位点即

checkpoint

点。

多个节点间通常会有一个高可靠高可用的全局时间戳服务用来保证分布式数据库整体的外部一致性。

基于分布式数据库中已有的这些组件和机制快照创建的过程大致分为如下三个步骤

checkpoint

第二步备份各个节点的数据文件的元数据通过元数据找到需要的数据。

checkpoint

新克隆租户的各个节点会通过之前保留下来的数据文件获得到初始数据同时每个节点会继续回放从

checkpoint

位点的日志这样所有节点在克隆执行完成之后都会将自身的状态准确的更新到

snapshot

已有的归档日志机制来实现克隆过程中日志数据的保留和管理。

新克隆租户的各个节点拉起之后会访问源租户的归档日志读取并回放从

checkpoint

会引用自己需要的物理宏块数据最终存储在各个物理宏块中。

克隆过程会拷贝源租户各个

Tablet

的元数据生成新克隆租户的元数据并且递增各个关联到的物理宏块的引用计数。

OceanBase

租户克隆功能依赖于日志归档需要对源租户开启日志归档才可以对该租户执行租户克隆。

并且在租户克隆语句的执行期间不可以关闭源租户的日志归档。

CREATE

resource_pool_name表示资源池的名称租户克隆时将会自动根据源租户的资源分布为新租户创建出资源池

unit_config新克隆租户

可以在系统租户下执行该语句为指定租户创建出一个新的克隆租户。

这个新克隆租户的

unit

既可以将该新克隆租户继续作为只读租户提供相关服务又或者可以将该新克隆租户设置为源租户的备租户亦或者可以通过

ALTER

new_tenant_name将新克隆租户转为可读可写的主租户提供服务。

如上文中提到的该新克隆租户与源租户之间存在严格的数据隔离和资源隔离。

当在系统租户下执行租户克隆语句时该语句会生成对应的克隆任务clone

DBA_OB_CLONE_HISTORY

列名类型含义CLONE_JOB_IDbigint(20)主键克隆任务

Trace

IdSOURCE_TENANT_IDbigint(20)源租户

idSOURCE_TENANT_NAMEvarchar(128)源租户名称CLONE_TENANT_IDbigint(20)克隆租户

idCLONE_TENANT_NAMEvarchar(128)克隆租户名称TENANT_SNAPSHOT_IDbigint(20)快照

idTENANT_SNAPSHOT_NAMEvarchar(128)快照名RESOURCE_POOL_IDbigint(20)克隆租户资源池

idRESOURCE_POOL_NAMEvarchar(128)克隆租户资源池名UNIT_CONFIG_NAMEvarchar(128)克隆租户

unit

unsigned克隆租户的目标回放位点STATUSvarchar(64)克隆任务的当前状态CLONE_JOB_TYPEvarchar(16)克隆任务的当前状态RESTORE

基于租户历史快照克隆租户FORK

基于租户当前状态克隆租户CLONE_START_TIMEtimestamp(6)克隆任务开始时间CLONE_FINISHED_TIMEtimestamp(6)克隆任务结束时间RET_CODEbigint(20)克隆任务返回值ERROR_MESSAGEvarchar(512)克隆任务失败时的提示信息允许为空

MySQL

oceanbase.DBA_OB_CLONE_PROGRESS\G

row

***************************CLONE_JOB_ID:

YA4740B7C050F-00060C210F4A4848-0-0SOURCE_TENANT_ID:

1702211800802135214

_inner_snapshot$1702211800702058206RESOURCE_POOL_ID:

clone_tnt_poolUNIT_CONFIG_NAME:

box8RESTORE_SCN:

CLONE_SYS_CREATE_TENANTCLONE_JOB_TYPE:

2023-12-10

20:36:40.551169CLONE_FINISHED_TIME:

NULLRET_CODE:

***************************CLONE_JOB_ID:

YA4740B7C050F-00060C210F4A4848-0-0SOURCE_TENANT_ID:

1702211800802135214

_inner_snapshot$1702211800702058206RESOURCE_POOL_ID:

clone_tnt_poolUNIT_CONFIG_NAME:

box8RESTORE_SCN:

CLONE_SYS_SUCCESSCLONE_JOB_TYPE:

2023-12-10

20:36:40.551169CLONE_FINISHED_TIME:

2023-12-10

语句以取消一个正在执行的克隆任务该语句会显式的将对应的克隆任务切换到

CANCELING

的状态执行完成后置为CANCELED状态同时当该克隆任务被取消之后其申请的各类资源都会被自动释放。

若在该

语句执行之前新克隆租户已经实际执行完成了克隆操作切换到了正常服务状态则该

CANCEL

resource_poolclone_tnt_pool,unitbox8;

ERROR

CLONE_JOB_ID1702212525544202404\G

row

***************************CLONE_JOB_ID:

YA4740B7C050F-00060C210F4A4859-0-0SOURCE_TENANT_ID:

0CLONE_TENANT_NAME:

_inner_snapshot$1702212525656187169RESOURCE_POOL_ID:

clone_tnt_poolUNIT_CONFIG_NAME:

box8RESTORE_SCN:

CLONE_SYS_CANCELEDCLONE_JOB_TYPE:

2023-12-10

20:48:45.544031CLONE_FINISHED_TIME:

2023-12-10

的状态该克隆任务申请的各类资源比如租户快照、资源池以及处于克隆状态的租户都会被自动释放。

源租户和新克隆租户在初始状态下是共享物理宏块后续随着源租户的写入新克隆租户的写入以及二者的迁移调度和故障恢复等事件的发生会使得两个租户共享的宏块逐步减少独占宏块逐步增多存储空间使用量逐步增加。

租户克隆特点

租户克隆功能加速了任务执行效率的同时降低了任务带来的风险总的来说该功能具有以下4个特点。

特点1快。

租户克隆过程中只拷贝元数据信息不拷贝数据信息使得租户克隆操作可以快速完成。

在我们的测试环境中8核64G

50w

特点2易。

只需要在系统租户中执行一条租户克隆语句就可以完成租户克隆操作。

同时

OceanBase

的租户克隆是完全实现在数据库内核中不需要外部存储系统的支持只需要在平时用的机器上拉起OceanBase

4.3

执行。

克隆出的新租户和源租户是两个完全独立的租户存在严格的数据隔离和资源隔离不会互相影响。

特点4省。

新克隆租户会尽可能的和源租户共享宏块最大限度的节省存储资源。