Alta disponibilidad en Azure Database for PostgreSQL

Azure Database for PostgreSQL admite la alta disponibilidad mediante el aprovisionamiento de réplicas principales y en espera separadas físicamente. Este modelo de alta disponibilidad está diseñado para garantizar que los datos confirmados nunca se pierdan durante los errores. En una configuración de alta disponibilidad (HA), los datos se confirman sincrónicamente en los servidores principal y en espera. El modelo está diseñado para que la base de datos no se convierta en un único punto de error en la arquitectura de software.

De forma predeterminada en la mayoría de las regiones, tu réplica en espera se implementa en una zona de disponibilidad distinta a la réplica principal (redundante por zona). También puede implementar las réplicas principal y en espera dentro de la misma zona de disponibilidad (zonal).

Características de alta disponibilidad

• Una réplica en espera se implementa en la misma configuración de máquina virtual ( incluidos los núcleos virtuales, el almacenamiento y la configuración de red) que el servidor principal.

• Puede agregar compatibilidad con zonas de disponibilidad para un servidor de bases de datos existente.

• Puede desactivar la alta disponibilidad, lo que elimina la réplica en espera.

• Puede elegir las zonas de disponibilidad para los servidores de bases de datos principal y en espera para obtener alta disponibilidad con redundancia de zona.

• Las operaciones como detener, iniciar y reiniciar se realizan en los servidores de base de datos principal y en espera al mismo tiempo.

• El servidor de base de datos principal realiza periódicamente copias de seguridad automáticas. Al mismo tiempo, la réplica en espera archiva continuamente los registros de transacciones en el almacenamiento de copia de seguridad. En el caso de los servidores con redundancia de zona, los datos de copia de seguridad se almacenan en el almacenamiento con redundancia de zona (ZRS). Los datos de copia de seguridad se almacenan en el almacenamiento con redundancia local (LRS) para los servidores configurados sin redundancia de zona, servidores zonales (zona única) y en regiones que no admiten zonas de disponibilidad.

• Los clientes siempre se conectan al nombre de host final del servidor de bases de datos principal.

• Los cambios en los parámetros del servidor también se aplican a la réplica en espera.

• Puede reiniciar el servidor para reflejar los cambios de parámetros estáticos del servidor.

• Las actividades de mantenimiento periódicas, como las actualizaciones de versiones secundarias, se realizan primero en el sistema de respaldo. Para reducir el tiempo de inactividad, el modo de espera se promueve a principal para que las cargas de trabajo puedan mantenerse mientras se aplican las tareas de mantenimiento en el nodo restante.

Nota:

Para garantizar que las funciones de alta disponibilidad sean correctas, configure los valores de parámetros max_replication_slots de servidor y max_wal_senders . La alta disponibilidad requiere cuatro de cada uno para controlar las conmutaciones por error y las actualizaciones sin interrupciones. Para una configuración de alta disponibilidad con cinco réplicas de lectura y 12 ranuras de replicación lógica, establezca los valores de los parámetros max_replication_slots y max_wal_senders en 21. Esta configuración es necesaria porque cada réplica de lectura y cada ranura de replicación lógica requieren uno de cada uno, además de los cuatro necesarios para que la alta disponibilidad funcione correctamente. Para obtener más información sobre max_replication_slots parámetros y max_wal_senders, consulte la documentación.

Tipos de soporte técnico de zona de disponibilidad

Azure Database for PostgreSQL admite modelos con redundancia de zona y zonales para configuraciones de alta disponibilidad. Ambas configuraciones de alta disponibilidad permiten la funcionalidad de conmutación automática por error sin pérdida de datos durante eventos planeados y no planeados.

• Con redundancia de zona. La alta disponibilidad con redundancia de zona implementa una réplica en espera en una zona diferente con capacidad de conmutación automática por error. La redundancia de zona proporciona el mayor nivel de disponibilidad, pero debe configurar la redundancia de aplicaciones entre zonas. Por ese motivo, elija la redundancia de zona cuando desee protección frente a errores de nivel de zona de disponibilidad y cuando se acepte la latencia entre las zonas de disponibilidad. Aunque puede haber algún impacto de latencia en las escrituras y confirmaciones debido a la replicación sincrónica, no afecta a las consultas de lectura. Este impacto es específico de las cargas de trabajo, el tipo de SKU que seleccione y la región.

  Puede elegir la región y las zonas de disponibilidad para los servidores principal y en espera. El servidor de réplica en espera se aprovisiona en la zona de disponibilidad elegida en la misma región con una configuración similar de proceso, almacenamiento y red que la del servidor principal. Los archivos de datos y los archivos de registro de transacciones (registros de escritura previa, también conocidos como WAL) se almacenan en el almacenamiento con redundancia local (LRS) dentro de cada zona de disponibilidad, almacenando automáticamente tres copias de datos. Una configuración con redundancia de zona proporciona aislamiento físico de toda la pila entre los servidores principal y en espera.

  

  La opción con redundancia de zona solo está disponible en las regiones que cuentan con soporte para zonas de disponibilidad.

  No se ofrece soporte para la redundancia entre zonas para:

  • Nivel de proceso ampliable
  • Regiones con disponibilidad de zona única

• Zona igual (zonal). Elija una implementación zonal cuando quiera lograr el mayor nivel de disponibilidad dentro de una sola zona de disponibilidad, pero con la latencia de red más baja. Puede elegir la región y la zona de disponibilidad para implementar el servidor de bases de datos principal. Un servidor de réplica en espera se aprovisiona automáticamente y se administra en la misma zona de disponibilidad con una configuración similar de proceso, almacenamiento y red que la del servidor principal. Una configuración zonal protege las bases de datos frente a errores de nivel de nodo y también ayuda a reducir el tiempo de inactividad de la aplicación durante los eventos de tiempo de inactividad planeados y no planeados. Los datos del servidor principal se replican de modo sincrónico en la réplica en espera. si se produce alguna interrupción en el servidor principal, el servidor cambia automáticamente a la réplica en espera.

  

  La opción de implementación zonal está disponible en todas las regiones de Azure donde puede implementar el Servidor flexible.

Nota:

Los modelos de implementación con redundancia de zona y zonales tienen el mismo comportamiento arquitectónico. Varias discusiones de las secciones siguientes se aplican a ambos, a menos que se indique lo contrario.

Recuperación de errores de zona

• Con redundancia de zona: Azure Database for PostgreSQL se traslada automáticamente al servidor en espera en un plazo de 60 a 120 segundos sin pérdida de datos.

• Zonal: si se produce un error en una zona, los servidores principal y en espera no están disponibles. Para recuperarse de un error de nivel de zona, puede realizar una restauración a un momento dado mediante la copia de seguridad. Puede elegir un punto de restauración personalizado con la hora más reciente para restaurar los datos más recientes. Un nuevo servidor flexible se implementa en otra zona no afectada. El tiempo necesario para la restauración depende de la copia de seguridad anterior y del volumen de registros de transacciones que se van a recuperar.

  Para más información sobre la restauración a un momento dado, consulte Copia de seguridad y restauración en el Servidor flexible de Azure Database for PostgreSQL.

Acuerdo de nivel de servicio

El modelo de redundancia de zona ofrece un SLA de tiempo de actividad más alto. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Azure Database for PostgreSQL sin alta disponibilidad

Aunque no se recomienda, puede configurar el servidor flexible sin alta disponibilidad habilitada. En el caso de los servidores flexibles configurados sin alta disponibilidad, el servicio proporciona almacenamiento con redundancia local con tres copias de datos y resistencia del servidor integrada para reiniciar automáticamente un servidor bloqueado y reubicar el servidor en otro nodo físico. Esta configuración ofrece un SLA de tiempo de actividad menor que los servidores con alta disponibilidad. Durante los eventos de conmutación por error planeados o no planeados, si el servidor deja de funcionar, el servicio mantiene la disponibilidad de los servidores mediante el siguiente procedimiento automatizado:

1. Se aprovisiona una nueva máquina virtual Linux de proceso.
2. El almacenamiento con archivos de datos se asigna a la nueva máquina virtual.
3. El motor de base de datos PostgreSQL pasa a estar en línea en la nueva máquina virtual.

En la imagen siguiente se muestra la transición entre la máquina virtual y el error de almacenamiento.

Configuración de opciones críticas para la empresa (alta disponibilidad)

Puede configurar la alta disponibilidad (HA) de dos maneras: alta disponibilidad con redundancia de zona, que coloca el servidor en espera en una zona de disponibilidad diferente para lograr una máxima resistencia de zona o alta disponibilidad de la misma zona, que implementa el servidor en espera en la misma zona que el servidor principal para minimizar la latencia.

La sección "Crítico para la empresa (alta disponibilidad)" proporciona una opción para crear un servidor de alta disponibilidad en espera con una configuración con redundancia de zona . Para simplificar la configuración y garantizar la resistencia de la zona, el portal proporciona una opción de resistencia zonal con dos botones de radio: Habilitado y Deshabilitado. Al seleccionar Habilitado, se intenta crear el servidor en espera en una zona de disponibilidad diferente (modo de alta disponibilidad con redundancia de zona). Si la región no admite HA redundante por zona, puede seleccionar la casilla de reserva para habilitar la HA en la misma zona (zonal).

Al activar la casilla de reserva, el sistema crea el servidor en espera en la misma zona. Si la capacidad zonal está disponible más adelante, Azure migrará automáticamente las cargas de trabajo desde alta disponibilidad en la misma zona hasta alta disponibilidad con redundancia de zona. Si no selecciona la casilla de verificación y la capacidad zonal no está disponible, la habilitación de alta disponibilidad fallará. Este diseño impone la alta disponibilidad con redundancia de zona como valor predeterminado al proporcionar una reserva controlada para la alta disponibilidad en la misma zona, asegurando que las cargas de trabajo finalmente logren una resiliencia completa por zona.

Creación de una instancia de Azure Database for PostgreSQL con la zona de disponibilidad habilitada

Para obtener información sobre cómo crear una instancia de Azure Database for PostgreSQL para alta disponibilidad con zonas de disponibilidad, consulte Inicio rápido: Creación de una instancia de Azure Database for PostgreSQL en Azure Portal.

Reimplementación y migración de una zona de disponibilidad

Para obtener información sobre cómo habilitar o deshabilitar la configuración de alta disponibilidad en su servidor flexible, tanto en modelos de implementación con redundancia de zona como zonales, consulte Administrar la alta disponibilidad en el servidor flexible.

Supervisar el estado de alta disponibilidad

La supervisión del estado de mantenimiento de alta disponibilidad (HA) en Azure Database for PostgreSQL proporciona una visión general continua del estado y la preparación de las instancias habilitadas para alta disponibilidad. Esta característica de supervisión aplica el marco de Resource Health Check (RHC) de Azure para detectar y alertar sobre cualquier problema que pueda afectar a la preparación de la conmutación por error de la base de datos o a la disponibilidad general. Al evaluar métricas clave como el estado de la conexión, el estado de conmutación por error y el estado de la replicación de datos, la supervisión del estado de alta disponibilidad permite la resolución proactiva de problemas y ayuda a mantener el tiempo de actividad y el rendimiento de la base de datos.

Utilice la supervisión del estado de salud de alta disponibilidad para:

• Obtenga información en tiempo real sobre el estado de las réplicas principales y en espera, con indicadores de estado que revelan posibles problemas, como el rendimiento degradado o el bloqueo de red.
• Configure alertas para notificaciones oportunas sobre cualquier cambio en el estado de alta disponibilidad, por lo que puede tomar medidas inmediatas para solucionar posibles interrupciones.
• Optimizar la preparación de la conmutación por error mediante la identificación y la resolución de problemas antes de que afecten a las operaciones de la base de datos.

Para obtener una guía detallada sobre cómo configurar e interpretar los estados de mantenimiento de alta disponibilidad, consulte Supervisión del estado de mantenimiento de alta disponibilidad (HA) para Azure Database for PostgreSQL.

Limitaciones de alta disponibilidad

• La replicación entre el servidor principal y en espera es sincrónica.

• No puede usar el servidor HA en espera para consultas de lectura.

• Dependiendo de la carga de trabajo y la actividad del servidor principal, el proceso de conmutación por error puede tardar más de 120 segundos, ya que la réplica en espera debe recuperarse antes de poder promocionarse.

• El servidor en espera normalmente recupera archivos WAL a 40 MB/s. Para versiones más grandes, esta tasa puede aumentar hasta 200 MB/s. Si la carga de trabajo supera este límite, puede encontrar tiempo prolongado para que la recuperación se complete durante la conmutación por error o después de establecer un nuevo modo de espera.

• Al reiniciar el servidor de bases de datos principal también se reinicia la réplica del servidor en espera.

• No se puede configurar un modo de espera adicional.

• No se pueden programar tareas de administración iniciadas por el cliente durante la ventana de mantenimiento administrado.

• Los eventos planificados, como el cálculo a escala y el almacenamiento a escala, se producen primero en el servidor en espera y luego en el servidor principal. Actualmente, el servidor no realiza la conmutación por error para estas operaciones planeadas.

• Si configura la descodificación lógica o la replicación lógica en un servidor flexible habilitado para alta disponibilidad:

  • En PostgreSQL 16 y versiones anteriores, las ranuras de replicación lógica no se conservan en el servidor en espera después de una conmutación por error de forma predeterminada.
  • Para asegurarse de que la replicación lógica sigue funcionando después de la conmutación por error, debe habilitar la pg_failover_slots extensión y configurar las opciones auxiliares, como hot_standby_feedback = on.
  • A partir de PostgreSQL 17, la sincronización de ranuras se admite de forma nativa. Si habilita las configuraciones de PostgreSQL correctas (sync_replication_slots, hot_standby_feedback), las ranuras de replicación lógica se conservan automáticamente después de la conmutación por error y no se requiere ninguna extensión.
  • Para conocer los pasos de configuración y los requisitos previos, consulte la documentación de la extensión PG_Failover_Slots.

• No se admite la configuración de zonas de disponibilidad entre la red privada (red virtual) y el acceso público con puntos de conexión privados. Debe configurar zonas de disponibilidad dentro de una red virtual (distribuidas entre zonas de disponibilidad dentro de una región) o el acceso público con puntos de conexión privados.

• Solo puede configurar zonas de disponibilidad dentro de una sola región. No se pueden configurar zonas de disponibilidad entre regiones.

Componentes y flujo de trabajo de alta disponibilidad

Finalización de transacciones

Una transacción de la aplicación desencadena una escritura y confirmación registrándose primero en el WAL del servidor principal. El servidor principal transmite estos registros al servidor en espera mediante el protocolo de streaming postgres. Cuando el almacenamiento del servidor en espera conserva los registros, el servidor principal confirma la finalización de escritura. La aplicación confirma su transacción solo después de esta confirmación. Este recorrido de ida y vuelta adicional agrega latencia a la aplicación. El porcentaje de impacto depende de la aplicación. Este proceso de confirmación no espera a que los registros se apliquen al servidor en espera. El servidor en espera permanece en modo de recuperación hasta que se promueve.

Comprobación de estado

La supervisión flexible del estado del servidor comprueba periódicamente el estado de los servidores principal y en espera. Después de varios pings, si la supervisión de estado detecta que no se puede acceder a un servidor principal, el servicio inicia una conmutación automática al servidor en espera. El algoritmo de supervisión de estado usa varios puntos de datos para evitar situaciones de falsos positivos.

Modos de conmutación por error

El Servidor flexible admite dos modos de conmutación por error, Conmutación por error planeada y Conmutación por error no planeada. En ambos modos, una vez que se interrumpe la replicación, el servidor en espera ejecuta la recuperación antes de su promoción como servidor primario y se habilita para operaciones de lectura/escritura. Con las entradas DNS automáticas actualizadas con el nuevo punto de conexión de servidor principal, las aplicaciones pueden conectarse al servidor mediante el mismo punto de conexión. Se establece un nuevo servidor en espera en segundo plano para que la aplicación pueda mantener la conectividad.

Estado de alta disponibilidad

El sistema supervisa continuamente el estado de los servidores principales y en espera. Toma las medidas adecuadas para solucionar los problemas, incluyendo la activación de una conmutación por error al servidor en espera. En la tabla siguiente se enumeran los posibles estados de alta disponibilidad:

Estado	Descripción
Inicializar	En proceso de crear un servidor en espera.
Replicando datos	Una vez creado el modo de espera, se está poniendo al día con la principal.
Saludable	La replicación está en estado estable y es correcta.
Conmutar por error	El servidor de bases de datos está en proceso de conmutar por error al de espera.
Quitar servidor en espera	En proceso de eliminar el servidor en espera.
Sin habilitar	La alta disponibilidad no está habilitada.

Nota:

Puede habilitar la alta disponibilidad durante la creación del servidor o en un momento posterior. Si habilita o deshabilita la alta disponibilidad durante la fase posterior a la creación, hágalo cuando la actividad del servidor principal sea baja.

Operaciones de estado estable

Las aplicaciones cliente de PostgreSQL se conectan al servidor principal mediante el nombre del servidor de base de datos. El servidor principal atiende directamente las lecturas de la aplicación. Al mismo tiempo, la aplicación recibe la confirmación de transacciones y solo escribe después de que los datos del registro hayan persistido tanto en el servidor principal como en la réplica en espera. Debido a esta ida y vuelta adicional, las aplicaciones pueden esperar una latencia elevada para las operaciones de escritura y confirmación. Puede supervisar el estado de la alta disponibilidad en el portal.

1. Los clientes se conectan al servidor flexible y realizan operaciones de escritura.
2. Los cambios se replican en el sitio de respaldo.
3. El servidor principal recibe una confirmación.
4. Se reconocen las escrituras y los compromisos.

Restauración a un momento dado de servidores de alta disponibilidad

Para los servidores flexibles configurados con alta disponibilidad, el sistema replica los datos de registro en tiempo real en el servidor en espera. Los errores de usuario en el servidor principal , como una eliminación accidental de una tabla o actualizaciones de datos incorrectas, se replican en la réplica en espera. Por lo tanto, no puede usar el modo de espera para recuperarse de estos errores lógicos. Para recuperarse de estos errores, debe realizar una restauración a un momento dado desde la copia de seguridad. Mediante la funcionalidad de restauración en el punto de tiempo de un servidor flexible, puede restaurar al estado anterior antes de que ocurriera el error. Se restaura un nuevo servidor de bases de datos como un servidor flexible zonal (zona única) con un nuevo nombre de servidor proporcionado por el usuario para las bases de datos configuradas con alta disponibilidad. Puede usar el servidor restaurado para varios casos de uso:

• Use el servidor restaurado para producción y, opcionalmente, habilite la alta disponibilidad con réplica en espera en la misma zona u otra zona de la misma región.

• Si desea restaurar un objeto, expórtelo desde el servidor de bases de datos restaurado e impórtelo al servidor de bases de datos de producción.

• Si quiere clonar el servidor de bases de datos con fines de prueba y desarrollo, o bien realizar la restauración para cualquier otro fin, puede realizar una restauración a un momento dado.

Para obtener información sobre cómo realizar una restauración a un momento dado de un servidor flexible, consulte Restauración a un momento dado de un servidor flexible.

Compatibilidad con la conmutación por error

Conmutación por error planeada

Los eventos de tiempo de inactividad planificados incluyen actualizaciones de software frecuentes programadas de Azure y actualizaciones de versiones secundarias. También puede usar una conmutación por error planeada para devolver el servidor principal a una zona de disponibilidad preferida. Al configurar la alta disponibilidad, estas operaciones se aplican primero a la réplica en espera mientras las aplicaciones siguen accediendo al servidor principal. Una vez que el proceso actualiza la réplica en espera, drena las conexiones del servidor principal y desencadena una conmutación por error que activa la réplica en espera como el servidor principal, manteniendo el mismo nombre de servidor de base de datos. Las aplicaciones cliente se vuelven a conectar con el mismo nombre del servidor de base de datos al nuevo servidor principal y pueden reanudar sus operaciones. El proceso establece un nuevo servidor en espera en la misma zona que la principal anterior.

Sugerencia

Cuando tiene un servidor flexible con redundancia de zona, también puede usar una conmutación por error planeada para devolver el servidor principal a una zona de disponibilidad preferida con una reducción del tiempo de inactividad. Por ejemplo, el servidor principal podría estar en una zona de disponibilidad diferente a la de la aplicación después de una conmutación por error no planeada. El proceso de conmutación programada mueve el servidor principal a su zona original y establece un nuevo servidor en espera en la misma zona que el servidor principal anterior.

En el caso de otras operaciones iniciadas por el usuario, como scale-compute o scale-storage, el proceso aplica los cambios en el modo de espera primero y, a continuación, el principal. Actualmente, el servicio no se traslada al modo de espera. Por lo tanto, mientras que la operación de escalado se ejecuta en el servidor principal, las aplicaciones experimentan un breve tiempo de inactividad.

También puede usar esta característica para conmutar por error en el servidor en espera con un tiempo de inactividad reducido. Por ejemplo, el servidor principal podría estar en una zona de disponibilidad diferente a la de la aplicación después de una conmutación por error no planeada. Quiere devolver el servidor principal a la zona anterior para colocarlo con la aplicación.

Al ejecutar esta característica, el proceso prepara primero el servidor en espera para asegurarse de que se ponga al día con las transacciones recientes, lo que permite a la aplicación seguir realizando lecturas y escrituras. El proceso promueve el modo de espera y corta las conexiones con el primario. La aplicación puede seguir escribiendo en el servidor principal mientras el proceso establece un nuevo servidor en espera en segundo plano. En la tabla siguiente se describen los pasos involucrados en el failover programado.

paso	Descripción	¿Se prevé algún tiempo de inactividad?
1	Espere a que el servidor en espera se sincronice con el servidor principal.	No
2	El sistema de supervisión interno inicia el flujo de trabajo de conmutación por error.	No
3	Las escrituras de aplicación se bloquean cuando el servidor en espera está cerca del número de secuencia de registro principal (LSN).	Sí
4	El servidor en espera se promueve como un servidor independiente.	Sí
5	El registro DNS se actualiza con la nueva dirección IP del servidor en espera.	Sí
6	La aplicación vuelve a conectarse y reanuda su lectura y escritura con el nuevo servidor primario.	No
7	Se establece un nuevo servidor de reserva. En el caso de los servidores con redundancia de zona, el nuevo servidor se encuentra en otra zona.	No
8	El servidor en espera comienza a recuperar los registros (desde Azure Blob) que perdió durante su establecimiento.	No
9	Se establece un estado estable entre el servidor principal y el servidor en espera.	No
10	Se ha completado el proceso de conmutación por error planeado.	No

El tiempo de inactividad de la aplicación se inicia en el paso 3 y puede reanudar la operación después del paso 5. El resto de los pasos se producen en segundo plano sin afectar a las escrituras y confirmaciones de la aplicación.

Sugerencia

Con el servidor flexible, puede programar opcionalmente las actividades de mantenimiento iniciadas por Azure eligiendo una ventana de 60 minutos en un día de su preferencia cuando se espera que las actividades de las bases de datos sean bajas. Las tareas de mantenimiento de Azure, como la aplicación de revisiones o las actualizaciones de versiones secundarias, se producen durante esa ventana. Si no elige una ventana personalizada, el sistema asigna una ventana de una hora entre las 11 p. m. y la hora local de 7 a. m. para el servidor. Estas actividades de mantenimiento iniciadas por Azure también se realizan en la réplica de espera para servidores flexibles que están configurados con zonas de disponibilidad.

Para obtener una lista de posibles eventos de tiempo de inactividad planeados, consulte Eventos de tiempo de inactividad planeados.

conmutación por error no planeada

Los tiempos de inactividad no planeados pueden producirse como resultado de interrupciones imprevistas, como errores de hardware subyacentes, problemas de red y errores de software. Si el servidor de bases de datos configurado con alta disponibilidad deja de funcionar inesperadamente, el proceso activa la réplica en espera y los clientes pueden reanudar sus operaciones. Si no configura la alta disponibilidad (HA) y se produce un error en el intento de reinicio, el proceso aprovisiona automáticamente un nuevo servidor de bases de datos. Aunque no se puede evitar un tiempo de inactividad no planeado, el servidor flexible ayuda a mitigar el tiempo de inactividad realizando automáticamente operaciones de recuperación sin necesidad de intervención humana.

Para obtener información sobre las conmutaciones por error no planeadas y el tiempo de inactividad, incluidos los posibles escenarios, consulte Mitigación de tiempo de inactividad no planeado.

conmutación por error forzada

Puede usar una conmutación por error forzada para las pruebas de conmutación por error, simulando un escenario de interrupción no planificado mientras ejecuta su carga de trabajo de producción y observa el tiempo de inactividad de su aplicación. También puede usar una conmutación por error forzada cuando el servidor principal deja de responder.

Una conmutación por error forzada desactiva el servidor principal e inicia el flujo de trabajo de conmutación por error en el que se realiza la operación de promoción en espera. Una vez que el servidor en espera completa el proceso de recuperación hasta los últimos datos confirmados, pasa a ser el servidor principal. Los registros DNS se actualizan y la aplicación puede conectarse al servidor principal promocionado. La aplicación puede seguir escribiendo en el servidor principal mientras se establece un nuevo servidor en espera en segundo plano, y eso no afecta al tiempo de actividad.

En la tabla siguiente se describen los pasos durante un failover forzado:

paso	Descripción	¿Se prevé algún tiempo de inactividad?
1	El servidor principal se detiene poco después de recibir la solicitud de conmutación por error.	Sí
2	La aplicación encuentra tiempo de inactividad cuando el servidor principal está inactivo.	Sí
3	El sistema de supervisión interno detecta el error e inicia una conmutación por error en el servidor en espera.	Sí
4	El servidor en espera entra en modo de recuperación antes de promocionarse por completo como un servidor independiente.	Sí
5	El proceso de conmutación por error espera a que se complete la recuperación en espera.	Sí
6	Una vez que el servidor está activo, el proceso actualiza el registro DNS con el mismo nombre de host, pero usa la dirección IP del modo de espera.	Sí
7	La aplicación puede volver a conectarse al nuevo servidor principal y reanudar la operación.	No
8	Se establece un servidor en espera en la zona preferida.	No
9	El servidor en espera comienza a recuperar los registros (desde Azure Blob) que perdió durante su establecimiento.	No
10	Se establece un estado estable entre el servidor principal y el servidor en espera.	No
11	Se ha completado el proceso de conmutación por error forzada.	No

El tiempo de inactividad de la aplicación se inicia después del paso 1 y continúa hasta que finaliza el paso 6. Los demás pasos se ejecutan en segundo plano sin afectar a las escrituras y confirmaciones de la aplicación.

Importante

El proceso de conmutación por error de un extremo a otro incluye (a) conmutar por error al servidor en espera después del error principal y (b) establecer un nuevo servidor en espera en un estado estable. Dado que su aplicación sufre un tiempo de inactividad hasta que se completa la conmutación por error al modo de espera, mida el tiempo de inactividad desde la perspectiva de su aplicación/cliente en lugar de desde el proceso global de conmutación por error de extremo a extremo.

Consideraciones al realizar conmutaciones por error forzadas

• El tiempo total de operación de un extremo a otro puede ser mayor que el tiempo de inactividad real experimentado por la aplicación.

  Importante

  Observe siempre el tiempo de inactividad desde la perspectiva de la aplicación.

• No realice conmutaciones por error inmediatas consecutivas. Espere al menos 15-20 minutos entre las conmutaciones por error, para que el nuevo servidor en espera pueda establecerse completamente.

• Realice una conmutación por error forzada durante un período de baja actividad para reducir el tiempo de inoperatividad.

Procedimientos recomendados para las estadísticas de PostgreSQL después de la conmutación por error

Después de una conmutación por error de PostgreSQL, mantener un rendimiento óptimo de la base de datos implica comprender los distintos roles de pg_statistic y las vistas pg_stat_* . La pg_statistic tabla almacena las estadísticas del optimizador, que son cruciales para el planificador de consultas. Estas estadísticas incluyen distribuciones de datos dentro de las tablas y permanecen intactas después de una conmutación por error, lo cual garantiza que el planificador de consultas pueda seguir optimizando la ejecución de consultas de forma eficaz en función de la información de distribución de datos histórica precisa.

En cambio, las vistas pg_stat_* generan datos estadísticos de actividad en tiempo de ejecución, como el número de exámenes, lecturas de tuplas y actualizaciones. Estas estadísticas se almacenan en memoria y se restablecen tras la recuperación frente a errores. Un ejemplo es pg_stat_user_tables, que realiza un seguimiento de la actividad de las tablas definidas por el usuario. Este restablecimiento refleja con precisión el estado operativo del nuevo servidor principal, pero también implica la pérdida de métricas históricas de actividad que podrían ser útiles para el proceso de limpieza automática y otras eficiencias operativas.

Dada esta distinción, podría plantearse ejecutar ANALYZE después de una recuperación frente a errores de PostgreSQL. Esta acción actualiza los pg_stat_* datos (por ejemplo, pg_stat_user_tables) con nuevas estadísticas de actividad de limpieza, lo que ayuda al proceso de limpieza automática, que, a su vez, garantiza que el rendimiento de la base de datos sea óptimo en su nuevo rol. Este paso proactivo supera la brecha entre conservar las estadísticas esenciales del optimizador y actualizar las métricas de actividad para alinearse con el estado actual de la base de datos.