云服务器内容精选
-
主节点与只读节点的通信 虽然主节点与只读节点共享底层存储数据，但是主节点和只读节点之间仍需要进行信息通信。 主节点发送到只读节点内容：redo的描述信息，比如redo日志的最新lsn和内部读取日志的接口信息。 只读节点发送到主节点内容： 只读节点当前的视图，视图中保存了当前的事务列表，主节点根据各个节点的视图信息，才能对undo日志进行purge清理。 只读节点的recycle_lsn，recycle_lsn表示只读节点读取数据页的最小lsn。对于只读节点来说，读取的数据页的lsn不会小于recycle lsn，主节点收集各个只读节点的recycle_lsn，来评估清理底层redo日志的位点。 各个只读节点的基本信息如节点ID, 最新消息更新时间戳等，用来主节点对只读节点的管理。 进行通信后，只读节点才能读取redo日志，进行数据可见性的更新。
-
只读延迟的计算 只读延迟是指在主节点更新数据后，在多少时间后能在只读节点得到这个最新数据。 只读节点读取redo日志进行缓存数据更新，对应的redo日志的lsn，称为visible lsn，表示只读节点能读取数据页的最大lsn。对于主节点来说，每更新或者插入一条数据产生的最新redo日志的lsn为flush_to_disk_lsn，表示主节点能访问的数据页的最大lsn。只读延迟其实就是只读节点visible lsn相比于主节点flush_to_disk_lsn的延迟，举个例子，比如t1时刻：主节点flush_to_disk_lsn=100， 只读节点visible lsn=80, 经过一段时间只读节点回放redo日志后，t2时刻：主节点 flush_to_disk_lsn=130，只读节点visible lsn=100。那么此时我们可以计算出只读延迟为：t2-t1，因为经过t2-t1的时间后只读节点才能读取主节点t1时刻的数据。
-
只读节点visible lsn的推进 根据延迟的计算方式，产生延迟的关键点在于只读节点visible lsn推进速度的快慢。 只读节点推进visible lsn的工作流程如下： 只读节点通过与主节点通信，获取最新redo的lsn和其描述信息。 从log store中读取redo日志到内存中。 redo 日志解析处理，失效内存中相关元数据信息、更新内存中的视图信息等。 推进visible lsn。 在大多数情况下，主节点和只读节点时延很小，但是在一些特殊场景下如主节点做大量DDL时候，可能会产生较大的只读延迟。
-
使用示例 表回收站功能提供以下命令用于操作回收站中暂存的表。 查看回收站中暂存的表 call dbms_recyclebin.show_tables(); 返回结果格式如下： +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ | SCHEMA | TABLE | ORIGIN_SCHEMA | ORIGIN_TABLE | RECYCLED_TIME | PURGE_TIME | +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ | __recyclebin__ | __innodb_test_db_t1_1069 | test_db | t1 | 2024-09-29 08:48:27 | 2024-10-02 08:48:27 | | __recyclebin__ | __innodb_test_db_t2_1070 | test_db | t2 | 2024-09-29 08:48:44 | 2024-10-02 08:48:44 | +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ 表3 字段说明 字段 说明 SCHEMA 回收站中表的当前库名。 TABLE 回收站中表的当前表名。 ORIGIN_SCHEMA 移入回收站前的原库名。 ORIGIN_TABLE 移入回收站前的原表名。 RECYCLED_TIME 表被移入回收站的时间。 PURGE_TIME 预计表被自动清理的时间。 恢复回收站中的表 手动创建与原表表结构相同的新表后，通过INSERT INTO ... SELECT ...语句将表中数据恢复到新表 示例： 查询回收站中原库名为db，原表名为t1的表： call dbms_recyclebin.show_tables(); 返回结果格式如下： +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ | SCHEMA | TABLE | ORIGIN_SCHEMA | ORIGIN_TABLE | RECYCLED_TIME | PURGE_TIME | +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ | __recyclebin__ | __innodb_test_db_t1_1069 | db | t1 | 2024-09-29 08:48:27 | 2024-10-02 08:48:27 | | __recyclebin__ | __innodb_test_db_t2_1070 | db | t2 | 2024-09-29 08:48:44 | 2024-10-02 08:48:44 | +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ 通过以上查询结果，确定需要恢复的表在回收站中的当前表名为__innodb_test_db_t1_1069，执行INSERT INTO ... SELECT ...命令，将回收站中表__innodb_test_db_t1_1069的数据恢复到新创建的表t1中： INSERT INTO `db`.`t1` SELECT * FROM `__recyclebin__`.`__innodb_test_db_t1_1069`; 通过INSERT INTO ... SELECT ...语句进行恢复不会移除回收站中暂存的数据，支持多次恢复，且生成的Binlog兼容性最佳。如实例存在基于Binlog的复制链路（如DRS 数据复制服务 、灾备实例），请避免使用call dbms_recyclebin.restore_table命令对回收站中的表进行恢复，建议使用INSERT INTO ... SELECT ...对数据进行恢复，降低由于目标端不支持表回收站功能、用户权限不足等原因导致复制中断的风险。 恢复回收站中的表到原库原表 call dbms_recyclebin.restore_table('TABLE_NAME'); 表4 参数说明 参数名称 说明 TABLE_NAME 回收站中表的当前表名。 示例： 将回收站中表__innodb_test_db_t1_1069恢复到原库test_db，并保留原表名t1。 call dbms_recyclebin.restore_table('__innodb_test_db_t1_1069'); 恢复回收站中的表到指定库的指定表 call dbms_recyclebin.restore_table('TABLE_NAME', 'DEST_DB', 'DEST_TABLE'); 表5 参数说明 参数名称 说明 TABLE_NAME 回收站中表的当前表名。 DEST_DB 指定表恢复到的数据库。 DEST_TABLE 指定表恢复后的表名。 示例： 将回收站中表__innodb_test_db_t1_1069恢复到指定库test_db2，并指定恢复后的表名为t3。 call dbms_recyclebin.restore_table('__innodb_test_db_t1_1069','test_db2','t3'); 执行恢复操作前请确保目标库存在，否则恢复命令将执行失败。 执行恢复操作前请确认目标库下不存在同名表，否则恢复将执行失败。 表回收站相关命令指定的引号内的库名、表名前后不允许有多余空格。 清理回收站中指定表 call dbms_recyclebin.purge_table('TABLE_NAME'); 表6 参数说明 参数名称 说明 TABLE_NAME 回收站中表的当前表名。 示例： 手动清理回收站中表__innodb_test_db_t1_1069 call dbms_recyclebin.purge_table('__innodb_test_db_t1_1069');
-
使用限制 当前版本支持分区级MDL锁功能，包括DROP PARTITION操作、RANGE和LIST分区方式的ADD PARTITION操作。 DROP PARTITION操作和ADD PARTITION操作仅支持inplace算法，不支持copy算法。 由于隔离级别可以设置为会话级别，如果transaction_isolation设置为REPEATABLE-READ或更高的隔离级别，在并发执行DDL过程中，可能会出现如下报错： ERROR HY000: Table definition has changed, please retry transaction。 这是正常现象，因为事务访问到了DDL创建的新分区。可以通过重新执行事务来解决这个问题。
-
语法 扩展column_definition定义，支持在CREATE TABLE/ALTER TABLE ADD/ALTER TABLE CHANGE/ALTER TABLE MODIFY场景定义列属性时使用压缩特性。 create_definition: { col_name column_definition | {INDEX | KEY} [index_name] [index_type] (key_part,...) [index_option] ... | {FULLTEXT | SPATIAL} [INDEX | KEY] [index_name] (key_part,...) [index_option] ... | [CONSTRAINT [symbol]] PRIMARY KEY [index_type] (key_part,...) [index_option] ... | [CONSTRAINT [symbol]] UNIQUE [INDEX | KEY] [index_name] [index_type] (key_part,...) [index_option] ... | [CONSTRAINT [symbol]] FOREIGN KEY [index_name] (col_name,...) reference_definition | check_constraint_definition } alter_option: { table_options | ADD [COLUMN] col_name column_definition [FIRST | AFTER col_name] | ADD [COLUMN] (col_name column_definition,...) | CHANGE [COLUMN] old_col_name new_col_name column_definition [FIRST | AFTER col_name] | MODIFY [COLUMN] col_name column_definition [FIRST | AFTER col_name] ... 其中column_definition为： column_definition: { data_type [NOT NULL | NULL] [DEFAULT {literal | (expr)} ] [VISIBLE | INVISIBLE] [AUTO_INCREMENT] [UNIQUE [KEY]] [[PRIMARY] KEY] [COMMENT 'string'] [COLLATE collation_name] [COLUMN_FORMAT {FIXED | DYNAMIC | DEFAULT}] [COLUMN_FORMAT {FIXED|DYNAMIC|DEFAULT}|COMPRESSED[={ZLIB|ZSTD}**]] [ENGINE_ATTRIBUTE [=] 'string'] [SECONDARY_ENGINE_ATTRIBUTE [=] 'string'] [STORAGE {DISK | MEMORY}] [reference_definition] [check_constraint_definition] | data_type [COLLATE collation_name] [GENERATED ALWAYS] AS (expr) [VIRTUAL | STORED] [NOT NULL | NULL] [VISIBLE | INVISIBLE] [UNIQUE [KEY]] [[PRIMARY] KEY] [COMMENT 'string'] [reference_definition] [check_constraint_definition] }
-
特性参数说明 表1 参数说明 参数名称 描述 取值范围 默认值 级别 是否动态生效 rds_column_compression 当参数取值为0时，表示字段压缩特性关闭，不再支持显式或者自动创建压缩列。 当参数取值为1时，表示仅支持显式创建压缩列。 当参数取值为2时，表示同时支持显式或自动创建压缩列。 [0,2] 0 GLOBAL 是 rds_default_column_compression_algorithm 设置字段压缩特性默认的压缩算法，适用于如下场景： 显式创建压缩字段而不指定具体的压缩算法。 自动压缩场景。 ZLIB或ZSTD ZLIB GLOBAL 是 rds_column_compression_threshold 设置字段压缩特性的阈值。 当列定义最大长度小于此阈值时，可以显式创建压缩列，但会收到提示信息，不能自动地创建压缩列。 当列定义最大长度大于等于此阈值时，支持显式或者自动创建压缩列。 [20-4294967295] 100 GLOBAL 是 rds_zlib_column_compression_level 控制字段压缩特性中zlib压缩算法的压缩级别。 当参数取值为0时代表不压缩。 取值为除0外范围内的其他参数值时，取值越小，压缩速度越快但压缩效果越差；取值越大，压缩速度越慢但压缩效果越好。 [0,9] 6 GLOBAL 是 rds_zstd_column_compression_level 控制字段压缩特性中zstd压缩算法的压缩级别。 取值越小，压缩速度越快但压缩效果越差；取值越大，压缩速度越慢但压缩效果越好。 [1,22] 3 GLOBAL 是
-
使用须知 TaurusDB实例内核版本大于等于2.0.54.240600可使用该功能。 不支持分区表、临时表、非InnoDB引擎表。 压缩字段上不能包含索引(主键、唯一索引、二级索引、外键、全文索引)。 仅支持的数据类型：BLOB（包含TINYBLOB、BLOB、MEDIUMBLOB、LONGBLOB），TEXT（包含TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT），VARCHAR，VARBINARY。 不支持在生成列上使用此特性。 不支持在分区表和带有压缩字段的表之间执行EXCHANGE PARTITION式语句。 不支持IMPORT TABLESPACE。 仅支持在CREATE TABLE/ALTER TABLE ADD/ALTER TABLE CHANGE/ALTER TABLE MODIFY场景使用此特性。 ALTER TABLE ADD COLUMN不支持INSTANT算法，ALTER TABLE {CHANGE|MODIFY} 语法涉及数据变化时不支持使用INSTANT算法。 自动压缩场景(rds_column_compression=2)，定义字段的最大长度需大于等于字段压缩阈值(rds_column_compression_threshold)时才可以被添加压缩属性；显式压缩场景(rds_column_compression=1)，若定义压缩字段的最大长度小于字段压缩阈值，字段仍可被添加压缩属性，同时收到warning信息。 若当前表中包含压缩字段，暂不支持NDP计算下推。 客户手动拉取BIN LOG 同步过程中ALTER语句会出现不兼容的问题，推荐客户侧使用HINT的方式来解决。 利用DRS迁移至无该特性的实例，压缩属性被消除。全量迁移任务可以进行，增量迁移时ALTER语句中存在压缩字段会导致迁移任务失败。 物理备份方面，利用备份去做数据恢复的版本也必须是带有字段压缩特性的。 升级至新版本之后，如果已经使用字段压缩功能，不支持回退至无该特性的版本。
-
资源计划指令(plan_directive)管理 资源计划指令描述了一个资源消费组具体的资源配置情况，一个资源计划指令唯一对应一个资源消费组；一个资源消费组可以关联多个资源计划指令，其中至多只允许启用一个资源计划指令，启用资源计划指令由上述启用资源计划实现。 创建资源计划指令 dbms_resource_manager.create_plan_directive ( plan CHAR(128), group_or_subplan CHAR(128), comment VARCHAR(2000), mgmt_p1 bigint(20), utilization_limit bigint(20)); plan：资源计划(plan)的名称。 group_or_subplan：资源消费组(consumer_group)的名称。 comment：资源计划指令的描述信息，可为''。 mgmt_p1：在CPU资源争抢的情况下，承诺分配给本资源消费组的CPU资源占所属租户总CPU资源的比例，取值范围[0, 100]，表示使用所属租户100%的CPU。同一租户且同一个资源计划(plan)所关联的所有资源计划指令(plan_directive)的mgmt_p1总和不超过100。当租户内的各个资源消费组发生CPU争抢，优先保证承诺分配各个资源消费组CPU资源，剩余的CPU资源由各个资源消费组争抢。承诺分配给资源消费组的CPU资源也遵循按需分配策略，不会预留，例如：承诺给当前资源消费组20%的CPU资源，但当前资源消费组业务量较少，只需要5%的CPU资源，则剩余的15%的CPU资源会按需分配给其他资源消费组。 utilization_limit：资源消费组可用的CPU资源的上限占所属租户总CPU资源的比例，取值范围为 [1, 100]。表示最大可使用租户全部CPU资源，如果取值为70则表示最大可使用租户70%的CPU资源。 同一资源消费组下的用户共享当前启用的资源计划指令配置的资源。例如：同一租户下的用户user1和user2都添加到资源消费组consumer_group1中，consumer_group1当前启用的资源计划指令的UTILIZATION_LIMIT为70，mgmt_p1为10，则user1和user2可使用的CPU资源总和最大为当前租户70%，CPU争抢时，保证user1和user2可获得的CPU资源总和为当前租户10%。 更新资源计划指令 dbms_resource_manager.update_plan_directive ( plan CHAR(128), group_or_subplan CHAR(128), new_comment VARCHAR(2000), new_mgmt_p1 bigint(20), new_utilization_limit bigint(20)); plan：资源计划(plan)的名称。 group_or_subplan：资源消费组(consumer_group)的名称。 comment：资源计划指令的描述信息，可为''。 mgmt_p1：在CPU资源争抢的情况下，承诺分配给本资源消费组的CPU资源占所属租户总CPU资源的比例，取值范围[0, 100]，表示使用所属租户100%的CPU。同一租户且同一个资源计划(plan)所关联的所有资源计划指令(plan_directive)的mgmt_p1总和不超过100。当租户内的各个资源消费组发生CPU争抢，优先保证承诺分配各个资源消费组CPU资源，剩余的CPU资源由各个资源消费组争抢。承诺分配给资源消费组的CPU资源也遵循按需分配策略，不会预留，例如：承诺给当前资源消费组20%的CPU资源，但当前资源消费组业务量较少，只需要5%的CPU资源，则剩余的15%的CPU资源会按需分配给其他资源消费组。 utilization_limit：资源消费组可用的CPU资源的上限占所属租户总CPU资源的比例，取值范围为 [1, 100]。表示最大可使用租户全部CPU资源，如果取值为70则表示最大可使用租户 70%的CPU资源。 同一资源消费组下的用户共享当前启用的资源计划指令配置的资源。例如：同一租户下的用户user1和user2都添加到资源消费组consumer_group1中，consumer_group1当前启用的资源计划指令的UTILIZATION_LIMIT为70，mgmt_p1为10，则user1和user2可使用的CPU资源总和最大为当前租户70%，CPU争抢时，保证user1和user2可获得的CPU资源总和为当前租户10%。 删除资源计划指令 dbms_resource_manager.delete_plan_directive ( plan CHAR(128), group_or_subplan VARCHAR(128)); plan：资源计划(plan)的名称。 group_or_subplan：资源消费组(consumer_group)的名称。 删除正在启用的plan_directive, 将导致对应用户的资源配置失效。 查看资源计划指令 DBA_RSRC_PLAN_DIRECTIVES记录资源计划指令的详细信息。如果在系统租户下查看，则可以查询到所有租户的资源计划指令，如果在普通租户下查看，只能看到当前租户下的资源计划指令。 SELECT * FROM information_schema.DBA_RSRC_PLAN_DIRECTIVES;
-
CPU使用率统计 用户级CPU使用率 新增information_schema.cpu_summary_by_user视图，用于显示各个资源消费组的CPU使用信息，在系统租户下会显示所有租户的所有资源消费组的CPU使用信息，在普通租户下，只会显示当前租户的所有资源消费组的CPU使用信息，具体使用如下： SELECT * FROM information_schema.cpu_summary_by_user; 查询结果中的列名说明： TENANT_NAME：用户所属的租户名称。 CONSUMER_GROUP：资源消费组名称。 CPU_USAGE：资源消费组的CPU使用率，为使用的CPU占所在实例总CPU的比例。例如4U的实例中, 资源消费组实际用了2U， 那么CPU_USAGE为50%。 CPU_USAGE_RELATIVE：资源消费组的CPU相对使用率，为使用的CPU占所在租户配置的MAX_CPU的比例。例如，当前租户的max_cpu为4U, 而资源消费组实际用了2U， 那么CPU_USAGE_RELATIVE为50%。 INCLUDED_USERS：属于此资源消费组中的用户名。 独占租户会创建一个默认的资源消费组default_group，租户下所有未绑定具体资源消费组的用户都会归属到default_group，default_group默认可使用租户的所有CPU资源，当租户内CPU争抢时，优先保证承诺分配给其他资源消费组的CPU资源，剩余的CPU资源分配给default_group。 租户级CPU使用率 新增information_schema.cpu_summary_by_tenant视图，用于显示各租户的CPU使用信息，在系统租户下会显示所有租户的CPU使用信息，在普通租户下，只会显示当前租户的CPU使用信息，具体使用如下： SELECT * FROM information_schema.cpu_summary_by_tenant; 查询结果中的列名说明： TENANT_NAME：租户名称。 TENANT_TYPE：租户类型，exclusive表示独占租户，shared表示共享租户。 CPU_USAGE：租户的CPU使用率，为使用的CPU占所在实例总CPU的比例。例如4U的实例中, 租户实际用了2U， 那么CPU_USAGE为50%。 CPU_USAGE_RELATIVE：租户CPU相对使用率，为租户实际使用的CPU占配置的MAX_CPU的占比。例如，当前租户的max_cpu为4U, 而租户实际用了2U， 那么CPU_USAGE为50%。 在满足所有独占租户MIN_CPU所配置的CPU资源后，所有的共享租户共享剩余的CPU资源，所以视图中所有的共享租户的CPU使用率一样，为所有共享租户的CPU使用率的总和。
-
资源计划（plan）管理 资源计划（plan）用于控制资源计划指令（plan_directive）的启用或禁用。一个资源计划关联一个或多个资源计划指令。启用或禁用资源计划可使对应的资源计划指令生效或失效，同一个租户内至多只能启用一个资源计划。 创建资源计划 dbms_resource_manager.create_plan ( plan_name VARCHAR(128), comment VARCHAR(2000)); plan_name：资源计划名称，仅支持包含大写字母、小写字母、数字或下划线。 comment：资源计划描述信息，可为''。 若删除当前启用的资源计划，则会将当前启用的资源计划设置为空，同时删除对应的资源计划指令（plan_directive）。 plan默认可配置的最大数量为128，由参数mt_resource_plan_num控制。 启用或禁用资源计划 dbms_resource_manager.set_resource_manager_plan( plan_name VARCHAR(128)); plan_name：资源计划名称。如果为空('')，则禁用资源计划。 删除资源计划 dbms_resource_manager.delete_plan ( plan_name VARCHAR(128)); plan_name：资源计划名称。 删除当前正在启用的资源计划，则会将当前启用的资源计划设置为空，同时删除所关联的资源计划指令（plan_directive）。 查看资源计划 视图DBA_RSRC_PLANS记录资源计划的详细信息。如果在系统租户下查看，则可以查询到所有租户的资源计划，如果在普通租户下查看，只能看到当前租户下的资源计划。 SELECT * FROM information_schema.DBA_RSRC_PLANS;
-
资源管理 资源配置（resource_config）和租户是一对多的关系，当某一租户绑定此资源配置时便可限制此租户下用户使用的CPU资源。 创建资源配置 CREATE resource_config config_name MAX_CPU [=] {max_cpu_value} [MIN_CPU [=] {min_cpu_value}]; 更新资源配置 ALTER resource_config config_name MAX_CPU [=] {max_cpu_value} [MIN_CPU [=] {min_cpu_value}]; 删除资源配置 DROP resource_config config_name; 查看资源配置 SELECT * FROM information_schema.DBA_RSRC_TENANT_RESOURCE_CONFIGS; 仅在高权限root用户下可使用。 参数说明： config_name： 资源配置名称。最大长度为64，仅支持包含大写字母、小写字母、数字或下划线。 MAX_CPU：绑定该资源配置的租户能够使用的最大CPU资源，单位为核数，最小值为0.1，最大值为实例规格中的CPU核数，可查看变量mt_flavor_cpu获取。粒度0.1。 MIN_CPU：在CPU资源争抢时，承诺分配给绑定该资源配置的租户的CPU资源，单位为核数，为可选项。默认等于MAX_CPU，最小值为0.1，最大值不超过MAX_CPU。粒度为0.1。(注意：shared_tenants_config为系统内置的资源配置，其MIN_CPU为0)。承诺分配给租户的CPU资源遵循按需分配策略，不会预留，例如：承诺给租户分配1U，但如果租户业务空闲，只会使用0.3U，则剩余的0.7U会按需分配给其他租户。 更新resource_config时，如果该resource_config已经绑定租户，且更新后MIN_CPU值大于原有的MIN_CPU值，则需要校验修改后的值是否满足资源约束，否则不做资源约束校验。 删除resource_config时，若租户正在使用该资源配置，则无法进行删除操作。 CPU争抢时，租户间资源分配会尽量按照租户的MIN_CPU分配资源，但存在一定的误差，误差通常在1U以内。 各租户下的实例的读写性能峰值并非和分配到的CPU资源呈线性关系。例如16U的实例分配给2个租户的MAX_CPU均为8U，那么两个租户同时满载跑业务的总共的TPS将达不到8U实例的2倍。即租户下的实例性能可能比同等规格的非多租实例的性能稍低。
-
用户级资源配置 租户下的用户默认共享当前租户的资源，若要进行用户级资源限制，请使用本节提供的用户级资源配置接口。 共享租户无法进行用户级资源配置。 资源消费组（consumer_group）管理 多个用户可以归属到同一个资源消费组(consumer_group)，这些用户共享资源消费组所关联的资源，通过租户下的用户连接数据库，进行资源消费组管理。 创建消费组 dbms_resource_manager.create_consumer_group ( consumer_group CHAR(128), comment CHAR(2000)); consumer_group：资源消费组名称，仅支持包含大写字母、小写字母、数字或下划线。 comment：资源消费组说明，可为''。 添加用户到资源消费组/从资源消费组中移除用户 dbms_resource_manager.set_consumer_group_mapping ( attribute CHAR(128), value varbinary(128), consumer_group CHAR(128)); attribute：要添加或修改的映射属性，当前版本仅支持USER。 value：要添加或修改的映射属性，当前版本仅支持用户名。 consumer_group：资源消费组名称，当参数不为空时将用户添加到资源消费组，当参数为空('')时，将用户从所在的资源消费组中移除。 删除消费组 dbms_resource_manager.delete_consumer_group ( consumer_group CHAR(128)); consumer_group：资源消费组名称。 删除consumer_group的时候会同步删除该资源消费组对应的plan_directive以及consumer_group_mapping。 如果特性开关打开，删除用户时，会自动将用户从已关联的资源消费组中移除。当特性关闭时，删除用户时不会自动从已关联的资源消费组中移除，但不会有任何影响，当后续重新打开特性时，如果发现关联到资源消费组的用户已经被删除，会自动将这些用户从已关联的资源消费组中移除。 如果特性开关打开，重命名用户时，不影响用户与资源消费组的关联关系。如果特性开关关闭后，删除用户，再创建同名用户，后续打开特性，该用户依然属于原有的资源消费组。 查看资源消费组 视图DBA_RSRC_CONSUMER_GROUPS记录了资源消费组信息。如果以系统租户下的用户身份下查看，则可以查询到所有租户的资源消费组信息，如果在普通租户下查看，只能看到当前租户下的资源消费组信息。 select * from information_schema.DBA_RSRC_CONSUMER_GROUPS; 查看资源消费组和用户的关联关系 视图DBA_RSRC_GROUP_MAPPINGS记录了用户和资源消费组的关联关系。如果以系统租户下的用户身份下查看，则可以查询到所有租户的用户和资源消费组的关联关系，如果在普通租户下查看，只能看到当前租户下的用户和资源消费组的关联关系。 select * from information_schema.DBA_RSRC_GROUP_MAPPINGS;
-
用户管理 开启多租模式后，用户分为系统租户下的用户和普通租户下的用户。存量的用户均属于系统租户，新创的用户根据接口语义属于系统租户或者普通租户。 在系统租户下管理用户 创建用户 创建系统租户下的用户： CREATE user [IF NOT EXISTS] user_name@host; 创建普通租户下的用户： CREATE user [IF NOT EXISTS] 'user_name@tenant_name'@host; 重命名用户 重命名系统租户下的用户： RENAME USER user_from@host1 TO user_to@host2; 重命名普通租户下的用户： RENAME USER 'user_from@tenant_name'@host1 TO 'user_to@tenant_name'@host2; 删除用户 删除系统租户下的用户： DROP USER [IF EXISTS] user_name@host; 删除普通租户下的用户： DROP USER [IF EXISTS] 'user_name@tenant_name'@host; 授权用户 为用户'user_1@tenant_1'@'%'授予租户tenant_1下的priv_type权限： GRANT priv_type ON *.* to 'user_1@tenant_1'@'%' with grant option; 查看权限： SHOW grants for 'user_1@tenant_1'@'%'; 在普通租户下管理用户 创建用户 创建当前租户下的用户： CREATE user [IF NOT EXISTS] user_name@host; 重命名用户 RENAME USER user_from@host1 TO user_to@host2; 删除用户 DROP USER [IF EXISTS] user_name@host; 授权用户 为用户user1授予当前租户下的priv_type权限： GRANT priv_type ON *.* to 'user_1'@'%' with grant option; 查看权限： SHOW grants for 'user_1'; 以系统租户身份创建或删除普通租户下的用户时，需要以user_name@tenant_name的方式对用户进行操作。 普通租户下的用户名称的长度被限制为不超过20个字符。 租户内不可以创建部分特殊用户：mysql.sys, mysql.session, mysql.infoschema以及参数rds_reserved_users中保留的用户。 在系统租户下，对普通租户下的用户重命名时，需要保证user_from和user_to中的tenant_name相同，如不相同，则接口返错。 多租户隔离特性关闭时，无法重命名普通租户下的用户。
-
数据库管理 数据库分为系统租户下的数据库和普通租户下的数据库。系统租户可以访问所有数据库，普通租户只能访问属于自己的数据库。 在系统租户下管理数据库 创建数据库 创建系统租户的数据库： CREATE DATABASE [IF NOT EXISTS] `db_name`; 创建普通租户的数据库： CREATE DATABASE [IF NOT EXISTS] `db_name@tanant_name`; 删除数据库 删除系统租户的数据库： DROP DATABASE [IF EXISTS] `db_name`; 删除普通租户的数据库： DROP DATABASE [IF EXISTS] `db_name@tanant_name`; 在普通租户下管理数据库 创建当前租户的数据库： CREATE DATABASE [IF NOT EXISTS] 'db_name'; 删除当前租户的数据库： DROP DATABASE [IF EXISTS] 'db_name'; 在系统租户下需要以db_name@tenant_name的方式对普通租户下的数据库进行操作。 系统库SYS、MYSQL暂不允许普通租户访问。 租户内不可以创建部分特殊DB：INFORMATION_SCHEMA, PERFORMANCE_SCHEMA, MYSQL, SYS, __recyclebin__。 存量数据库分配租户 为保证兼容性，升级或者迁移到多租实例后，存量的数据库默认属于系统租户，可以通过如下语法将存量的数据库分配给租户。此外，对于已经开启多租特性后，系统租户创建的且未分配给普通租户的数据库，也可通过如下语法分配数据库给对应租户。 数据库分配 将数据库分配给租户名为tenant_name的普通租户 ALTER DATABASE db_name TENANT = `tenant_name`; 将数据库回收到系统租户下 ALTER DATABASE db_name TENANT = ``; 查看映射关系 SELECT * FROM information_schema.DBA_RSRC_TENANT_DB; 仅在高权限root用户下可使用。 如果数据库是开启多租后创建的，以db_name@tenant_name格式命名的数据库不允许分配调用此接口，接口会返错。 如果tenant不存在，且不为空，接口返错。 通过租户下的用户连接数据库 在系统租户下，原有连接方式不变。 在普通租户下，指定用户时，需要以user_name@tenant_name的形式；指定数据库时，支持db_name和db_name@tenant_name两种形式。 mysql --host=**** -u user1@tenant_1 -D db1 -p pwssword; mysql --host=**** -u user1@tenant_1 -D db1@tenant_1 -p pwssword; 连接成功后，该用户将受到对应租户下的资源限制。
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
