PolarDB:Using Resource Management

Habilitar la función Resource Control

Crear un control de recursos

CREATE polar_resource_control <rc_name> max_cpu <max_cpu_value>;

Parámetros:

Una vez creado el control de recursos, ejecute la siguiente consulta SQL desde una cuenta con privilegios elevados para consultar todos los controles de recursos.

SELECT * FROM mysql.polar_resource_control;

Ejecute la siguiente consulta SQL desde una cuenta con privilegios elevados para obtener los Thread Groups asociados a un control de recursos.

SELECT id, resource_control_name FROM information_schema.thread_pool_status;

Actualizar un control de recursos

ALTER polar_resource_control <rc_name> max_cpu <max_cpu_value>;

Descripción:

Eliminar un control de recursos

DROP polar_resource_control <rc_name>;

Descripción:

Establecer un control de recursos para un usuario o una base de datos

Asociar

SET polar_resource_control <rc_name> FOR [database|USER] <db_name/user_name>;

La sentencia SQL es la siguiente:

Desasociar

RELEASE polar_resource_control <rc_name> FOR [database|USER] db_name/user_name>;

Después de ejecutar esta sentencia, la base de datos o el usuario especificado deja de estar restringido por los límites de recursos de CPU del control de recursos. Las sentencias que ya se están ejecutando siguen sujetas a dichos límites. Las sentencias que comiencen después de quitar el control de recursos no estarán sujetas a ellos.

Configurar un control de recursos para una consulta o conexión

Asociar

SET polar_resource_control <rc_name> FOR [query|connection] <connection_id>;

Parámetros:

Liberar

RELEASE polar_resource_control <rc_name> FOR [query|connection] <connection_id>;

Parámetros:

Prioridad de los controles de recursos

Los controles de recursos se aplican a una sentencia de consulta según el siguiente orden de prioridad. Se utiliza la primera coincidencia encontrada.

1. Un control asociado explícitamente a la consulta mediante su identificador de conexión. Tiene la prioridad más alta.

2. Se determina si la conexión actual tiene un control de recursos asociado y se aplican los límites de recursos correspondientes.

3. El sistema comprueba si el usuario conectado tiene un control de recursos asociado. De ser así, se aplican los límites de recursos.

4. Si la base de datos actualmente conectada tiene un control de recursos asociado, el sistema aplica los límites de recursos.

5. Si no se cumple ninguna de las condiciones anteriores, no aplican los límites de recursos.

Uso de un clúster multimaster

Un Multi-master Cluster funciona igual que un clúster de un solo master y la sintaxis es totalmente compatible. Cuando ejecuta una sentencia CREATE POLAR_RESOURCE_CONTROL, ALTER POLAR_RESOURCE_CONTROL o DROP POLAR_RESOURCE_CONTROL, esta se reenvía de forma aleatoria a un nodo de lectura y escritura del clúster. Luego, la sentencia se sincroniza en todos los nodos de lectura y escritura, lo cual puede generar cierta latencia. Para limitar los recursos de una consulta o conexión, utilice HINT syntax para especificar un nodo.

Escenarios

• Evitar que usuarios malintencionados consuman recursos excesivos del clúster.

• Gestionar consultas lentas inesperadas.

• Evitar que usuarios malintencionados activen el escalado automático en un clúster Serverless.

• Limitar el uso de CPU en entornos multiinquilino o cuando varios servicios comparten un clúster.

Ejemplos de uso

• Evitar que usuarios malintencionados consuman recursos excesivos del clúster

  Para gestionar usuarios malintencionados, establezca límites de recursos de CPU para ellos. Puede aplicar estos límites de forma preventiva o como respuesta a una actividad malintencionada.

  CREATE polar_resource_control rc_for_trouble_user max_cpu 10;
  SET polar_resource_control rc_for_trouble_user FOR USER trouble_user;

  Después de configurar un control de recursos para el usuario trouble_user, los hilos de este usuario podrán usar un máximo del 10 % de la CPU total del clúster. Esto evita de manera eficaz que el usuario malintencionado consuma recursos de CPU excesivos y afecte a otros servicios.

• Gestionar consultas lentas inesperadas

  A veces surgen consultas lentas imprevistas en un entorno de producción. Pueden deberse a un análisis sintáctico o una optimización incorrecta de SQL, lo que aumenta la carga de CPU. Esto provoca que la consulta se ejecute durante mucho tiempo y consuma recursos de CPU significativos. Aunque puede finalizar la consulta con el comando kill, debe esperar a que alcance un punto específico de su ejecución, lo cual consume tiempo. Además, revertir la transacción durante el proceso de kill también consume recursos de CPU y toma tiempo. Para reducir rápidamente la carga de CPU de una consulta lenta o evitar que la CPU se sature, aplique un límite de uso de CPU a dicha consulta.

  CREATE polar_resource_control rc_for_slow_query max_cpu 10;
  SET polar_resource_control rc_for_slow_query FOR query query_id;

  Nota

  Cuando configura un control de recursos para una consulta lenta, obtenga su query_id mediante la ejecución de SHOW PROCESSLIST.

  Después de configurar un control de recursos para la consulta lenta con el identificador query_id, el uso máximo de CPU de esa consulta se limita al 10 % de la CPU total del clúster. Esto reduce rápidamente la carga de CPU del clúster y evita que la consulta afecte a otros servicios de producción.

  Un clúster de PolarDB puede tener varios nodos de cómputo, y distintos nodos podrían tener consultas con el mismo identificador de conexión. Por lo tanto, cuando configure un control de recursos para una consulta, utilice HINT syntax para aplicar la configuración a un nodo específico.

  /*force_node='pi-bpxxxxxxxx'*/ SET polar_resource_control rc_for_slow_query FOR query query_id;

• Evitar que usuarios malintencionados activen el escalado del clúster en un clúster serverless

  Cuando un clúster está en modo Serverless, escala automáticamente según la carga de trabajo para manejar picos repentinos de alta carga. Sin embargo, es posible que desee evitar que el clúster escale como respuesta a solicitudes de usuarios malintencionados. En este caso, aplique límites de recursos a esos usuarios en el clúster serverless.

  CREATE polar_resource_control rc_for_trouble_user max_cpu 10;
  SET polar_resource_control rc_for_trouble_user FOR USER trouble_user;

• Limitar el uso de CPU en clústeres multiinquilino o multiservicio

  En escenarios de Software como Servicio (SaaS), varios inquilinos suelen ejecutarse en el mismo clúster. También es común que distintos servicios de negocio compartan un clúster. En estas situaciones, es importante limitar los recursos que puede usar un solo inquilino o servicio. Así se evita que un usuario o servicio consuma demasiada CPU y afecte el rendimiento general del clúster. Para lograrlo, establezca límites de recursos de CPU independientes para cada servicio. Por ejemplo, puede aplicar límites por usuario o por base de datos.

  CREATE polar_resource_control rc_for_business_1 max_cpu 20;
  CREATE polar_resource_control rc_for_business_2 max_cpu 20;
  
  SET polar_resource_control rc_for_business_1 FOR USER user_1;
  SET polar_resource_control rc_for_business_2 FOR USER user_2;

  Con esta configuración, los servicios que usan user_1 y user_2 quedan limitados, cada uno, a un máximo del 20 % de la CPU total del clúster. Por lo tanto, ambos usuarios pueden usar en conjunto un máximo del 40 % de los recursos de CPU. Si la carga de trabajo de user_1 aumenta de repente, su uso de CPU se mantiene limitado al 20 %, lo que garantiza que los demás servicios del clúster no se vean afectados.

  Si un solo servicio usa varios usuarios, asigne el mismo control de recursos a todos ellos.

  CREATE polar_resource_control rc_for_business_1 max_cpu 20;
  
  SET polar_resource_control rc_for_business_1 FOR USER user_1;
  SET polar_resource_control rc_for_business_1 FOR USER user_2;

  Con esta configuración, el servicio que usan user_1 y user_2 queda limitado a un máximo del 20 % de la CPU total del clúster. Por lo tanto, ambos usuarios pueden usar en conjunto un máximo del 20 % de los recursos de CPU. Esto evita que el servicio supere su límite de CPU cuando aumenta la carga de trabajo de uno de los usuarios y garantiza una asignación equitativa de recursos.