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.

En esta página, se describe cómo habilitar, configurar y supervisar el reenvío transparente de consultas en tus instancias de AlloyDB para PostgreSQL. El reenvío transparente de consultas es una función inteligente de optimización de recursos que permite que el nodo principal intercepte las consultas de solo lectura y las reenvíe de forma selectiva a las instancias del grupo de lectura subutilizadas, al mismo tiempo que mantiene la coherencia de lectura después de escritura. Las consultas que se reenvían al grupo de lectura producen resultados coherentes con la ejecución del nodo principal.

Nota: Las consultas se reenvían a instancias del grupo de lectura en 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 informes o consultas analíticas, con coherencia de lectura después de escritura, en la misma base de datos que controla las transacciones, y deseas 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 separados, y, al mismo tiempo, necesitas una coherencia estricta de lectura después de escritura.
• Administración dinámica de la carga: Experimentas picos impredecibles en el tráfico de lectura y deseas que la base de datos transfiera automáticamente el trabajo en los nodos del grupo de lectura cuando el nodo principal esté bajo una carga pesada con coherencia de lectura y escritura.

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 Consulta 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 transparente de consultas no tendrá 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 transparente de consultas

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

Habilitar a nivel de la sesión

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

SET alloydb.enable_query_forwarding = TRUE;

Habilita la opción 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 instrucciones SELECT de solo lectura.
• La consulta no debe tomar ningún bloqueo a nivel de la fila, como los que se usan en SELECT ... FOR UPDATE.
• El reenvío transparente de consultas tiene compatibilidad limitada con las instrucciones SELECT dentro de las transacciones de varias instrucciones.
• 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 búsqueda solo es apta para el reenvío si su costo de sobrecarga es mínimo en comparación con el costo total de la búsqueda. Esto significa que, por lo general, se excluyen las consultas que usan análisis de índices, ya que su sobrecarga suele superar el costo de la consulta en sí.
• No se admite el reenvío a un nodo de espera activa de AlloyDB. Un nodo en espera activo 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 la consulta con EXPLAIN

En el siguiente ejemplo, large_table es una tabla en una base de datos con muchas filas. Para verificar si una búsqueda 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 la consulta después del plan de ejecución estándar de Postgres. Si falta esta instrucción, la consulta no es apta para el reenvío y se ejecuta de forma local en el servidor 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 estándar de SQL 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 transparente de consultas funcione en toda 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 las búsquedas que se controlan con el reenvío transparente de búsquedas.	Nombre visible: Recuento de búsquedas de TQF Tipo de métrica: CUMULATIVE Tipo de valor: INT64 Etiquetas: status: Control de búsquedas si el reenvío transparente de búsquedas está habilitado. Esta etiqueta registra uno de los siguientes valores: completed: Se ejecuta en una instancia de grupo de lectura. fallback: Se ejecuta en el servidor principal. disqualified: No se pudo reenviar.

¿Qué sigue?

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