Escalado de recursos en Azure Database for PostgreSQL: servidor flexible
SE APLICA A: 
Azure Database for PostgreSQL con servidor flexible
Azure Database for PostgreSQL: servidor flexible 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 la CPU y la memoria.
Una vez creada 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.
El nivel de proceso puede escalarse o reducirse verticalmente entre los niveles Ampliable, De uso general y Optimizado para memoria, para ajustarse a las necesidades de su carga de trabajo. En cada uno de estos niveles, hay una amplia selección de hardware preconfigurado de diferentes generaciones y con más o menos CPU y más o menos memoria instalada. Entre esa amplia selección podrá elegir la que sea compatible con sus necesidades de recursos en cada momento, manteniendo sus costos operativos reducidos y ajustados a sus necesidades.
El número de núcleos virtuales y la memoria instalada se pueden escalar o reducir verticalmente. El nivel de almacenamiento también puede escalarse o reducirse para adaptarse a los requisitos de rendimiento e IOPS que exija su carga de trabajo. El tamaño de almacenamiento solo se puede aumentar. Además, en función de los requisitos, puede aumentar o disminuir el período de retención de copias de seguridad entre 7 y 35 días.
Estos recursos se pueden escalar 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
Puede escalar su instancia horizontalmente creando 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 escalada horizontalmente, la instancia principal y las réplicas de lectura también se pueden escalar verticalmente.
Al cambiar el número de núcleos virtuales o el nivel de proceso, se reinicia la instancia 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, 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. Para más información, consulte Opciones de Almacenamiento en Azure Database for PostgreSQL: servidor flexible.
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 reducido
El escalado de tiempo de inactividad reducido 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 reducido, 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, 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 está ejecutando actualmente su instancia, y luego cambia a la nueva con una breve interrupción. Después, un proceso en segundo plano elimina la máquina virtual antigua. Todo este proceso se produce sin costo adicional para usted.
Este proceso permite realizar actualizaciones sin interrupciones, al tiempo 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. Para usar esta funcionalidad no se necesita ninguna acción del cliente.
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 reducido es el tipo predeterminado de operación. 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 reducido.
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 de
Time-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 reducido funcione, permita todas las conexiones entrantes y salientes entre las direcciones IP de la subred delegada, cuando use redes virtuales integradas. Si estas conexiones no están permitidas, el proceso de escalado de tiempo de inactividad reducido no funciona y el escalado se produce mediante el flujo de trabajo de escalado estándar.
- El escalado de tiempo de inactividad reducido no funciona si hay restricciones de capacidad regionales o límites de cuota en la suscripción.
- El escalado de tiempo de inactividad reducido no funciona para un servidor de réplica porque 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 reducido no funciona si un servidor insertado en la red virtual no tiene suficientes direcciones IP utilizables en una 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 reducido. 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 reducido no funciona con tablas sin etiquetar. Si usa tablas no registradas para alguno de sus datos, perderá todos los datos de esas tablas tras el escalado de tiempo de inactividad reducido.