Compartir a través de

Escalado de recursos en Azure Database for PostgreSQL: servidor flexible

  • Artículo

SE APLICA A: Azure Database for PostgreSQL: servidor flexible

Azure Database for PostgreSQL: servidor flexible admite opciones de escalado vertical y horizontal.

Escalado vertical: puede escalar verticalmente si agrega más recursos a la instancia de servidor flexible de Azure Database for PostgreSQL, como aumentar el número de CPU y memoria asignadas por la instancia. El rendimiento de red de la instancia depende de los valores que elija para la CPU y la memoria.

Después de crear una instancia de servidor flexible de Azur  Database for PostgreSQL, puede cambiar lo siguiente de forma independiente:

  • CPU (núcleos virtuales).
  • Cantidad de almacenamiento.
  • Período de retención de copia de seguridad.

El número de núcleos virtuales se puede escalar o reducir verticalmente, pero el tamaño de almacenamiento solo se puede aumentar. También puede escalar o reducir verticalmente el período de retención de la copia de seguridad de 7 a 35 días. Los recursos se pueden escalar mediante varias herramientas, por ejemplo, Azure Portal o la CLI de Azure.

Nota:

Después de aumentar el tamaño de almacenamiento, no puede volver a un tamaño de almacenamiento más pequeño.

Escalado horizontal: puede escalar horizontalmente mediante la creación de réplicas de lectura. Las réplicas de lectura permiten escalar las cargas de trabajo de lectura en instancias independientes de servidor flexible de Azure Database for PostgreSQL. No afectan al rendimiento ni la disponibilidad de la instancia principal.

Al cambiar el número de núcleos virtuales o el nivel de proceso, la instancia se reinicia para que se aplique el nuevo tipo de servidor. Durante este tiempo, el sistema pasa al nuevo tipo de servidor. No se pueden establecer conexiones nuevas y se revierten todas las transacciones no confirmadas.

El tiempo total necesario para reiniciar el servidor depende del proceso de recuperación tras el bloqueo y de la actividad de la base de datos en el momento del reinicio. El reinicio suele tardar un minuto o menos, pero pueden ser varios. El tiempo depende de la actividad transaccional cuando se ha iniciado el reinicio.

Si la aplicación es sensible a la pérdida de transacciones en curso que pueden producirse durante el escalado de proceso, se recomienda implementar un patrón de reintento de transacciones.

Para el escalado del almacenamiento no es necesario reiniciar el servidor en la mayoría de los casos. Del mismo modo, los cambios del período de retención de copia de seguridad son una operación en línea. Para mejorar el tiempo de reinicio, se recomienda realizar operaciones de escalado durante las horas de poca actividad. Este enfoque reduce el tiempo necesario para reiniciar el servidor de bases de datos.

Escalado de tiempo de inactividad casi cero

El escalado sin casi tiempo de inactividad es una característica diseñada para minimizar el tiempo de inactividad al modificar los niveles de almacenamiento y proceso. Si modifica el número de núcleos virtuales o cambia el nivel de proceso, el servidor se somete a un reinicio para aplicar la nueva configuración. Durante esta transición al nuevo servidor, no se puede establecer ninguna nueva conexión.

Normalmente este proceso con escalado normal podría tardar entre 2 y 10 minutos. Con la nueva característica de escalado de tiempo de inactividad casi cero, esta duración se ha reducido a menos de 30 segundos. Esta reducción del tiempo de inactividad durante el escalado de recursos mejora la disponibilidad general de la instancia de base de datos.

Funcionamiento

Al actualizar la instancia de servidor flexible de Azure Database for PostgreSQL en escenarios de escalado, se crea una copia del servidor (VM) con la configuración actualizada. La sincronizamos con la actual y cambiamos a la nueva copia con una interrupción de 30 segundos. Después, retiramos el servidor antiguo. El proceso se produce sin costo adicional.

Este proceso permite actualizaciones sin problemas a la vez que minimiza el tiempo de inactividad y garantiza la rentabilidad. Este proceso de escalado se desencadena cuando se realizan cambios en los niveles de almacenamiento y proceso. Esta característica solo está disponible en servidores que no son de alta disponibilidad y está habilitada en todas las regiones de Azure. Para usar esta funcionalidad no se necesita ninguna acción del cliente.

En el caso de los servidores configurados para réplica de lectura, las operaciones de escalado deben seguir una secuencia específica para garantizar la coherencia de los datos y minimizar el tiempo de inactividad. Para obtener más información sobre esa secuencia, consulte escalado con réplicas de lectura.

Nota:

El proceso de escalado de tiempo de inactividad casi cero es la operación predeterminada. Cuando se encuentran las siguientes limitaciones, el sistema cambia al escalado normal, lo que implica más tiempo de inactividad en comparación con el escalado de tiempo de inactividad casi cero.

Expectativas precisas de tiempo de inactividad

  • Duración del tiempo de inactividad: en la mayoría de los casos, el tiempo de inactividad oscila entre 10 y 30 segundos.
  • Consideraciones adicionales: después de un evento de escalado, hay un período deTime-To-Live (TTL) de DNS inherente de aproximadamente 30 segundos. Este período no se controla directamente mediante el proceso de escalado. Es un elemento estándar del comportamiento de DNS. Por lo tanto, desde la perspectiva de una aplicación, el tiempo de inactividad total experimentado durante el escalado podría oscilar entre 40 y 60 segundos.

Consideraciones y limitaciones

  • Para que el escalado de tiempo de inactividad casi cero funcione, habilite todas las conexiones entrantes o salientes entre las direcciones IP de la subred delegada cuando use redes integradas de red virtual. Si estas conexiones no están habilitadas, el proceso de escalado de tiempo de inactividad casi cero no funciona y el escalado se produce mediante el flujo de trabajo de escalado estándar.
  • El escalado de tiempo de inactividad casi cero no funciona si hay restricciones de capacidad regionales o límites de cuota en las suscripciones de cliente.
  • El escalado de tiempo de inactividad casi cero no funciona para un servidor de réplica porque solo se admite en el servidor principal. Para un servidor de réplica, pasa automáticamente por un proceso de escalado normal.
  • El escalado de tiempo de inactividad casi cero no funciona si un servidor insertado en la red virtual con una subred delegada no tiene suficientes direcciones IP utilizables. Si tiene un servidor independiente, se necesita una dirección IP adicional. Para un servidor habilitado para alta disponibilidad, se necesitan dos direcciones IP adicionales.
  • Las ranuras de replicación lógica no se conservan durante un evento de conmutación por error de tiempo de inactividad cercano a cero. Para mantener las ranuras de replicación lógica y garantizar la coherencia de los datos después de una operación de escala, use la extensión pg_failover_slot. Para más información,vea Habilitación de la extensión en un servidor flexible.
  • El escalado de tiempo de inactividad casi cero no funciona con tablas sin etiquetar. Los clientes que usan tablas sin etiquetar para cualquiera de sus datos perderán todos los datos de esas tablas después del escalado de tiempo de inactividad casi cero.
  • Actualmente no se admite el escalado de tiempo de inactividad cercano a cero para los servidores habilitados para alta disponibilidad (HA).

Contenido relacionado