Compartir a través de

Límites en Azure Database for PostgreSQL

En las secciones siguientes se describen los límites de capacidad y funcionales de las instancias de servidor flexible de Azure Database for PostgreSQL. Para obtener más información sobre los niveles de recursos (proceso, memoria y almacenamiento), consulte los artículos acerca de 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. Una instancia de 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, la tabla reduce el valor de las conexiones de usuario máximas 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 5.000 4,985
B16ms 16 64 GiB 5.000 4,985
B20ms 20 80 GiB 5.000 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 5.000 4,985
D32s_v3/D32ds_v4/D32ds_v5/D32ads_v5 32 128 GB 5.000 4,985
D48s_v3/D48ds_v4/D48ds_v5/D48ads_v5 48 192 GiB 5.000 4,985
D64s_v3/D64ds_v4/D64ds_v5/D64ads_v5 64 256 GiB 5.000 4,985
D96ds_v5/D96ads_v5 96 384 GiB 5.000 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 5.000 4,985
E16s_v3/E16ds_v4/E16ds_v5/E16ads_v5 16 128 GB 5.000 4,985
E20ds_v4/E20ds_v5/E20ads_v5 20 160 GiB 5.000 4,985
E32s_v3/E32ds_v4/E32ds_v5/E32ads_v5 32 256 GiB 5.000 4,985
E48s_v3/E48ds_v4/E48ds_v5/E48ads_v5 48 384 GiB 5.000 4,985
E64s_v3/E64ds_v4/E64ds_v5/E64ads_v5 64 432 GiB 5.000 4,985
E96ds_v5/E96ads_v5 96 672 GiB 5.000 4,985

Las ranuras de conexión reservadas, actualmente en 15, pueden 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 sistema calcula el valor predeterminado del parámetro de max_connections servidor al aprovisionar la instancia del servidor flexible de Azure Database for PostgreSQL, en función del nombre del producto que seleccione para su proceso. Cualquier cambio posterior en la selección del producto para el recurso de cálculo que soporte la instancia no tendrá ningún efecto sobre el valor predeterminado para el max_connections parámetro de servidor 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. La configuración del servidor determina este número 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.

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

FATAL: sorry, too many clients already.

Cuando se usa una instancia de servidor flexible de Azure Database for PostgreSQL para una base de datos ocupada con un gran número de conexiones simultáneas, puede haber una presión significativa en 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.

Cada conexión de una instancia de servidor flexible de Azure Database for PostgreSQL, independientemente de si está inactiva o activa, consume una cantidad significativa de recursos de la 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. El artículo Número de conexiones de base de datos en la wiki de PostgreSQL describe este artículo con más detalle. Para más información, consulte Identificación y resolución del rendimiento de la conexión en Azure Postgres.

Limitaciones funcionales

En las secciones siguientes, se enumeran las consideraciones sobre lo que se admite y lo que no se admite para sus instancias de servidor flexible en Azure Database for PostgreSQL.

Operaciones de escalado

  • En este momento, el escalado vertical del almacenamiento del servidor requiere un reinicio del servidor.
  • El almacenamiento del servidor solo se puede ampliar en incrementos de 2x. Consulte Almacenamiento para obtener más información.
  • Actualmente no se admite la reducción del tamaño de almacenamiento del servidor. La única manera de realizar esta operación es volcarla y restaurarla en una nueva instancia de servidor flexible de Azure Database for PostgreSQL.

Almacenamiento

  • 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 los 95% o si la capacidad disponible es inferior a 5 GiB (lo que sea más), el sistema cambia automáticamente el servidor al modo de solo lectura para evitar errores asociados a 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), una instancia de servidor flexible de Azure Database for PostgreSQL quita automáticamente esa ranura de replicación lógica sin usar. Esta 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. Una instancia de servidor flexible de Azure Database for PostgreSQL usa el espacio de tablas predeterminado que hereda 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).
  • Archivos de datos huérfanos y discrepancias de uso de disco: en raras ocasiones, PostgreSQL puede dejar archivos de datos huérfanos en el disco, archivos que ya no tienen entradas correspondientes en el catálogo del sistema de la base de datos (que realiza un seguimiento de todas las tablas y datos). Esto puede ocurrir si se crea una tabla y se rellena dentro de una transacción que no se puede completar correctamente (por ejemplo, debido a un bloqueo o interrupción del servidor), lo que produce una discrepancia entre el tamaño notificado por la base de datos y el uso real del disco. Este comportamiento procede del código base de la comunidad de PostgreSQL y no es específico de Azure. La comunidad de PostgreSQL conoce el problema y está explorando mejoras para la limpieza automática en futuras versiones. Para obtener más información, consulte: PostgreSQL: Archivos huérfanos en PostgreSQL. Esto puede provocar un consumo inesperado de almacenamiento o disco.
    • Cómo detectar: Comparar el tamaño notificado por la base de datos (mediante consultas como SELECT pg_database_size('your_database')) con métricas de Azure Portal para el uso real del disco. Si hay una discrepancia significativa, es posible que los archivos huérfanos sean la causa. Si es así:
      • Ejecute VACUUM FULL en las tablas afectadas para reclamar espacio (tenga en cuenta que se trata de un uso intensivo de recursos, requiere un bloqueo de tabla y puede requerir tiempo de inactividad).
      • También puede usar herramientas como las extensiones pg_repack o pg_squeeze para reorganizar sin interrupciones, pero primero probar en un entorno no de producción.
      • Supervisión mediante métricas de Azure Portal para umbrales de uso de disco. Si el problema persiste o no está seguro, póngase en contacto con el soporte técnico de Azure para obtener ayuda.
    • Cómo evitar: Asegúrese de que las transacciones se administran correctamente en las aplicaciones para minimizar las operaciones incompletas. Supervise periódicamente el uso del disco a través de las métricas de Azure Portal. La actualización a la versión de PostgreSQL compatible más reciente puede incluir correcciones de la comunidad para problemas relacionados.

Redes

  • Actualmente no se admite la migración y salida de una red virtual.
  • Actualmente no se admite la combinación de acceso público con la implementación en una red virtual.
  • Las redes virtuales no admiten reglas de firewall. 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

Zonas de disponibilidad

  • Actualmente no se admite el traslado manual de servidores a otra zona de disponibilidad. 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

  • Una instancia de servidor flexible de Azure Database for PostgreSQL admite todas las características del motor de PostgreSQL, incluidas las particiones, la replicación lógica y los contenedores de datos externos.
  • Una instancia de servidor flexible de Azure Database for PostgreSQL admite todas las contrib extensiones y mucho más. Para más información, consulte la información sobre extensiones de PostgreSQL.
  • Actualmente, los servidores ampliables no tienen acceso al agrupador de conexiones pgBouncer integrado.

Operaciones de detención e inicio

  • Después de detener la instancia de servidor flexible de Azure Database for PostgreSQL, se inicia automáticamente después de siete 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 se pueden 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 es 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 sistema crea el nuevo servidor con las mismas configuraciones de proceso y almacenamiento que el servidor en el que se basa.
  • El sistema restaura los servidores de bases de datos de las redes virtuales 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.

Seguridad

  • Postgres 14 y versiones posteriores deshabilitan el uso del hashing MD5 y las contraseñas nativas de Postgres del sistema utilizan únicamente el método SCRAM-SHA-256.

Contenido relacionado

  • Last updated on