Optimiza los recursos y aísla las consultas de lectura con el reenvío transparente de consultas

Versión preliminar — Reenvío transparente de consultas

Esta función está sujeta a las "Condiciones de la oferta previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles “sin modificaciones” y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Para descargar el tráfico de lectura de tu instancia principal sin sacrificar la coherencia de lectura de tus escrituras ni modificar los extremos de conexión de la aplicación, puedes habilitar, configurar y supervisar el reenvío transparente de consultas en tus instancias de AlloyDB para PostgreSQL. El reenvío de consultas transparente intercepta las consultas de solo lectura en el nodo principal y las enruta de forma selectiva a las instancias de grupos de lectura infrautilizadas, lo que devuelve resultados coherentes con la ejecución del nodo principal.

Nota: Las consultas se reenvían a las instancias del grupo de lectura de la región. Las consultas no se reenvían a los clústeres secundarios.

El reenvío transparente de consultas es más adecuado para las siguientes situaciones:

• Cargas de trabajo híbridas (HTAP): Ejecutas consultas analíticas o de informes, con coherencia de lectura de tus escrituras, en la misma base de datos que controla las transacciones y quieres evitar que las lecturas costosas afecten la latencia de escritura.
• Aplicaciones monolíticas: Quieres usar la capacidad del grupo de lectura sin refactorizar tu aplicación para usar extremos de lectura y escritura independientes, pero aún necesitas una coherencia estricta de lectura de tus escrituras.
• Administración dinámica de la carga: Experimentas aumentos repentinos impredecibles en el tráfico de lectura y quieres que la base de datos descargue automáticamente el trabajo en los nodos del grupo de lectura cuando el nodo principal tenga una carga pesada con coherencia de lectura de tus escrituras.

Antes de comenzar

• Asegúrate de que tu clúster de AlloyDB sea compatible con PostgreSQL 17 o 18.

• Debes tener al menos una instancia de grupo de lectura activa configurada en tu clúster de AlloyDB. Para obtener información sobre cómo crear o verificar instancias de grupos de lectura, consulta Crea una instancia de grupo de lectura en un clúster y Visualiza los detalles de la instancia.

  Nota: Si tu clúster solo tiene una configuración principal o de alta disponibilidad (HA) sin grupos de lectura, el reenvío de consultas transparente no tiene nodos de destino disponibles para recibir las consultas reenviadas.

Roles obligatorios

• Asegúrate de conectarte con un usuario de base de datos integrado, como postgres. No se admite la autenticación basada en IAM.

Habilita el reenvío de consultas transparente

El reenvío transparente de consultas está inhabilitado de forma predeterminada. Puedes habilitarla de forma dinámica a nivel de la sesión o de la base de datos sin reiniciar la base de datos.

Habilita la función a nivel de la sesión

Para habilitar el reenvío de consultas transparente en tu sesión actual, ejecuta el siguiente comando de SQL:

SET alloydb.enable_query_forwarding = TRUE;

Habilita la auditoría a nivel de la base de datos

Para habilitar el reenvío transparente de consultas para una base de datos específica, ejecuta el siguiente comando de SQL:

ALTER DATABASE DATABASE_NAME SET alloydb.enable_query_forwarding = ON;

Reemplaza DATABASE_NAME por el nombre de tu base de datos.

Nota: Después de ejecutar el comando ALTER DATABASE, se habilita el reenvío transparente de consultas para las conexiones nuevas a la base de datos.

Condiciones de elegibilidad de la consulta

• El reenvío transparente de consultas solo se aplica a las declaraciones SELECT de solo lectura.
• La consulta no debe aplicar bloqueos a nivel de fila, como los que se usan en SELECT ... FOR UPDATE.
• El reenvío de consultas transparente tiene compatibilidad limitada con las declaraciones SELECT dentro de las transacciones de varias declaraciones.
• Las consultas no pueden hacer referencia a tablas temporales, no registradas o de catálogo.
• La consulta debe cumplir con las siguientes restricciones de funciones:
  • La consulta no debe contener funciones volátiles ni funciones definidas por el usuario (UDF).
  • La consulta no debe contener funciones de valor de SQL, como CURRENT_DATE, LOCALTIME, USER o CURRENT_SCHEMA.
  • La consulta no debe contener expresiones NEXTVAL().
  • La consulta no puede contener ningún procedimiento ni función de SQL.
• Todas las columnas de resultados deben usar tipos de datos que implementen funciones de envío y recepción binarias.
• Una consulta solo es apta para el reenvío si su costo de sobrecarga es mínimo en comparación con el costo total de la consulta. Esto significa que las consultas que usan análisis de índices suelen excluirse, ya que su sobrecarga suele superar el costo de la consulta en sí.
• No se admite el reenvío a un nodo en espera activa de AlloyDB. Un nodo en espera activa de AlloyDB es un nodo secundario dedicado para instancias principales con alta disponibilidad (HA).
• La consulta debe usar el protocolo de consulta simple. No se admite el protocolo de consulta extendido.

Verifica la elegibilidad de las consultas con EXPLAIN

En el siguiente ejemplo, large_table es una tabla en una base de datos con muchas filas. Para verificar si una consulta específica es apta para el reenvío según tu configuración actual, ejecuta el comando EXPLAIN:

EXPLAIN SELECT count(*) FROM large_table t1, large_table t2;

Si la consulta es apta, el resultado incluye una declaración de estado de reenvío de consultas después del plan de ejecución estándar de Postgres. Si falta esta sentencia, la consulta no es apta para el reenvío de consultas y se ejecuta de forma local en la instancia principal.

Aggregate  (cost=25000.00..25000.01 rows=1 width=8)
  ->  Nested Loop  (cost=0.00..20000.00 rows=1000000 width=0)
        ... [Standard Postgres Plan Steps] ...
Query Forwarding: Eligible. (overhead=1250.02)

En la respuesta de salida, Eligible indica que la consulta cumple con los criterios de SQL estándar de solo lectura y que el análisis de costo-beneficio favorece su enrutamiento a una instancia de grupo de lectura. El parámetro overhead indica el costo calculado del planificador para reenviar la consulta a una instancia de grupo de lectura, incluida la sobrecarga de establecer la conexión y restablecer las instantáneas en la réplica.

Supervisa las métricas de reenvío de consultas

Para verificar que el reenvío de consultas transparente funcione en tu carga de trabajo, puedes hacer un seguimiento de la siguiente métrica en Cloud Monitoring:

Métrica	Descripción	Detalles
alloydb.googleapis.com/internal/database/postgresql/workload/distributed/tqf_query_count	Es el recuento acumulativo de consultas que se controlan con el reenvío transparente de consultas.	Nombre visible: Recuento de consultas de TQF Tipo de métrica: CUMULATIVE Tipo de valor: INT64 Etiquetas: status: Control de consultas si el reenvío de consultas transparente está habilitado. Esta etiqueta registra uno de los siguientes valores: completed: Se ejecuta en una instancia de grupo de lectura. fallback: se ejecuta en la instancia principal. disqualified: No se pudo reenviar.

¿Qué sigue?

• Crea una instancia de grupo de lectura en un clúster
• Supervisa instancias