Escalado de recursos en Azure Database for PostgreSQL: servidor flexible

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

Escalado vertical

Escale verticalmente el servidor agregando más recursos al servidor flexible Azure Database for PostgreSQL. Puede aumentar o disminuir el número de CPU y memoria asignadas.

El rendimiento de red del servidor depende de los valores que elija para cpu y memoria.

Después de crear un servidor flexible Azure Database for PostgreSQL, puede escalar de forma independiente:

• Nivel de proceso y SKU.
• Nivel de almacenamiento y tamaño.
• Período de retención de copia de seguridad.

Escala el nivel de proceso hacia arriba o hacia abajo entre Burstable, De uso general y Optimizado para memoria para adaptarlo a las necesidades de tu carga de trabajo. En cada uno de estos niveles, elija entre una amplia selección de hardware preconfigurado de diferentes generaciones con distintos números de CPU y cantidades de memoria instalada. Seleccione la opción que admite los requisitos de recursos al tiempo que mantiene los costos operativos reducidos y ajustados a sus necesidades.

Aumente o reduzca el número de vCores y la memoria instalada. También puede configurar el nivel de almacenamiento hacia arriba o hacia abajo para adaptarse a los requisitos de rendimiento e IOPS que exige la carga de trabajo. Solo puede aumentar el tamaño de almacenamiento. En función de los requisitos, puede aumentar o disminuir el período de retención de copia de seguridad entre 7 y 35 días.

Escala estos recursos usando múltiples interfaces. Por ejemplo, puede usar el portal de Azure o CLI de Azure.

Escalado horizontal

Azure Database for PostgreSQL clústeres elásticos permiten escalar horizontalmente la base de datos para admitir cargas de trabajo de datos que van más allá de las funcionalidades de un único servidor de bases de datos. Los clústeres elásticos también proporcionan la posibilidad de ejecutar operaciones paralelas simultáneamente en todos los nodos de un clúster, lo que aumenta significativamente el rendimiento y desbloquea una latencia ultra baja. Los clústeres elásticos ofrecen dos modelos de particionamiento de tablas: particionamiento basado en filas y particionamiento basado en esquemas.

Escalado de réplica de lectura

Puede escalar horizontalmente el servidor mediante la creación de réplicas de lectura. Las réplicas de lectura te permiten escalar tus cargas de trabajo de lectura en servidores flexibles independientes de Azure Database for PostgreSQL. No afectan al rendimiento y la disponibilidad del servidor principal.

En una configuración escalada horizontalmente, también puedes escalar verticalmente el servidor principal y las réplicas de lectura.

Al cambiar el número de núcleos virtuales o el nivel de proceso, el servidor se reinicia para que el nuevo hardware asignado comience a ejecutar la carga de trabajo del servidor. Durante este tiempo, el sistema pasa al nuevo tipo de servidor. No se pueden establecer nuevas conexiones 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, 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. Para más información, consulte Opciones de almacenamiento en Azure Database for PostgreSQL.

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, realice operaciones de escalado durante las horas fuera del pico. 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 reinicia para aplicar la nueva configuración. Durante esta transición al nuevo servidor, no se pueden establecer nuevas conexiones.

Normalmente, este proceso tarda entre 2 y 10 minutos con escalado normal. Al usar la función de escalado con tiempo de inactividad casi nulo, esta duración se reduce 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.

Cómo funciona

Al actualizar el Azure Database for PostgreSQL servidor flexible en escenarios de escalado, el servicio crea una nueva máquina virtual para el servidor con la configuración actualizada. A continuación, se sincroniza con la máquina virtual que ejecuta actualmente el servidor y, a continuación, cambia a la nueva máquina virtual con una breve interrupción. Un proceso en segundo plano elimina la máquina virtual antigua.

Este proceso permite actualizaciones sin problemas con un tiempo de inactividad mínimo y se desencadena automáticamente al cambiar los niveles de almacenamiento o proceso. No es necesario realizar ninguna acción para usar esta funcionalidad. Esta funcionalidad se admite tanto para las implementaciones con alta disponibilidad como para las implementaciones sin alta disponibilidad de Azure Database for PostgreSQL flexible server.

En las configuraciones de escalado horizontal, compuestas por un servidor primario y una o varias réplicas 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.

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. El proceso de escalado no controla directamente este período. 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, permita todas las conexiones entrantes y salientes entre las direcciones IP de la subred delegada, cuando se usan redes integradas de red virtual. Si no permite estas conexiones, el proceso de escalado con casi cero tiempo de inactividad no funciona y el escalado se produce a través del flujo de trabajo estándar de escalado.
• El escalado de tiempo de inactividad casi cero no funciona si hay restricciones de capacidad regionales o límites de cuota en la suscripción.
• El escalado de tiempo de inactividad casi cero no funciona para un servidor de réplica, ya que solo se admite en el servidor principal. En el caso de los servidores de réplica, la operación de escalado pasa automáticamente por el proceso normal.
• El escalado de tiempo de inactividad casi cero no funciona si una servidor insertado en la red virtual no tiene suficientes direcciones IP utilizables en la subred delegada. Si tiene un servidor independiente, se necesita una dirección IP adicional. Para un servidor con alta disponibilidad habilitada, se requieren 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 obtener más información, consulte Habilitación de la extensión pg_failover_slots en una instancia de servidor flexible.
• El escalado de tiempo de inactividad casi cero no funciona con tablas sin etiquetar. Si usa tablas sin registro para cualquiera de sus datos, perderá todos los datos de esas tablas después del escalado con tiempo de inactividad cerca de cero.
• Cerca de cero [Versión preliminar] no funciona si se escala el proceso del servidor desde o hasta un tamaño de proceso de 1 o 2 núcleos virtuales del nivel Ampliable.

Contenido relacionado

• Administrar Azure Database for PostgreSQL