多租户管理简介
功能简介
TaurusDB提供的多租户管理功能，让数据库能够为其多个租户服务，提高数据库资源利用率。租户间实现数据隔离，不同租户能访问自己的数据。支持租户级资源隔离和用户级资源隔离，资源隔离能够避免浪费和性能扰邻。支持资源动态调整，能够及时应对不同租户或用户的业务高峰和波谷。
多租户管理功能的原理图如下：
上图显示了多租户管理特性的整体流程，租户分为系统租户和普通租户。
上图中有属于系统租户的库DB_1和用户user_1，也有普通租户Tenant_1的库DB_1、DB_2和用户user_1、user_2，以及普通租户Tenant_2的库DB_1、DB_2和用户user_1、user_2。
系统租户有整个数据库实例的访问权限，即系统租户可访问和管理自己所拥有的DB_1、user_1，也可以访问和管理Tenant_1或者Tenant_2下的DB_1、DB_2、user_1、user_2。普通租户有数据隔离，即Tenant_1只能访问和管理自己所拥有的库DB_1、DB_2和用户user_1、user_2，无法访问Tenant_2下的库和用户，也无法访问系统租户下的库和用户。
除了数据隔离，多租还实现了CPU资源隔离。如上图显示了当前实例总的CPU资源，使用者可自定义系统租户和普通租户的资源配置，同时也可以在租户级资源配置的基础上，为租户内的每个用户划分各自所占的资源。
基本概念
租户级
- 租户（Tenant）：租户的层级结构在数据库实例之下，在数据库与用户之上。租户是为了数据隔离、资源隔离提出的概念，实际访问数据库还是需要以用户的身份去访问。
- 按照数据隔离的维度：分为系统租户和普通租户。
- 按照资源隔离的维度：租户可使用的资源由租户级资源配置（当前仅支持CPU资源）确定，分为独占型租户和共享型租户。
- 独占型租户：租户关联的资源配置中的min_cpu>0，需要保证在任何时刻该租户的CPU核数不小于min_cpu。
- 共享型租户：关联到特定的资源配置shared_tenants_config的租户，此资源配置的min_cpu=0。系统优先保证独占租户的资源请求，然后将剩余资源配给共享租户。同时，系统保留一部分CPU资源（由参数mt_shared_cpu_reserved进行配置）给共享租户，保证共享租户在CPU争抢时不会出现无法获取到资源的情况。独占型租户和共享型租户可以通过修改关联的资源配置进行相互转换。
- 租户级资源配置（resource_config）：为实现租户级资源隔离所提出的概念，一个resource_config描述了对应租户下能够使用的资源。当前仅支持通过设置min_cpu和max_cpu实现对CPU资源上下限进行配置，内置以下资源配置：
- RDS_SYS_CONFIG：系统租户对应的资源配置，min_cpu默认为0.1(单位:CPU核数)，max_cpu默认为实例规格的CPU核数。
- shared_tenants_config：共享租户对应的资源配置，min_cpu固定为0，max_cpu默认为实例规格的CPU核数。
如上图所示，当使用者以系统租户的身份登录实例，并创建数据库DB1、DB3和USER1时，库名和用户名将保持不变。系统租户也能查看普通租户下的库和用户，查看属于tenant1的库DB1、USER1、USER2时，将显示为DB1@tenant1、USER1@tenant1、USER2@tenant1，查看属于tenant2的库DB1、DB2与USER1时，将显示为DB1@tenant2、DB2@tenant2、USER1@tenant2。
TaurusDB以不同的租户名后缀区分不同租户下库和用户，当使用者以普通租户tenant1的身份登录实例，看到的库和用户又将显示为DB1、DB2、USER1、USER2，对于租户tenant2来说同理。若未开启多租时就存在库DB2，那么在开启多租后将默认属于系统租户。使用者也可以根据TaurusDB提供的语法将DB2分配给其他租户，详情见后文。
对于资源隔离来说，系统租户有默认的资源配置，也支持自定义修改。如上图，系统租户可使用的CPU下限为1U，上限为2U。租户tenant1的CPU下限为0，说明是共享租户，CPU使用上限为4U。租户tenant2的CPU下限为3U，说明是独占租户，CPU上限为4U。
用户级
用户的层级结构在数据库实例和租户之下，同一个租户可以拥有多个用户。多租户功能没有修改用户间的数据隔离，只增加了用户级的资源管理机制。
- 资源消费组（consumer_group）
多个用户可以归属到同一个资源消费组，这些用户共享资源消费组所关联的资源。
- 资源计划指令（plan_directive）
资源计划指令描述了一个资源消费组具体的资源配置情况，一个资源计划指令唯一对应一个资源消费组；一个资源消费组可以关联多个资源计划指令，其中至多只允许启用一个资源计划指令，为实现此功能，引入下述的资源计划的概念。
- 资源计划（plan）
用于控制资源计划指令的启用或禁用。一个资源计划关联一个或多个资源计划指令。启用或禁用资源计划可使对应的资源计划指令生效或失效，同一个租户内至多只能启用一个资源计划。
图3 用户级资源配置关系图
如上图，当前实例规格为4U，有独占租户Tenant_1，所占资源中CPU使用下限为1U，使用上限为4U。同一租户下各用户共享租户资源，当前租户下有2个资源计划plan1、plan2。plan1下有1个计划指令plan_directive1，plan2下有2个计划指令plan_directive2，plan_directive3。
- plan_directive2：限制了所属用户组consumer_group1的CPU资源使用下限为Tenant_1的60%，使用上限为Tenant_1的100%。
- plan_directive3：限制了所属用户组consumer_group2的CPU资源使用下限为Tenant_1的40%，使用上限为Tenant_1的100%。
当开启plan2时，plan_directive2，plan_directive3对用户级CPU的限制将开始生效。user_1由于属于consumer_group1，所以CPU的使用限制将由plan_directive2决定，user_2和user_3同理。
使用须知
- 若TaurusDB实例内核版本为2.0.60.241200及其以上，新增的多租视图（包括MT_RESOURCE_CONFIG、MT_TENANT、MT_TENANT_DB、MT_RESOURCE_PLAN、MT_CONSUMER_GROUP、MT_GROUP_MAPPING_RULE、MT_PLAN_DIRECTIVE）将代替旧版本的多租视图DBA_RSRC_*提供服务
- Binlog：目前Binlog没有实现租户隔离，如果允许普通租户拉取Binlog会破坏租户间数据隔离，因此当前禁止普通租户下的用户拉取Binlog。
- 数据库代理：因HTAP标准版不支持带@字符的数据库，普通租户下的数据库迁移到该类HTAP引擎时会更改目标端库名，但数据库代理的自动行存/列存引流功能要求源端和目标端的库名一致，因此普通租户创建的数据库将无法使用数据库代理的自动行存/列存引流功能。
- 备份恢复：
如果原实例的内核版本小于2.0.60.241200且已开启多租功能，目标实例的内核版本是2.0.60.241200及以上，则无法通过备份将原实例恢复至目标实例，此场景__taurus_sys__库可能会被清理，多租功能将无法正常提供服务。
未开启多租开关的目标实例不支持创建带@的用户、数据库和表空间。
- 升降级：
- 如果实例中的多租开关打开，且TaurusDB实例内核版本为2.0.60.241200及其以上，存在需要降级到2.0.60.241200之前的版本的场景。降级成功后，需要再次重启实例，多租功能才能恢复可用，否则降级后的多租开关将变更为关闭。
- 如果TaurusDB实例内核版本为2.0.60.241200及其以上，存在需要降级到2.0.60.241200之前的版本的场景。降级成功后，在information_schema下执行show tables等可能依然会显示新增的多租视图（包括MT_RESOURCE_CONFIG、MT_TENANT、MT_TENANT_DB、MT_RESOURCE_PLAN、MT_CONSUMER_GROUP、MT_GROUP_MAPPING_RULE、MT_PLAN_DIRECTIVE），但无法访问。如需清除残留的多租视图元数据，需要手动重启实例。
- 如果TaurusDB实例内核升级到2.0.60.241200版本及以后，在information_schema下执行show tables命令，可能无法正常显示新增的多租视图。但不影响多租视图的访问，如需显示，需要手动重启实例。
- 兼容性：
- 先开启后关闭多租开关，创建数据库、用户和表空间时，名称中不能包含@字符。
- 普通租户下，数据库名称最大长度由64降低为50，用户名称最大长度由32降低为20。
- 系统库mysql、sys暂不开放给普通租户。
- 普通租户下，系统库performance_schema里的表使用用户名或库名做条件查询时，需要使用模糊搜索。
- 系统租户的root用户可以kill其他用户的session；普通租户的用户，只能kill当前用户的session。
- 多租实例不支持全文索引。
