深圳雨棚制作,深圳 网站优化公司排名,学做软件的网站有哪些,报ui设计班熟悉或曾用过OceanBase的朋友#xff0c;对于“多租户”这一理念定不陌生。OceanBase的租户概念#xff0c;与我们熟知的传统数据库实例颇为相似。举例来说#xff0c;OceanBase的租户支持MySQL兼容模式#xff0c;对于用户而言#xff0c;选用一个MySQL兼容模式的租户对于“多租户”这一理念定不陌生。OceanBase的租户概念与我们熟知的传统数据库实例颇为相似。举例来说OceanBase的租户支持MySQL兼容模式对于用户而言选用一个MySQL兼容模式的租户就如同用一个MySQL数据库实例。
OceanBase 4.3 版本在已有的多租户架构基础上新增了功能——租户克隆本文将向大家介绍租户克隆的应用场景和使用方法。
租户克隆功能是什么
当我们需要使用 OceanBase 数据库时会在一台或多台机器上拉起 OceanBase 进程这些进程会组成 OceanBase 集群。在这个集群中我们可以创建出需要的租户。单个 OceanBase 集群中可以创建出多个租户租户间互相隔离。
如下图所示在 OceanBase 的系统租户下执行该克隆语句就可以对指定的源租户快速克隆出一个新租户。新克隆租户在初始时刻包含的数据就是源租户在语句执行时刻的一个快照。 租户克隆操作可以快速把源租户的元数据信息拷贝一份给到新克隆租户来使用。初始时刻新克隆租户访问的是和源租户完全相同的物理宏块。宏块就是上图中画的 Macro Block是 OceanBase 中基础的数据存储单元。
因为克隆过程只拷贝了元数据而不是拷贝数据克隆操作可以快速完成。
该新克隆租户与源租户是两个独立的租户他们之间保持了 OceanBase 一直以来的租户隔离特性存在严格的数据隔离和资源隔离。新克隆租户的任何数据改动都不会影响到源租户源租户的数据改动也不会影响到新克隆租户。新克隆租户与源租户具有自己独占的 CPU、内存、IOPS 资源不相互抢占。
租户克隆功能可以做什么
如果大家在使用OceanBase的过程中遇到以下六种场景租户克隆功能就会发挥它的价值。 场景一报表任务。
业务正在大促卖得非常好数据库运行平稳但已处于满载状态。老板非常高兴走到值班室问技术团队要一个当前整体销售情况的报表。这时候是选择冒着被“广进”的风险跑这个报表任务呢还是选择对满脸期待的老板进行下预期管理呢如果最终决定运行这个报表任务当前这种情况下又该开多大的并发度来跑大查询呢
这时就可以利用租户克隆技术快速基于生产租户克隆出一个新的报表租户用新克隆出来的报表租户执行在线数据分析任务。
从 OceanBase 4.3 版本开始支持行列混合存储如果源租户是行列混存结构克隆得到的新租户也是行列混存结构可以良好支持 AP 负载。
场景二快弹只读备租户。
生产租户压力很大同时内部运营系统还会发送不那么确定的复杂查询负载。我们希望将这些来自内部的复杂查询负载从生产租户上快速移走。
这时就可以利用租户克隆技术快速基于生产租户克隆出一个新租户让这个新租户作为生产租户的备租户。新租户会主动去生产租户上拉取日志提供一个准实时的弱读服务。
如此一来我们就可以将内部运营系统的复杂查询负载快速转移到这个新的只读备租户中。
场景三应用版本发布。
不少应用的版本发布流程都是先备份数据库再更新应用版本。若这次应用版本发布出现问题就用发布前的那个数据库备份来还原数据库最终实现整体版本发布的回退。备份数据库及用备份来恢复数据库在数据量增大后都变得特别慢导致整个版本发布过程执行时间特别长。
为了最小化版本发布对生产经营的影响版本发布大多选择在凌晨进行同时为了应对各类突发情况整个版本发布过程时常需要相关同学现场值守。发版时间太长一方面对业务生产经营产生影响另一方面会让参与同学倍感疲倦。
租户克隆技术就可以在一定程度上解决这个问题。首先在版本正式发布前可以基于生产租户克隆出一个预发测试租户用这个预发测试租户来做最后的版本预发验证。版本发布的第一个流程利用租户克隆技术对生产租户克隆出一个小规格的临时备份租户。如果版本发布出现问题就可以用这个临时备份租户克隆出新的生产租户来将数据库还原到版本发布之前。
因为租户克隆过程执行得很快可以大幅度减少版本发布需要的执行时间。
场景四数据库变更。
这是 DBA 同学经常遇到的场景。比如研发同学找到你帮忙调整一个索引并且告诉你这个变更在测试环境已经验证了很久了绝对没问题。结果你一执行完索引变更数据库 CPU 直接就飙到100%同时你发现如果要将之前的索引重新构建出来至少要6个小时。
这时租户克隆机制就可以帮你解决这个问题具体做法和应用版本发布的操作类似。
场景五快速构建开发测试环境。
当前我们的代码已经可以通过像 git 这样的工具被分支化管理比如你要做一个 bugfix你可以快速拉出一个 bugfix 分支并在分支上编写代码。但是整个研发过程不光是编码还有测试验证。测试验证时常需要基于主干测试库构建出一个分支测试库。主干测试库可能很大进而构建这个分支测试库耗时很长最终导致编码 5 分钟搭建测试环境 5 个小时的情况。
租户克隆技术就可以解决这个问题快速从主干测试租户中克隆一个分支测试租户以支持分支的测试验证。
场景六数据导出。
部分时候我们需要将数据库中大量的表数据按 csv 格式导出到对象存储中以供下游的大数据分析系统使用。由于担心影响线上生产服务不敢开太大的导出并发导致导出速度缓慢。
这时可以利用克隆功能克隆出一个新的导出租户用这个新的导出租户来执行数据导出任务尽可能地减少对生产租户的影响。
租户克隆如何实现
租户克隆的过程大致分为两个步骤。第一个步骤是对源租户创建一个 crash-consistent snapshot第二个步骤是基于 crash-consistent snapshot 拉起新克隆租户。可以看到整体的克隆流程都是围绕着这个 snapshot 进行的。
下面依次介绍两个步骤的执行。
如何在一个 shared-nothing 的分布式数据库中创建 crash-consistent snapshot如下图所示在分布式数据库基础模型中单个数据库具有多个完全对等的节点。每个节点都有自己的内存缓存持久化的日志文件及持久化的数据文件。正常更新的时候数据修改都是在内存中进行并在必要时将日志持久化到日志文件中。后台会有定时的checkpoint 任务将内存中修改过的数据刷写到数据文件中同时记录下宕机重启时回放日志的起始位点即 checkpoint 点。多个节点间通常会有一个高可靠高可用的全局时间戳服务用来保证分布式数据库整体的外部一致性。 基于分布式数据库中已有的这些组件和机制快照创建的过程大致分为如下三个步骤
第一步记录下各个节点当前的 checkpoint 位点。
第二步备份各个节点的数据文件的元数据通过元数据找到需要的数据。
第三步通过全局时间戳服务确定最终的一致性快照位点。
上述步骤执行完成后各个节点保留下来的数据文件加上各个节点从 checkpoint 位点到 snapshot 位点的日志文件就构成了一个 crash-consistent snapshot。后续我们就可以基于这个 crash-consistent snapshot拉起新的克隆租户。
新克隆租户的各个节点会通过之前保留下来的数据文件获得到初始数据同时每个节点会继续回放从 checkpoint 位点到 snapshot 位点的日志这样所有节点在克隆执行完成之后都会将自身的状态准确的更新到 snapshot 位点。
整个租户克隆的步骤都是非阻塞的不会阻塞源租户正常的SQL 执行。
下图描述了租户克隆在 OceanBase 中的具体实现。 日志部分我们利用了 OceanBase 已有的归档日志机制来实现克隆过程中日志数据的保留和管理。新克隆租户的各个节点拉起之后会访问源租户的归档日志读取并回放从 checkpoint 位点到 snapshot 位点的日志数据从而将各个节点的状态统一更新到 snapshot 位点。
数据部分从 OceanBase 4.0 版本开始数据以 Tablet 的形式来组织Tablet 会引用自己需要的物理宏块数据最终存储在各个物理宏块中。克隆过程会拷贝源租户各个 Tablet 的元数据生成新克隆租户的元数据并且递增各个关联到的物理宏块的引用计数。
一致性快照位点通过 OceanBase 的全局时间戳服务 GTS来生成一致性快照位点。
租户克隆操作方法
前置准备。
租户克隆功能依赖于日志归档需要对源租户开启日志归档才可以对该租户执行租户克隆。并且在租户克隆语句的执行期间不可以关闭源租户的日志归档。
租户克隆语句。
CREATE TENANT new_tenant_name FROM source_tenant_name WITHRESOURCE_POOL [] resource_pool_name,UNIT [] unit_config
new_tenant_name新克隆租户名
source_tenant_name源租户名
resource_pool_name表示资源池的名称租户克隆时将会自动根据源租户的资源分布为新租户创建出资源池
unit_config新克隆租户 resource pool 的 unit 规格
可以在系统租户下执行该语句为指定租户创建出一个新的克隆租户。这个新克隆租户的 unit 数量以及 unit 在各个 observer 上的分布均与源租户保持一致。可以在语句中指定新克隆租户单个 unit 的规格。
-- 基于 mysql 租户当前状态创建克隆租户 clone_tenant
-- 该语句自动创建出的 resource pool 名为 clone_tenant_pool其各个 UNIT 规格为 S1_unit_config
CREATE TENANT clone_tenant FROM mysqlWITHRESOURCE_POOL clone_tenant_pool,UNIT S1_unit_config;
租户克隆速度。
源租户新克隆租户克隆租户操作执行时间8核64G单日志流包含 50w tablet数据量 1TB。8核64G2min
新克隆租户使用。
租租户克隆任务执行完成后得到的新克隆出的租户为只读租户。
既可以将该新克隆租户继续作为只读租户提供相关服务又或者可以将该新克隆租户设置为源租户的备租户亦或者可以通过 ALTER SYSTEM ACTIVATE STANDBY TENANT new_tenant_name将新克隆租户转为可读可写的主租户提供服务。
如上文中提到的该新克隆租户与源租户之间存在严格的数据隔离和资源隔离。
租户克隆任务。
当在系统租户下执行租户克隆语句时该语句会生成对应的克隆任务clone job。可以通过 DBA_OB_CLONE_PROGRESS 和 DBA_OB_CLONE_HISTORY 视图查看克隆任务的执行状态PROGRESS 表中包含当前正在执行的 clone jobHISTORY 表中包含执行完成的 clone job。
相关字段
列名类型含义CLONE_JOB_IDbigint(20)主键克隆任务 idTRACE_IDvarchar(64)克隆任务 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 配置名RESTORE_SCNbigint(20) unsigned克隆租户的目标回放位点STATUSvarchar(64)克隆任务的当前状态CLONE_JOB_TYPEvarchar(16)克隆任务的当前状态RESTORE - 基于租户历史快照克隆租户FORK - 基于租户当前状态克隆租户CLONE_START_TIMEtimestamp(6)克隆任务开始时间CLONE_FINISHED_TIMEtimestamp(6)克隆任务结束时间RET_CODEbigint(20)克隆任务返回值ERROR_MESSAGEvarchar(512)克隆任务失败时的提示信息允许为空
示例
MySQL [(none)] select * from oceanbase.DBA_OB_CLONE_PROGRESS\G
*************************** 1. row ***************************CLONE_JOB_ID: 1702211800546509768TRACE_ID: YA4740B7C050F-00060C210F4A4848-0-0SOURCE_TENANT_ID: 1004SOURCE_TENANT_NAME: mysqlCLONE_TENANT_ID: 1016CLONE_TENANT_NAME: clone_tntTENANT_SNAPSHOT_ID: 1702211800802135214
TENANT_SNAPSHOT_NAME: _inner_snapshot$1702211800702058206RESOURCE_POOL_ID: 1008RESOURCE_POOL_NAME: clone_tnt_poolUNIT_CONFIG_NAME: box8RESTORE_SCN: 1702211802014048020STATUS: CLONE_SYS_CREATE_TENANTCLONE_JOB_TYPE: FORKCLONE_START_TIME: 2023-12-10 20:36:40.551169CLONE_FINISHED_TIME: NULLRET_CODE: NULLERROR_MESSAGE: NULL
1 row in set (0.00 sec)MySQL [(none)] select * from oceanbase.DBA_OB_CLONE_HISTORY where CLONE_JOB_ID 1702211800546509768\G
*************************** 1. row ***************************CLONE_JOB_ID: 1702211800546509768TRACE_ID: YA4740B7C050F-00060C210F4A4848-0-0SOURCE_TENANT_ID: 1004SOURCE_TENANT_NAME: mysqlCLONE_TENANT_ID: 1016CLONE_TENANT_NAME: clone_tntTENANT_SNAPSHOT_ID: 1702211800802135214
TENANT_SNAPSHOT_NAME: _inner_snapshot$1702211800702058206RESOURCE_POOL_ID: 1008RESOURCE_POOL_NAME: clone_tnt_poolUNIT_CONFIG_NAME: box8RESTORE_SCN: 1702211802014048020STATUS: CLONE_SYS_SUCCESSCLONE_JOB_TYPE: FORKCLONE_START_TIME: 2023-12-10 20:36:40.551169CLONE_FINISHED_TIME: 2023-12-10 20:37:53.919247RET_CODE: 0ERROR_MESSAGE: NULL
1 row in set (0.01 sec)
取消租户克隆任务。
可以通过执行 ALTER SYSTEM CANCEL CLONE new_tenant_name 语句以取消一个正在执行的克隆任务该语句会显式的将对应的克隆任务切换到 CANCELING 的状态执行完成后置为CANCELED状态同时当该克隆任务被取消之后其申请的各类资源都会被自动释放。
若在该 ALTER SYSTEM CANCEL CLONE new_tenant_name 语句执行之前新克隆租户已经实际执行完成了克隆操作切换到了正常服务状态则该 CANCEL 语句不会被执行。
示例
MySQL [(none)] alter system cancel clone clone_tnt;
Query OK, 0 rows affected (0.02 sec)MySQL [oceanbase] create tenant clone_tnt from mysql with resource_poolclone_tnt_pool,unitbox8;
ERROR 12004 (HY000): clone job has been canceledMySQL [(none)] select * from oceanbase.DBA_OB_CLONE_HISTORY where CLONE_JOB_ID1702212525544202404\G
*************************** 1. row ***************************CLONE_JOB_ID: 1702212525544202404TRACE_ID: YA4740B7C050F-00060C210F4A4859-0-0SOURCE_TENANT_ID: 1004SOURCE_TENANT_NAME: mysqlCLONE_TENANT_ID: 0CLONE_TENANT_NAME: clone_tntTENANT_SNAPSHOT_ID: 1702212525756306747
TENANT_SNAPSHOT_NAME: _inner_snapshot$1702212525656187169RESOURCE_POOL_ID: 1009RESOURCE_POOL_NAME: clone_tnt_poolUNIT_CONFIG_NAME: box8RESTORE_SCN: 18446744073709551615STATUS: CLONE_SYS_CANCELEDCLONE_JOB_TYPE: FORKCLONE_START_TIME: 2023-12-10 20:48:45.544031CLONE_FINISHED_TIME: 2023-12-10 20:48:51.070501RET_CODE: -4072ERROR_MESSAGE: clone job has been canceled
1 row in set (0.00 sec)
执行完“取消克隆租户”命令后该 clone_tenant 对应的克隆任务切换到 CLONE_SYS_CANCELED 的状态该克隆任务申请的各类资源比如租户快照、资源池以及处于克隆状态的租户都会被自动释放。
注意事项。
源租户和新克隆租户在初始状态下是共享物理宏块后续随着源租户的写入新克隆租户的写入以及二者的迁移调度和故障恢复等事件的发生会使得两个租户共享的宏块逐步减少独占宏块逐步增多存储空间使用量逐步增加。
租户克隆特点
租户克隆功能加速了任务执行效率的同时降低了任务带来的风险总的来说该功能具有以下4个特点。
特点1快。租户克隆过程中只拷贝元数据信息不拷贝数据信息使得租户克隆操作可以快速完成。在我们的测试环境中8核64G 的源租户包含 50w tablet1TB 数据克隆出一个 8c64g 的新租户可以在 2min 内完成。
特点2易。只需要在系统租户中执行一条租户克隆语句就可以完成租户克隆操作。同时 OceanBase 的租户克隆是完全实现在数据库内核中不需要外部存储系统的支持只需要在平时用的机器上拉起OceanBase 4.3 版本的进程就可以用上租户克隆功能。
特点3稳。租户克隆过程不会阻塞源租户正常的 SQL 执行。克隆出的新租户和源租户是两个完全独立的租户存在严格的数据隔离和资源隔离不会互相影响。
特点4省。新克隆租户会尽可能的和源租户共享宏块最大限度的节省存储资源。
更多关于租户克隆的信息可参见官网文档
