Límites en Azure Database for PostgreSQL con servidor flexible

Artículo
04/27/2024

SE APLICA A: Azure Database for PostgreSQL: servidor flexible

En las secciones siguientes, se describen los límites funcionales y de capacidad del servidor flexible de Azure Database for PostgreSQL. Si desea obtener información sobre los niveles de recursos (proceso, memoria o almacenamiento), consulte el artículo proceso y almacenamiento.

Número máximo de conexiones

En la siguiente tabla se muestra el predeterminado número máximo de conexiones para cada plan de tarifa y configuración de núcleo virtual. El servidor flexible de Azure Database for PostgreSQL reserva 15 conexiones para la replicación física y la supervisión de la instancia de servidor flexible de Azure Database for PostgreSQL. Por lo tanto, el valor de las conexiones de usuario máximas enumeradas en la tabla se reduce en 15 de las conexiones máximas totales.

Nombre de producto	Núcleos virtuales	Tamaño de memoria	Número máximo de conexiones	Número máximo de conexiones de usuario
Flexible
B1ms	1	2 GiB	50	35
B2s	2	4 GiB	429	414
B2ms	2	8 GiB	859	844
B4ms	4	16 GiB	1,718	1,703
B8ms	8	32 GiB	3437	3,422
B12ms	12	48 GiB	5000	4,985
B16ms	16	64 GiB	5000	4,985
B20ms	20	80 GiB	5000	4,985
Uso general
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5	2	8 GiB	859	844
D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5	4	16 GiB	1,718	1,703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5	8	32 GiB	3437	3,422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5	16	64 GiB	5000	4,985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5	32	128 GB	5000	4,985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5	48	192 GiB	5000	4,985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5	64	256 GiB	5000	4,985
D96ds_v5 / D96ads_v5	96	384 GiB	5000	4,985
Memoria optimizada
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5	2	16 GiB	1,718	1,703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5	4	32 GiB	3437	3,422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5	8	64 GiB	5000	4,985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5	16	128 GB	5000	4,985
E20ds_v4 / E20ds_v5 / E20ads_v5	20	160 GiB	5000	4,985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5	32	256 GiB	5000	4,985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5	48	384 GiB	5000	4,985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5	64	432 GiB	5000	4,985
E96ds_v5 / E96ads_v5	96	672 GiB	5000	4,985

Las ranuras de conexión reservadas, actualmente 15, podrían cambiar. Se recomienda comprobar periódicamente las conexiones reservadas totales en el servidor. Este número se calcula sumando los valores de los parámetros reserved_connections y superuser_reserved_connections del servidor. El número máximo de conexiones de usuario disponibles es max_connections : (reserved_connections + superuser_reserved_connections).

El valor predeterminado para el parámetro de servidor max_connections se calcula al aprovisionar la instancia del servidor flexible de Azure Database for PostgreSQL, en función del nombre del producto que seleccione para su proceso. Los cambios posteriores de la selección de producto en el proceso que admita el servidor flexible no tendrán ningún efecto en el valor predeterminado del parámetro de servidor max_connections de esa instancia. Se recomienda que, cada vez que cambie el producto asignado a una instancia, también ajuste el valor del parámetro max_connections según los valores de la tabla anterior.

Cambiar el valor de max_connections

Al configurar por primera vez la instancia de servidor flexible de Azure Database for Postgres, decide automáticamente el mayor número de conexiones que puede controlar simultáneamente. Este número se basa en la configuración del servidor y no se puede cambiar.

Sin embargo, puede usar la configuración max_connections para ajustar cuántas conexiones se permiten en un momento determinado. Después de cambiar esta configuración, debe reiniciar el servidor para que el nuevo límite empiece a funcionar.

Precaución

Aunque es posible aumentar el valor de max_connections más allá de la configuración predeterminada, le recomendamos que lo haga.

Las instancias pueden encontrar dificultades cuando la carga de trabajo se expande y exige más memoria. A medida que aumenta el número de conexiones, también aumenta el uso de memoria. Las instancias con memoria limitada pueden tener problemas como bloqueos o latencia alta. Aunque un valor mayor para max_connections puede ser aceptable cuando la mayoría de las conexiones están inactivas, puede provocar problemas de rendimiento significativos después de que se activen.

Si necesita más conexiones, se recomienda usar PgBouncer, la solución integrada de Azure para la administración del grupo de conexiones. Úselo en modo de transacción. Para empezar, se recomienda usar valores conservadores multiplicando los núcleos virtuales dentro del rango de 2 a 5. Después, supervise cuidadosamente el uso de recursos y el rendimiento de las aplicaciones para garantizar un funcionamiento sin problemas. Para obtener información detallada sobre PgBouncer, consulte PgBouncer en Azure Database for PostgreSQL: servidor flexible.

Cuando las conexiones superan el límite, es posible que reciba el siguiente error:

FATAL: sorry, too many clients already.

Cuando se utiliza Azure Database for PostgreSQL servidor flexible para una base de datos ocupada con un gran número de conexiones simultáneas, puede haber una presión significativa sobre los recursos. Esta variedad puede dar lugar a un uso elevado de la CPU, especialmente cuando se establecen muchas conexiones simultáneamente y cuando las conexiones tienen duraciones cortas (menos de 60 segundos). Estos factores pueden afectar negativamente al rendimiento general de la base de datos aumentando el tiempo invertido en procesar conexiones y desconexiones.

Tenga en cuenta que cada conexión en el servidor flexible de Azure Database for PostgreSQL, independientemente de si está inactiva o activa, consume una cantidad significativa de recursos de su base de datos. Este consumo puede provocar problemas de rendimiento más allá del uso elevado de la CPU, como la contención de discos y bloqueos. En el artículo Número de conexiones de base de datos en la wiki de PostgreSQL se describe este tema con más detalle. Para más información, consulte Identificación y resolución del rendimiento de la conexión en el servidor flexible de Azure Database for PostgreSQL.

Limitaciones funcionales

Las siguientes secciones enumeran consideraciones sobre lo que es y no es compatible con el servidor flexible Azure DB for PostgreSQL.

Operaciones de escalado

En este momento, el escalado vertical del almacenamiento del servidor requiere un reinicio del servidor.
Puede escalar el almacenamiento del servidor solo en incrementos de 2x. Consulte Proceso y almacenamiento para obtener más información.

Storage

Después de configurar el tamaño de almacenamiento, no se puede reducir. Tiene que crear un nuevo servidor con el tamaño de almacenamiento deseado, realizar una operación manual de volcado de memoria y restauración y migrar las bases de datos al nuevo servidor.
Cuando el uso del almacenamiento alcanza el 95 % o si la capacidad disponible es inferior a 5 GiB, lo que sea mayor, el servidor cambia automáticamente al modo de solo lectura para evitar los errores asociados a las situaciones de disco lleno. En raras ocasiones, si la tasa de crecimiento de los datos supera el tiempo necesario para cambiar al modo de solo lectura, es posible que el servidor se queden sin almacenamiento. Es posible habilitar el crecimiento automático del almacenamiento para evitar estos problemas y escalar automáticamente el almacenamiento en función de las demandas de carga de trabajo.
Se recomienda establecer reglas de alerta para storage used o storage percent cuando superen determinados umbrales para que pueda tomar medidas con antelación, como aumentar el tamaño del almacenamiento. Por ejemplo, podría establecer una alerta si el porcentaje de almacenamiento superase el 80 % de uso.
Si usa la replicación lógica, debe quitar la ranura de replicación lógica en el servidor principal si el suscriptor correspondiente ya no existe. De lo contrario, los archivos de registro de escritura anticipada (WAL) se acumulan en la principal y rellenan el almacenamiento. Si el almacenamiento supera un umbral determinado y si la ranura de replicación lógica no está en uso (debido a un suscriptor no disponible), el servidor flexible de Azure Database for PostgreSQL quita automáticamente esa ranura de replicación lógica sin usar. Esa acción libera los archivos WAL acumulados e impide que el servidor no esté disponible porque se rellena el almacenamiento.
No se admite la creación de espacios de tablas. Si va a crear una base de datos, no proporcione un nombre de espacio de tablas. El servidor flexible de Azure Database for PostgreSQL usa el predeterminado que se hereda de la base de datos de plantilla. No es seguro proporcionar un espacio de tablas como el temporal, ya que no podemos asegurarnos de que estos objetos permanecerán persistentes después de que los eventos como reinicios del servidor y conmutaciones por error de alta disponibilidad (HA).

Redes

Actualmente no es posible entrar y salir de una red virtual.
Actualmente no se admite la combinación de acceso público con la implementación en una red virtual.
Las reglas de firewall no se admiten en redes virtuales. En su lugar, puede usar grupos de seguridad de red.
Los servidores de bases de datos de acceso público pueden conectarse a la red pública de Internet; por ejemplo, a través de postgres_fdw. No puede restringir este acceso. Los servidores de redes virtuales pueden tener acceso saliente restringido a través de grupos de seguridad de red.

Alta disponibilidad

Consulte Alta disponibilidad (confiabilidad) en Azure DB for PostgreSQL: servidor flexible.

Zonas de disponibilidad

Actualmente no se admite el traslado manual de servidores a una zona de disponibilidad diferente. Sin embargo, mediante el uso de la zona de disponibilidad preferida como zona en espera, puede activar la alta disponibilidad. Después de establecer la zona en espera, puede conmutar por error a ella y, a continuación, desactivar la alta disponibilidad.

Motor de postgres, extensiones y PgBouncer

Postgres 10 y versiones anteriores no se admiten, ya que la comunidad de código abierto las retiró. Si debe usar una de estas versiones, debe usar la opción servidor único de Azure Database for PostgreSQL, que admite las versiones principales anteriores 9.5, 9.6 y 10.
El servidor flexible de Azure Database for PostgreSQL admite todas las extensiones contrib y muchas más. Para más información, consulte la información sobre extensiones de PostgreSQL.
El agrupador de conexiones PgBouncer integrado no está disponible actualmente para los servidores ampliables.

Operaciones de detención e inicio

Después de detener la instancia de servidor flexible de Azure DB for PostgreSQL, se inicia automáticamente después de 7 días.

Mantenimiento programado

Puede cambiar la ventana de mantenimiento personalizada a cualquier día o hora de la semana. Sin embargo, los cambios que realice después de recibir la notificación de mantenimiento no tendrán ningún impacto en el siguiente mantenimiento. Los cambios surten efecto solo con el siguiente mantenimiento programado mensual.

Copias de seguridad del servidor

El sistema administra las copias de seguridad. Actualmente no hay ninguna manera de ejecutar copias de seguridad manualmente. Se recomienda usar pg_dump en su lugar.
La primera instantánea es una copia de seguridad completa y las instantáneas consecutivas son copias de seguridad diferenciales. Las copias de seguridad diferenciales solo copian de seguridad de los datos modificados desde la última copia de seguridad de instantáneas.

Por ejemplo, si el tamaño de la base de datos es de 40 GB y el almacenamiento aprovisionado es de 64 GB, la primera copia de seguridad de instantáneas será de 40 GB. Ahora, si cambia 4 GB de datos, el tamaño de la siguiente copia de seguridad de instantánea diferencial será de sólo 4 GB. Los registros de transacciones (registros de escritura anticipada) están separados de las copias de seguridad completas y diferenciales, y se archivan continuamente.

Restauración del servidor

Cuando se usa la característica de restauración a un momento dado (PITR), el nuevo servidor se crea con las mismas configuraciones de proceso y almacenamiento que el servidor en el que se basa.
Los servidores de bases de datos de las redes virtuales se restauran en las mismas redes virtuales al restaurar desde una copia de seguridad.
El nuevo servidor creado durante una restauración no tiene las reglas de firewall que existían en el servidor original. Debe crear reglas de firewall por separado para el nuevo servidor.
No se admite la restauración en otra suscripción. Como solución alternativa, puede restaurar el servidor dentro de la misma suscripción y luego migrar el servidor restaurado a otra suscripción.