Escalado de recursos en Azure Database for PostgreSQL

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

Escalado vertical

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

El rendimiento de red de la instancia depende de los valores que elija para cpu y memoria.

Después de crear una instancia de servidor flexible de 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.

Puede escalar el nivel de computación entre Ampliable, De uso general y Optimizado para Memoria para ajustarse a las necesidades de su carga de trabajo. En cada uno de estos niveles, puede elegir entre una amplia selección de hardware preconfigurado de diferentes generaciones con distintos números de CPU y cantidades de memoria instalada. Puede seleccionar la opción que admite los requisitos de recursos al tiempo que mantiene los costos operativos reducidos y ajustados a sus necesidades.

Puede escalar o reducir verticalmente el número de núcleos virtuales 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.

Puede escalar estos recursos mediante varias interfaces. Por ejemplo, puede usar Azure Portal o la CLI de Azure.

Nota:

Después de aumentar el tamaño del almacenamiento asignado a la instancia, no puede reducirlo a un tamaño menor.

Escalado horizontal

Los clústeres elásticos de Azure Database for PostgreSQL permiten escalar horizontalmente la base de datos para admitir cargas de trabajo de datos que se extienden más allá de las funcionalidades de una instancia de base de datos única. Los clústeres elásticos también permiten 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

Otro enfoque para escalar horizontalmente la instancia es crear 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.

En una configuración escalable horizontalmente, también puede escalar verticalmente la instancia principal y las réplicas de lectura.

Al cambiar el número de núcleos virtuales o el nivel de proceso, la instancia 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 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, 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 puede establecer ninguna nueva conexión.

Normalmente este proceso con escalado normal podría tardar entre 2 y 10 minutos. Con la característica de escalado de tiempo de inactividad casi cero, 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.

Funcionamiento

Al actualizar la instancia de servidor flexible de Azure Database for PostgreSQL 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 la instancia y, a continuación, cambia a la nueva máquina virtual con una breve interrupción. Después, 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 es compatible con instancias de servidor flexible de Azure Database para PostgreSQL tanto de alta disponibilidad (HA) como no de alta disponibilidad (no HA).

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.

Nota:

El escalado de tiempo de inactividad casi cero es el tipo de operación predeterminado. 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. 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 una instancia 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

• Administración de Azure Database for PostgreSQL