Utilizar agrupación de conexiones

Importante

El escalado automático de Lakebase es la versión más reciente de Lakebase, con proceso de escalado automático, escalado a cero, bifurcación y restauración instantánea. Para ver las regiones admitidas, consulte Disponibilidad de regiones. Si es un usuario aprovisionado de Lakebase, consulte Aprovisionamiento de Lakebase.

Lakebase incluye un agrupador de conexiones PgBouncer integrado que mantiene un grupo de conexiones de servidor y los comparte entre muchas conexiones de cliente. El agrupador admite hasta 10 000 conexiones simultáneas, lo que lo convierte en una buena opción para funciones sin servidor, API web y otras aplicaciones que abren muchas conexiones de corta duración.

La agrupación de conexiones requiere la autenticación nativa de contraseña de Postgres. No está disponible para roles de identidad de OAuth ni de Azure Databricks.

Funcionamiento de la agrupación de conexiones

Cada conexión de Postgres consume recursos de servidor porque Postgres crea un proceso independiente para cada cliente. Las aplicaciones que abren muchas conexiones de corta duración, como las API web y las funciones sin servidor, pueden agotar rápidamente el límite de conexión del servidor.

El agrupador de conexiones se encuentra entre la aplicación y Postgres. Los clientes se conectan al agrupador y el agrupador reenvía las consultas a un grupo más pequeño de conexiones de servidor reales. Cuando se completa una transacción, el agrupador devuelve la conexión de servidor al grupo, lo que hace que esté disponible para el siguiente cliente.

Lakebase ejecuta PgBouncer en modo de transacción. En el modo de transacción, se mantiene una conexión de servidor mientras dure una única transacción y, a continuación, se devuelve al grupo. Esto permite a muchos clientes compartir un pequeño grupo de conexiones de servidor.

El modo de transacción mejora la eficacia de la conexión, pero restringe determinadas características de Postgres que requieren una conexión de servidor persistente. Consulte Limitaciones del modo de transacción.

Grupos de conexiones

PgBouncer crea un grupo independiente para cada base de datos y combinación de usuario. Dos usuarios que se conectan a la misma base de datos obtienen grupos independientes. El tamaño de cada grupo es de aproximadamente el 90% del límite de conexión directa del recurso de cómputo.

Cuando todas las conexiones de un pool están en uso, las nuevas solicitudes de cliente esperan en una cola. Si una conexión de servidor no está disponible en un plazo de 2 minutos, el cliente recibe un error de tiempo de espera.

Límites de conexión

Tres límites rigen la agrupación de conexiones:

Límite Value Qué controla
Conexiones de cliente (max_client_conn) 10 000 Número máximo de conexiones de la aplicación a PgBouncer
Tamaño del reservorio (default_pool_size) ~90% de max_connections Conexiones de servidor activas por par (usuario, base de datos)
Conexiones directas (max_connections) Varía según el tamaño de computación. Número máximo de conexiones de Postgres directas

El límite de conexión directa depende del tamaño de proceso. Por ejemplo, un proceso de 8 CU admite 1678 conexiones directas y un proceso de 16 CU admite 3357. Para obtener la lista completa, consulte Especificaciones de proceso.

La agrupación de conexiones permite que la aplicación admita mucho más usuarios simultáneos que el límite de conexión directa solo permitiría.

Prerrequisitos

  • El proyecto de escalado automático de Lakebase debe estar activo.
  • Debe tener un rol de contraseña nativa de Postgres en el proyecto. Para obtener instrucciones, consulte Creación de un rol nativo de contraseña de Postgres.
  • Para usar el agrupador de solo lectura, debe tener un punto de conexión de alta disponibilidad con Permitir el acceso a instancias de cálculo de solo lectura habilitadas. Consulte Alta disponibilidad.

Habilitación de la agrupación de conexiones

  1. En la aplicación Lakebase, vaya al proyecto y haga clic en Conectar.
  2. Seleccione la rama y la instancia de computación a la que desea conectarse.
  3. En la lista desplegable Rol , seleccione un rol nativo de contraseña de Postgres. El conmutador de agrupación de conexiones solo está visible cuando se selecciona un rol que requiere contraseña. Está oculto para los roles de identidad de OAuth y Azure Databricks.
  4. Activa la agrupación de conexiones.
  5. Copie el cadena de conexión y úselo en la aplicación.

Cuadro de diálogo de conexión que muestra la alternancia de conexiones agrupadas habilitada para una función de contraseña nativa de Postgres.

Formatos de cadena de conexión

Las cadenas de conexión del agrupador usan un nombre de host diferente al de las conexiones directas de base de datos:

Tipo Formato de nombre de host Cuándo se deben usar
Pooler de lectura-escritura <endpoint-id>-pooler.<region>.<cloud>.databricks.com Todo el tráfico de escritura y lectura enrutado a través del agrupador
Pooler de solo lectura <endpoint-id>-ro-pooler.<region>.<cloud>.databricks.com Solo lectura del tráfico. Requiere un punto de conexión de alta disponibilidad con acceso de lectura habilitado.

Ambos tipos de agrupador usan el puerto 5432.

Note

Copie la cadena de conexión del agrupador directamente desde el cuadro de diálogo Connect de la aplicación Lakebase para obtener el nombre de host correcto para el punto de conexión, la región y la nube.

Limitaciones del modo de transacción

Las siguientes características de Postgres no están disponibles al usar el agrupador de conexiones:

  • Instrucciones preparadas de nivel SQL: las PREPARE y DEALLOCATE no se admiten en el modo de transacción. Las instrucciones preparadas a nivel de controlador (usadas internamente por psycopg2, node-postgres, JDBC y bibliotecas similares) funcionan correctamente mediante el soporte a nivel de protocolo de PgBouncer. Para JDBC, si ve errores relacionados con instrucciones preparadas, establezca prepareThreshold=0 para deshabilitar el almacenamiento en caché de instrucciones preparadas del lado servidor con nombre.

  • Configuración de nivel de sesión: SET los comandos no se conservan en las transacciones porque cada transacción puede usar una conexión de servidor diferente. Por ejemplo:

    BEGIN;
SET search_path TO myschema;
SELECT * FROM mytable; -- works in this transaction
COMMIT;
-- connection returns to pool after COMMIT
SELECT * FROM mytable; -- ERROR: relation "mytable" does not exist

    Para aplicar una configuración de forma permanente, use ALTER ROLE en su lugar:

    ALTER ROLE myrole SET search_path TO myschema, public;

  • Tablas temporales mantenidas por sesión: las tablas temporales que se conservan entre transacciones no están disponibles. Una conexión devuelta al grupo se puede asignar a un cliente diferente en la siguiente transacción.

  • WITH HOLD cursores: los cursores declarados con WITH HOLD requieren una conexión persistente y no se admiten.

  • Bloqueos de asesoramiento: PgBouncer no admite bloqueos de asesoramiento. Los bloqueos de aviso requieren una conexión de servidor persistente, que no está disponible en modo de transacción.

  • LISTEN/NOTIFY: no se admite. Use una conexión directa (no agrupada) para las aplicaciones que requieren mensajería pub/sub.

  • pg_dump y migraciones de esquema: Use una conexión directa para pg_dump, migraciones de esquema y otras herramientas que dependen del estado de nivel de sesión.

Note

Para las aplicaciones que requieren funciones de Postgres a nivel de sesión, use una cadena de conexión directa desde el cuadro de diálogo Connect sin habilitar la alternancia de agrupación de conexiones .

Pasos siguientes

  • Cadenas de conexión: referencia de formato de cadena de conexión para conexiones directas. Consulte Cadenas de conexión.
  • Creación de roles de Postgres: creación de roles nativos de contraseña de Postgres necesarios para la agrupación de conexiones. Consulte Creación de roles de Postgres.
  • Acerca de la autenticación: comparación de métodos de autenticación de OAuth y contraseña. Consulte Acerca de la autenticación.
  • Last updated on