逻辑集群概述

基本概念

逻辑集群是通过Node Group机制来实现资源和数据的隔离。通过把物理集群的所有物理节点划分成多个逻辑集群，每个逻辑集群本质上是一个Node Group，每个物理节点只能属于一个逻辑集群，用户数据表只能分布在一个逻辑集群范围内。这样不同逻辑集群的用户数据是隔离的，逻辑集群所属节点的资源主要提供给逻辑集群内数据表的操作，同时供其他逻辑集群的作业交互查询使用。企业将不同的业务部署在不同的逻辑集群上，既可以实现业务统一管理，也能保证业务之间数据隔离和资源隔离。

逻辑集群从物理节点层次将大集群进行划分，和数据库形成交叉。一个数据库中的表可以按逻辑集群来分配到不同的物理节点，而一个逻辑集群也可以包含多个数据库的表。在划分逻辑集群后，整个数据库中对象间的层次关系如图1所示。

其中Elastic_group弹性集群是指在逻辑集群模式下，非逻辑集群节点组成的集群并且总是存在，是一个特殊的Node Group，可以包含多个或不包含任何DN节点。弹性集群不能用户手动创建，在物理集群下第一次创建逻辑集群时自动创建弹性集群，物理集群中所有不属于逻辑集群的物理节点都会加入弹性集群。后续逻辑集群创建所需的DN节点都是来自弹性集群中。因此，为了能够创建新的逻辑集群，需要保证弹性集群中有DN节点存在（在物理集群模式下第一次创建逻辑集群时不需要）。用户可以通过扩容向弹性集群添加新的物理节点。

图1 逻辑集群、数据库、表层次关系

• 逻辑集群仅支持8.1.0.100及以上集群版本。
• 在实际业务场景中，建议用户尽可能将同一个数据库的表创建到同一个逻辑集群中。
• 逻辑集群不是独立子集群，可以实现数据隔离，资源隔离和权限隔离，但不支持独立运维。
• 逻辑集群不支持经典变更规格。
• 物理集群切换逻辑集群时，如果原物理集群有数据则不支持切换。用户请确保切换时原物理集群数据为空。

逻辑集群架构

图2展示了物理集群划分成多个逻辑集群的架构示意图。物理集群的所有节点被分成多个逻辑集群节点组。业务用户1和业务用户2的作业分别在不同的逻辑集群上执行。用户1和用户2可以在本逻辑集群内部定义资源池来控制不同作业的资源（CPU，内存，I/O）。如果业务用户1的某些作业需要访问业务用户2的数据，在获得授权后可以跨逻辑集群访问。逻辑集群可以配置跨逻辑集群访问的资源来保证逻辑集群内部作业的资源充足。

图2 逻辑集群架构

将物理集群的所有节点分成多个逻辑集群，每个子集群都可以根据业务情况定义资源池。由于用户表不会跨逻辑集群分布，如果业务不跨逻辑集群访问，业务之间就不存在资源竞争。同一逻辑集群内部的作业可以通过资源池来分配资源。如果某些业务需要访问其他逻辑集群的数据，可以跨逻辑集群访问，被访问的逻辑集群可以对来自其他逻辑集群的访问请求进行资源控制，以减少对逻辑集群内部作业的资源竞争。

用户在创建完成物理集群后就要确定是否划分逻辑集群，如果在划分逻辑集群前已经创建了用户表，由于这些用户表已经分布在所有物理节点，就无法再划分逻辑集群了，具体限制条件请参见约束和限制。对于已经在使用的集群（例如8.1.0.100之前版本构建的数据库集群），如果希望转换为逻辑集群管理，可以在集群升级到支持逻辑集群（8.1.0.100及以上版本）后，将整个集群全部节点转换为一个逻辑集群。然后通过添加新节点对物理集群扩容，并在新增节点上创建新的逻辑集群。

逻辑集群支持如下管理操作：

• 添加/删除逻辑集群：
  • 添加逻辑集群：物理集群转换为逻辑集群后，可指定逻辑集群名称和物理节点列表，将这些物理节点划分为一个逻辑集群。
  • 删除逻辑集群：删除指定名称的逻辑集群，逻辑集群删除后释放的节点会落入弹性集群中。
• 管理逻辑集群：
  • 编辑逻辑集群：根据需求向逻辑集群中添加节点或减少节点。
  • 资源管理（逻辑集群模式）：对指定逻辑集群进行资源管理（仅8.1.3.x及以上集群版本支持）。
  • 扩容逻辑集群：该操作将扩大逻辑集群物理节点数目，并对逻辑集群内的表进行重分布到扩容后的物理节点上。
  • 重启逻辑集群：该操作将逻辑集群包含的所有DN重新启动，考虑到对整个物理集群的影响，逻辑集群并不支持单独的停止和启动。
  • 缩容逻辑集群：从弹性集群中选择指定的主机环，缩容选定的主机环。
• 弹性增删逻辑集群：支持在计划时间段内，动态创建、删除计算逻辑集群，实现计算资源动态伸缩。

约束和限制

• 逻辑集群的创建、扩容和缩容必须以环为单位，最少3个物理节点，DN的主备从必须在同一环所包含的物理节点内。
• 逻辑集群切换期间，如果原物理集群有数据，则会进行锁集群操作。用户可执行增删改查等简单DML语句，但执行操作数据库对象等复杂DDL语句会阻塞业务出现报错，请谨慎操作。
• 逻辑集群不支持单独备份和恢复。
• 逻辑集群不支持单独升级。
• 物理集群转换为逻辑集群模式之后不支持回退到物理集群。
• 逻辑集群模式下，只能创建逻辑集群，不支持创建普通的NodeGroup，逻辑集群内部也不支持创建子NodeGroup。
• 逻辑集群的OM操作（创建、删除、编辑、扩容、缩容、重启）不支持并行执行。
• 由于公共数据库对象（除系统表之外的表、外表和视图）会分布在物理集群所有节点，当某个逻辑集群节点重启后，其他逻辑集群对这些公共数据库对象进行的DDL操作将会中断。
• 在逻辑集群模式下，由于每个DN只包含所属逻辑集群下的表，而自定义函数要在所有DN上创建，因此创建的函数体中不能使用%type引用表字段类型。
• 在逻辑集群模式下，WITH RECURSIVE语句不支持下推。
• 在逻辑集群模式下，只有在相同逻辑集群下支持交换分区，不同逻辑集群下的分区表和普通表不支持交换分区。
• 在逻辑集群模式下，创建函数时如果函数参数或返回值有表类型，这些表类型必须属于同一个逻辑集群。
• 在逻辑集群模式下，通过CREATE TABLE ... LIKE方式创建外表时，源表和要创建的外表必须是在同一个逻辑集群中。
• 在逻辑集群模式下，不支持创建Schema同时创建表语句，即CREATE SCHEMA ... CREATE TABLE语句，用户需要首先创建Schema，再创建表到该Schema下。
• 逻辑集群不支持一主多备，逻辑集群只在主备从的部署形态下生效。
• 某个逻辑集群用户不能访问另一个逻辑集群用户创建的全局临时表。

权限说明

在逻辑集群模式下：

• 逻辑集群创建权限（CREATE ON NODE GROUP）允许授予任何用户/角色，创建权限后可在对应的逻辑集群上进行创建表等相关操作。
  • 如果创建的表指定的schema是某个用户私有schema（即该schema和用户同名且schema的owner是该用户），则新创建的表会将owner自动变更为该用户，不需要进行关联逻辑集群操作。
  • 和逻辑集群关联的用户在创建表时不一定指定to group，如果没有指定to group子句，用户创建的表在用户关联的逻辑集群上；支持变更用户关联的逻辑集群。
  • 如果用户没有关联逻辑集群，该用户创建表时会将表创建到default_storage_nodegroup指定的逻辑集群上；如果default_storage_nodegroup为installation，则将表创建到第一个逻辑集群中。在逻辑集群模式下，将oid最小的逻辑集群设置为第一个逻辑集群。通常用户没有显示设置default_storage_nodegroup的时候，默认值为installation。
  • 存算分离支持创建只读逻辑集群，如果用户关联到只读逻辑集群，只能在只读逻辑集群上创建会话级临时表（本地临时表和volatile临时表，不包括全局临时表）；该用户如果创建其他常规表和外表，要遵循没有关联逻辑集群的用户建表规则，即表会创建到default_storage_nodegroup指定的逻辑集群上，如果default_storage_nodegroup是installation，则将表创建到第一个逻辑集群中。
  • 系统管理员可以通过ALTER ROLE命令为每个用户设置默认的default_storage_nodegroup，具体语法参考ALTER ROLE。
• 建表规则
  • 用户表在没有指定to group时，如果设置了default_storage_nodegroup参数，则会将表创建到指定的逻辑集群中。
  • 如果default_storage_nodegroup参数设置为installation时，则会将表创建到第一个逻辑集群中（即所有逻辑集群中oid最小的一个）。
• 允许修改表的owner为任何用户，但对表进行操作时，需要检查对应的schema和nodegroup权限。
• 系统管理员可以关联到特定逻辑集群，并在多个逻辑集群中创建表。
  • 系统管理员如果关联了逻辑集群，那么创建表时如果未指定to group，那么会默认创建到关联的逻辑集群中；如果指定了to group，则可将表创建到指定的逻辑集群中。
  • 系统管理员如果没有关联逻辑集群，没有指定to group，则创建在由default_storage_nodegroup参数指定的逻辑集群中，详情参见建表规则。

• 允许将系统管理员权限授予关联了逻辑集群的用户，但同样遵循建表规则。
• 非表对象（schema/sequence/function/trigger等）的访问不再检查逻辑集群权限。
• 系统中的资源池必须关联到特定逻辑集群。
  • 在一个逻辑集群下可以创建多个资源池，同一个资源池不能属于多个逻辑集群。
  • 由于资源池定义了资源使用量，因此关联特定资源池的逻辑集群用户发起的作业将受到该资源池的资源约束。
  • 逻辑集群下不需要创建负载组来定义并发作业的数量。因此，逻辑集群模式不再支持负载组。
• 逻辑集群删除时只删除表、外表，资源池对象，其他对象不会删除。
  • 如果有对象依赖逻辑集群下的表（部分依赖表的sequence/function/triggers）同样也会删除。
  • 逻辑集群删除过程会取消用户关联关系，删除已有的父子租户关系，该集群用户将会绑定默认的installation nodegroup，关联全局默认资源池。
• 逻辑集群用户如果有创建数据库权限也可创建数据库。

复制表节点组

复制表节点组是逻辑集群模式下一种特殊的节点组，它可以包含一个或多个逻辑集群，但只能创建复制表。典型应用场景是用来创建公共维度表。如果多个逻辑集群都需要一些相同的公共维表，可以创建复制表节点组，并将这些公共维表创建在这个节点组中。复制表节点组包含的逻辑集群都可在本DN上直接访问这些维度表，而不需访问其他DN节点上的表。如果复制表节点组包含的逻辑集群中有任何一个发生了扩容或缩容操作，复制表节点组也会随之扩容或缩容。如果包含的逻辑集群被删除了，复制表节点组会随之缩容。但如果复制表节点组只包含一个逻辑集群，这种情况下如果逻辑集群被删除，则复制表节点组也会删除。通常情况下用户不应该创建这样的复制表节点组，而是应该将表创建到逻辑集群内。

复制表节点组通过SQL语句CREATE NODE GROUP创建，通过DROP NODE GROUP语句删除，删除前需要将该节点组上的表对象都删。

8.1.2及以上版本支持创建复制表节点组。

应用场景

场景一：将不同资源要求的数据隔离

图3 基于不同资源要求划分逻辑集群

如上图所示，不同资源要求的数据就分开存放到不同逻辑集群中，同时不同逻辑集群之间也支持互访，在保证资源隔离的基础上也可以保证功能不受影响。

• T1和T2表主要用于大批量数据计算，并生成报表数据（比如银行跑批）。这个过程由于需要大批量导入和大数据查询，所以对节点的内存和IO资源消耗比较高，且耗时比较长，但这类查询对实时性要求不高，因此可以将这些数据划分到一个独立的逻辑集群中。
• T3和T4表包含了一些计算数据和实时数据，主要用于业务点查和实时查询，这类查询要求实时性高，为避免其他高负载操作影响，可以将这些数据划分到独立的逻辑集群中。
• T5和T6表主要用于大并发OLTP类操作，数据更新非常频繁，对IO非常敏感，为了避免大数据查询对其影响，可以将这类表划分到独立的逻辑集群中。

场景二：不同业务要求的数据隔离，扩展数据集群多租户的能力

图4 逻辑集群多业务数据和多租户管理

大规模数据库集群往往同时包含很多业务的数据，不同业务有不同的数据表，为了对不同业务进行资源隔离，可以通过创建多租户来实现。将不同业务用户分配给不同租户，以便减少业务之间资源竞争。但随着业务规模不断扩大，集群系统中的业务数目越来越多，通过划分多租户来管理越来越难以控制资源竞争。由于每个表都会分布在数据库集群的所有DN节点上，因此每次数据表操作都可能会涉及所有DN节点，这会导致网络压力增大和系统资源消耗，单纯通过扩大集群规模也很难解决。所以可通过划分多个逻辑集群解决业务数量扩大问题，如上图所示。

通过划分独立的逻辑集群，将新增的业务分配到独立的逻辑集群上，这样新增业务对原有业务的影响会很小。而原有逻辑集群中的业务规模如果扩大，也可以通过对原有逻辑集群扩容来解决。

逻辑集群不适合将多个独立的数据库系统合并在一起管理，独立的数据库系统往往对独立运维要求很高，需要能够单独管理、监控、备份和升级，同时集群之间要求故障隔离，逻辑集群无法做到独立运维和完全的故障隔离。