Confiabilidad en Azure Database for PostgreSQL

Azure Database for PostgreSQL es un servicio de base de datos totalmente administrado diseñado para ofrecer un control y flexibilidad pormenorizados sobre las funciones de administración de bases de datos y las opciones de configuración. El servicio proporciona funcionalidades de alta disponibilidad y recuperación ante desastres en función de sus requisitos.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Azure Database for PostgreSQL sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad, interrupciones de región y mantenimiento del servicio. También se describe cómo puede usar copias de seguridad para recuperarse de otros tipos de problemas y se resalta cierta información clave sobre el contrato de nivel de servicio (SLA) de Azure Database for PostgreSQL.

Recomendaciones de implementación de producción

Para obtener información sobre cómo implementar Azure Database for PostgreSQL para admitir los requisitos de confiabilidad de la solución y cómo afecta la confiabilidad a otros aspectos de la arquitectura, consulte Procedimientos recomendados de arquitectura para Azure Database for PostgreSQL en Azure Well-Architected Framework.

Introducción a la arquitectura de confiabilidad

En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.

Arquitectura lógica

Al trabajar con Azure Database for PostgreSQL, se implementa un servidor, que representa los recursos de proceso y almacenamiento necesarios para admitir el servidor de bases de datos. Puede implementar una o varias bases de datos en el servidor.

Los servidores se pueden implementar en varios niveles de proceso: ampliable, de uso general y optimizado para memoria, cada uno de los cuales está optimizado para diferentes tipos de cargas de trabajo. En algunas regiones de Azure, puede implementar servidores con Azure Confidential Computing.

Para más información sobre la arquitectura de servicio general y los modelos de implementación, consulte ¿Qué es Azure Database for PostgreSQL?.

Arquitectura física

• Separación de proceso y almacenamiento: Azure Database for PostgreSQL usa una arquitectura de separación de proceso y almacenamiento para admitir la alta disponibilidad. El motor de base de datos se ejecuta en una máquina virtual Linux, mientras que los archivos de datos se almacenan en Azure Storage, que mantiene tres copias sincrónicas con redundancia local de los archivos de base de datos para garantizar la durabilidad de los datos.

• Alta disponibilidad: Opcionalmente, puede habilitar una configuración de alta disponibilidad en el servidor. Al habilitar la configuración de alta disponibilidad, el servicio aprovisiona y mantiene un servidor en espera activo. Los cambios de datos en el servidor principal se replican sincrónicamente en el servidor en espera para garantizar una pérdida de datos cero durante un error del servidor principal.

  La arquitectura separa la capa de proceso de la capa de almacenamiento, lo que permite al servicio controlar los distintos tipos de errores de forma adecuada. Para lograr una mayor resistencia, puede distribuir los servidores entre zonas de disponibilidad.

  

  Un servidor en espera se implementa en la misma configuración de máquina virtual que el servidor principal, incluidos los núcleos virtuales, el almacenamiento y la configuración de red.

  Puede cambiar entre servidores mediante la realización de una conmutación por error. Hay dos tipos de conmutación por error: conmutaciones por error forzadas, que se usan cuando se produce un error en el servidor principal y conmutaciones por error planeadas, que se usan durante algunas operaciones de mantenimiento y en otros escenarios en los que es necesario minimizar el tiempo de inactividad de la aplicación durante una conmutación por error.

  Las operaciones como detener, iniciar y reiniciar se realizan en los servidores de base de datos principal y en espera al mismo tiempo. Los eventos planeados, como la computación de escalado y el almacenamiento de escalado se producen primero en espera y, a continuación, en el servidor principal. Actualmente, el servidor no conmuta por error para estas operaciones planeadas.

  Para más información, consulte Alta disponibilidad en Azure Database for PostgreSQL.

• Copias de seguridad: Azure Database for PostgreSQL crea automáticamente copias de seguridad del servidor. Para obtener más información, consulte Copia de seguridad y restauración.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Las aplicaciones deben controlar los errores de conectividad transitorios que pueden producirse durante el mantenimiento, las operaciones de escalado o las interrupciones de red. Siga estas recomendaciones:

• Cuando la aplicación encuentre errores transitorios, vuelva a intentar la operación mediante retroceso exponencial. Aumente el retraso entre reintentos y limite el número de intentos. Si la operación sigue produciendo un error después de los reintentos máximos, considérela un fracaso.
• Siempre que sea posible, use bibliotecas cliente (también denominadas controladores) que controlen automáticamente los reintentos.
• Los errores transitorios que se producen durante las operaciones de escritura requieren una consideración más cuidadosa. Considere la posibilidad de hacer que las operaciones de escritura sean idempotentes, por lo que se pueden ejecutar de forma segura varias veces.

Para más información, consulte Control de errores de conectividad transitorios en Azure Database for PostgreSQL.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Puede seleccionar su tipo de soporte de zona de disponibilidad a través de la configuración de alta disponibilidad. Al habilitar la alta disponibilidad, se implementa un servidor en espera junto con el servidor principal. Este modelo de alta disponibilidad ayuda a garantizar que los datos confirmados nunca se pierdan durante los errores. Independientemente del modelo de implementación de alta disponibilidad que utilice su servidor, los datos se confirman sincrónicamente tanto en el servidor principal como en el servidor en espera. Si se produce una interrupción en el servidor principal, se conmuta automáticamente al servidor de respaldo.

Los archivos de datos y los registros de escritura anticipada (WAL) se almacenan en discos administrados premium dentro de cada zona de disponibilidad, con almacenamiento con redundancia local (LRS) que almacena automáticamente tres copias de datos dentro de cada zona.

Azure Database for PostgreSQL admite dos tipos de configuración de zona de disponibilidad cuando se usa alta disponibilidad:

• Alta disponibilidad con redundancia de zona: La redundancia de zona proporciona el nivel más alto de resistencia de zona mediante la implementación de un servidor principal en una zona de disponibilidad y un servidor en espera en una zona de disponibilidad diferente. El servidor en espera usa una configuración de red, almacenamiento y proceso similar a la principal. Una configuración con redundancia de zona proporciona aislamiento físico de toda la pila entre los servidores principal y en espera.

  Puede seleccionar las zonas de disponibilidad para los servidores principales y en espera o permitir que Microsoft los elija.

  Se recomiendan implementaciones con redundancia de zona para servidores de producción.

  

  Las operaciones de escritura pueden experimentar un pequeño aumento de la latencia de confirmación porque el servicio replica de forma sincrónica los datos en el servidor en espera. El impacto varía según la carga de trabajo, la SKU seleccionada y la región.

• Alta disponibilidad zonal (misma zona): Los servidores principales y en espera usan la misma zona de disponibilidad. Si se produce una interrupción en el servidor principal, pero la zona sigue operativa, el servidor conmuta automáticamente al servidor en espera. Una implementación zonal proporciona alta disponibilidad dentro de una sola zona de disponibilidad. Protege contra 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. Sin embargo, no protege contra una interrupción en esa zona.

  

  La alta disponibilidad zonal (misma zona) solo está disponible en las situaciones siguientes:

  • La región no admite zonas de disponibilidad. La región funciona eficazmente como una sola zona, por lo que la única configuración de alta disponibilidad que puede seleccionar es la misma zona.
  • Si una región no tiene capacidad suficiente para una implementación con redundancia de zona, el servicio puede colocar inicialmente ambos servidores en la misma zona de disponibilidad y migrarlos automáticamente a zonas independientes cuando la capacidad esté disponible. Esta opción está disponible cuando se usa Azure Portal o la CLI de Azure para implementar un servidor. Para obtener más información, consulte Configuración de opciones críticas para la empresa (alta disponibilidad).

  Dado que los servidores están en la misma zona, puede reducir la latencia de escritura a las aplicaciones que implemente dentro de la misma zona.

Si configura el servidor sin alta disponibilidad, se ejecuta en un solo servidor. Si ese servidor o su zona deja de funcionar, el servidor no está disponible. Para obtener más información, consulte Configuraciones sin zonas de disponibilidad.

Requisitos

• Compatibilidad con regiones: La compatibilidad de Azure Database for PostgreSQL con configuraciones de zona de disponibilidad difiere entre las regiones de Azure. Para obtener una lista completa de las regiones y los tipos de compatibilidad de zona de disponibilidad y las consideraciones específicas de esa región, consulte Regiones de Azure.

• Nivel de proceso: En la tabla siguiente se muestra la compatibilidad con el nivel de proceso para cada tipo de compatibilidad con zonas de disponibilidad:

  Nivel de precios	Zone-redundant	Zonal (misma zona)
  Ampliable	No soportado	Soportado
  General Purpose	Soportado	Soportado
  Memoria optimizada	Soportado	Soportado

• Nivel de servicio: La redundancia de zona requiere niveles de uso general o optimizados para memoria.

  Las implementaciones zonales (misma zona) se admiten en todos los planes de tarifa.

Consideraciones

Capacidad de región: Si una región no tiene capacidad suficiente para una implementación con redundancia de zona, el servicio puede colocar inicialmente ambos servidores en la misma zona de disponibilidad y migrarlos automáticamente a zonas independientes cuando la capacidad esté disponible. Esta opción está disponible cuando se usa Azure Portal o la CLI de Azure para implementar un servidor. Para obtener más información, consulte Configuración de opciones críticas para la empresa (alta disponibilidad).

Costo

Al habilitar la alta disponibilidad, se crea el servidor en espera y se factura a la misma velocidad que la principal. La configuración de la zona de disponibilidad no afecta al costo. No hay cargos por la replicación de datos dentro o entre zonas de disponibilidad. Dependiendo del volumen de almacenamiento de copia de seguridad, también se le puede facturar por el almacenamiento de copia de seguridad. Para obtener información detallada sobre los precios, consulte Precios de Azure Database for PostgreSQL.

Configurar soporte de zonas de disponibilidad

Para configurar la compatibilidad con zonas de disponibilidad para un servidor, configure las opciones de alta disponibilidad.

• Cree un servidor con redundancia de zona: Para aprender a crear un servidor con alta disponibilidad y redundancia de zona habilitada, consulte Inicio rápido: Creación de una instancia de Azure Database for PostgreSQL en Azure Portal.

• Cambie la configuración de zona de disponibilidad para los servidores existentes: Puede cambiar la configuración de zona de disponibilidad para los servidores existentes cambiando la configuración de alta disponibilidad. Para ver los pasos detallados, consulte Habilitación de la alta disponibilidad para los servidores existentes.

  No se puede cambiar la zona usada para el servidor principal o en espera después de que se hayan creado. Debes recrear el servidor.

  Sugerencia

  Es recomendable esperar hasta que la actividad del servidor sea baja antes de cambiar la configuración de alta disponibilidad.

• Deshabilitar alta disponibilidad: Al deshabilitar la alta disponibilidad, se quita el servidor en espera, por lo que el servidor no es resistente a interrupciones en su zona de disponibilidad. Para obtener más información, consulte Deshabilitación de la alta disponibilidad.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando los servidores están configurados con compatibilidad con zonas de alta disponibilidad y disponibilidad y todas las zonas de disponibilidad están operativas.

• Operación entre zonas: Las aplicaciones cliente de PostgreSQL se conectan al servidor principal mediante el nombre del servidor de base de datos. Azure Database for PostgreSQL usa una configuración activa/pasiva en la que el servidor principal controla todas las conexiones y consultas de base de datos en la zona de disponibilidad principal. El servidor en espera no atiende el tráfico de cliente durante las operaciones normales.

• Replicación de datos entre zonas: Los cambios en los datos se replican sincrónicamente entre los servidores principal y en espera. Las transacciones no se consideran completas hasta que los servidores principal y en espera confirmen la escritura.

  La escritura desencadenada por transacciones de la aplicación y confirma el primer registro en el WAL en el 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 proceso de confirmación no espera a que los registros se apliquen al servidor en espera.

  Los efectos de la replicación son diferentes en función de la configuración de zona de disponibilidad que use el servidor:

  • Con redundancia de zona: Dado que los servidores están en zonas independientes, este enfoque garantiza una pérdida de datos cero durante un error de zona. Esta situación también se denomina a veces lograr un objetivo de punto de recuperación (RPO) de cero para los errores de zona.

    Sin embargo, la replicación entre zonas podría introducir una pequeña cantidad de latencia adicional. El impacto de la latencia depende de la aplicación y, para la mayoría de las aplicaciones, es insignificante.

  • Zonal: dado que ambos servidores están en la misma zona, no se replica ningún tráfico entre zonas.

  Nota:

  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 el servidor en espera. Por lo tanto, no puede usar el modo de espera para recuperarse de estos tipos de errores y debe realizar una restauración a un momento dado desde la copia de seguridad. Para obtener más información, consulte Copia de seguridad y restauración.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando los servidores están configurados para alta disponibilidad y compatibilidad con zonas de disponibilidad y hay una interrupción en una zona de disponibilidad.

• Detección y respuesta: Azure 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.

  En caso de error de zona, el comportamiento es diferente en función de la configuración de zona de disponibilidad que use el servidor:

  • Con redundancia de zona: Azure Database for PostgreSQL detecta automáticamente fallos en la zona de disponibilidad. Para ver los posibles tipos de estado de alta disponibilidad, consulte Tipos de estado de alta disponibilidad. Cuando se produce un error en una zona, Azure inicia una conmutación por error forzada al servidor en espera sin que sea necesario realizar ninguna acción.

  • Zonal: Si la zona de disponibilidad que hospeda un servidor zonal deja de estar disponible, los servidores principal y en espera no están disponibles. En este escenario, el servicio no proporciona conmutación automática por error. Es responsable de detectar la interrupción de zona y realizar acciones de recuperación, como restaurar copias de seguridad con redundancia de zona en un servidor independiente en otra zona de disponibilidad o región.

• Notificación: 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. La característica de supervisión se basa en Azure Resource Health y puede 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. Evalúe las métricas clave, como el estado de conexión, el estado de conmutación por error y el estado de replicación de datos, para habilitar la solución de problemas proactiva y ayudar a mantener el tiempo de actividad y el rendimiento 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.

• Solicitudes activas: Cuando una zona de disponibilidad deja de estar disponible, es posible que se finalicen las solicitudes en curso a los servidores de la zona afectada. Las aplicaciones deben reintentar estas solicitudes. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

• Pérdida de datos esperada: La cantidad de pérdida de datos depende de la configuración de zona de disponibilidad que usa el servidor.

  • Redundante por zona: Se anticipa una pérdida de datos cero durante el fallo de zona debido a la replicación sincrónica entre los servidores principal y en espera en distintas zonas.

  • Zonal: Los datos de los servidores de la zona afectada no están disponibles hasta que se recupere la zona.

• Tiempo de inactividad esperado: La cantidad de tiempo de inactividad depende de la configuración de zona de disponibilidad que usa el servidor.

  • Con redundancia de zona: La conmutación por error se completa normalmente en un plazo de 60 a 120 segundos. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

  • Zonal: Los servidores de una zona afectada no están disponibles hasta que se recupere la zona de disponibilidad.

• Redistribución: El comportamiento de reenrutamiento del tráfico depende de la configuración de zona de disponibilidad que usa el servidor.

  • Con redundancia de zona: Después de la conmutación por error, el servidor en espera anterior se convierte en el nuevo servidor principal y comienza a aceptar nuevas conexiones. Azure establece automáticamente un nuevo servidor en espera en la zona principal original después de recuperarse. Para más información, consulte Conmutación por error forzada.

  • Zonal: Cuando una zona no está disponible, el servidor no está disponible. Si tiene un servidor independiente que ha creado previamente en otra zona de disponibilidad o región, es responsable de redirigir el tráfico a ese servidor.

Recuperación de zona

El comportamiento de recuperación de zona depende de la configuración de zona de disponibilidad que usa el servidor.

• Con redundancia de zona: Cuando se recupera la zona de disponibilidad, Azure Database for PostgreSQL vuelve a generar automáticamente el servidor de reserva en la zona recuperada y lo sincroniza con el servidor principal actual. A continuación, la zona recuperada actúa como ubicación en espera. El servicio no mueve automáticamente el rol principal a la zona original para evitar interrupciones innecesarias. Puede iniciar manualmente una conmutación por error planeada si desea devolver la principal a la zona original.

• Zonal: Una vez que la zona está en buen estado, los servidores de la zona están disponibles de nuevo. Es responsable de cualquier procedimiento de recuperación de zona y sincronización de datos que requieran las cargas de trabajo.

Prueba de fallos de zona

Las opciones para probar errores de zona dependen de la configuración de zona de disponibilidad que usa la instancia.

• Con redundancia de zona: Puede probar la resistencia de la aplicación para la conmutación por error iniciando una conmutación por error forzada. Una conmutación por error forzada le permite simular un evento no planificado durante la ejecución de su carga de trabajo, permitiéndole observar el tiempo de inactividad de su aplicación. Se recomienda ejecutar simulaciones en un entorno que no sea de producción o en un momento silencioso. Para obtener más información, consulte Iniciar una conmutación por error forzada.

• Zonal: Aunque no se puede simular una interrupción de zona completa, puede simular que el servidor no está disponible de forma similar a lo que sucede durante una interrupción de zona. Para obtener más información, vea Detener el proceso de un servidor.

Resistencia a errores en toda la región

Azure Database for PostgreSQL admite réplicas de lectura entre regiones, que puede usar para mantener una copia sincronizada de la base de datos en otra región para una recuperación más rápida.

También puede usar copias de seguridad con redundancia geográfica, en regiones admitidas, para proporcionar recuperación entre regiones. Sin embargo, las copias de seguridad suelen implicar más tiempo de inactividad y pérdida de datos que la replicación. Para obtener más información, consulte Copia de seguridad y restauración.

Réplicas de lectura entre regiones

Puede implementar réplicas de lectura para proteger las bases de datos frente a errores de nivel de región. Cada réplica de lectura es un servidor independiente de Azure Database for PostgreSQL. Cuando coloca una réplica de lectura en una segunda región de Azure, el servidor de bases de datos puede proporcionar resiliencia ante un problema que afecte a toda la región. Puede implementar hasta cinco réplicas de lectura, las cuales opcionalmente pueden estar en distintas regiones de Azure. La tecnología de replicación física de PostgreSQL actualiza las réplicas de lectura de forma asincrónica y pueden retardar la principal. Las réplicas de lectura entre regiones pueden servir opcionalmente cargas de trabajo de solo lectura para reducir la latencia de las aplicaciones distribuidas globalmente o descargar el tráfico de lectura desde el servidor principal. Para obtener más información sobre las características y consideraciones de réplica de lectura, consulte Réplicas de lectura.

Los puntos de conexión virtuales proporcionan puntos de conexión de lectura-escritura y de solo lectura, y redirigen automáticamente el tráfico cuando se promueve una réplica, lo que ayuda a minimizar el tiempo de inactividad durante las conmutaciones por error. Se recomienda encarecidamente usar puntos de conexión virtuales con réplicas de lectura entre regiones para mejorar la resistencia de la aplicación. Para más información, consulte Puntos de conexión virtuales para réplicas de lectura en Azure Database for PostgreSQL.

Si se produce un error en la región primaria, puede desencadenar una promoción para que la réplica secundaria se convierta en la principal. Hay diferentes tipos de conmutación por error que puedes activar dependiendo de cómo uses las réplicas de lectura. Cuando se usan réplicas de lectura para proporcionar resistencia a errores de región, normalmente se usa el enfoque de promoción al servidor principal , que actualiza el punto de conexión virtual. Durante una interrupción de la región, debe realizar una promoción forzada, lo que puede dar lugar a una pérdida de datos para los datos no replicados. En escenarios planificados en los que la región primaria está en buen estado, puede optar por realizar una promoción planificada para evitar la pérdida de datos. Para más información, consulte Promoción de réplicas de lectura en Azure Database for PostgreSQL.

Nota:

En esta sección se resume alguna de la información importante sobre cómo las réplicas de lectura pueden admitir resiliencia ante fallos a nivel regional. También puede usar réplicas de lectura para mejorar el rendimiento y admitir bases de usuarios distribuidas geográficamente a gran escala. Para obtener más información, consulte Réplicas de lectura.

Requisitos

• Compatibilidad con regiones: Puede crear réplicas de lectura entre regiones en cualquier región que admita Azure Database for PostgreSQL. No estás limitado a las regiones emparejadas de Azure.

• Niveles de cómputo: Los niveles de cómputo de uso general y optimizados para memoria admiten réplicas de lectura. El nivel Ampliable no admite réplicas de lectura.

Consideraciones

• Diferencias de configuración: Es posible que las réplicas de lectura no hereden todas las opciones de configuración del servidor principal. Planifique configurar los ajustes necesarios después de la conmutación por error. El servidor principal y las réplicas deben ser simétricos, lo que significa que deben tener los mismos niveles, tamaños de almacenamiento y valores para algunas configuraciones. Durante fallos en la región, se puede renunciar al requisito de tener un servidor simétrico para promociones forzadas, pero se recomienda mantener una configuración simétrica siempre que sea posible para evitar problemas inesperados. Para obtener más información, consulte Administración de configuración.

• Supervisión del retraso de replicación: El proceso de replicación asincrónica requiere un retraso de replicación, que puede variar dependiendo de varios factores. Cuando el retraso de replicación es muy alto, es posible que el servidor experimente problemas. Es importante supervisar el retraso de replicación para que pueda mitigar los problemas antes de que se escalen. Para más información, consulte Supervisión de la replicación.

• Alta disponibilidad: Las réplicas de lectura no pueden tener alta disponibilidad habilitada y, cuando se promueven, tampoco tienen alta disponibilidad. Eres responsable de configurar la alta disponibilidad después de promover una réplica.

Para obtener más consideraciones que se aplican al proceso de promoción, consulte Promoción de réplicas de lectura en Azure Database for PostgreSQL: consideraciones.

Costo

Las réplicas de lectura incurren en costos de proceso y almacenamiento, así como cargos por transferencia de datos entre regiones para la replicación. Para obtener información detallada sobre los precios, consulte Precios de Azure Database for PostgreSQL y Precios de ancho de banda.

Configuración de la compatibilidad con varias regiones

• Cree una réplica de lectura: Para obtener información sobre cómo crear una réplica de lectura, consulte Creación de una réplica de lectura. Las réplicas se pueden configurar después de crear el servidor principal, siempre que el servidor principal se ejecute y sea accesible.

  Para crear un punto de conexión virtual, consulte Creación de puntos de conexión virtuales.

• Eliminar una réplica de lectura: Para obtener información sobre cómo eliminar una réplica de lectura, consulte Eliminación de una réplica de lectura.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando el servidor está configurado con una réplica de lectura en otra región y un punto de conexión virtual, y todas las regiones están operativas:

• Enrutamiento del tráfico entre regiones: En las operaciones normales, el punto de conexión virtual dirige el tráfico del punto de conexión de lectura y escritura al servidor principal de la región primaria. Si también usa el punto de conexión de solo lectura del punto de conexión virtual, dirige el tráfico a la réplica que configure.

• Replicación de datos entre regiones: Las réplicas de lectura entre regiones usan la replicación asincrónica para minimizar el impacto en el rendimiento del servidor principal. La cantidad de retraso de replicación depende de varios factores, incluida la carga de escritura y la latencia entre el servidor principal y las réplicas. El retraso de replicación suele ser al menos varios minutos, pero puede ser mucho más largo. Para más información, consulte Supervisión de la replicación.

Comportamiento durante una falla de región

En esta sección se describe qué esperar cuando el servidor está configurado con una réplica de lectura en otra región y un punto de conexión virtual, y hay una interrupción en la región primaria:

• Detección y respuesta: Usted es responsable de detectar una interrupción en la región primaria y promover manualmente una réplica de lectura como el nuevo servidor principal. Durante una interrupción regional, debe realizar una promoción forzada, lo que resulta en la pérdida de cualquier dato no replicado.

  Importante

  Usted es responsable de activar la promoción. Azure no promueve las réplicas de lectura automáticamente, incluso si se produce una falla en una región.

  Para obtener pasos detallados para comenzar una promoción, consulte Convertir réplica de lectura en principal.

• Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: Se eliminan todas las conexiones activas a la región primaria. Las aplicaciones deben reintentar la realización de conexiones a la réplica promocionada una vez completado el proceso de promoción.

• Pérdida de datos esperada: Durante una interrupción de la región, debe realizar una promoción obligatoria, lo que da lugar a la pérdida permanente de los datos no replicados.

  La cantidad de pérdida de datos depende del retraso de replicación en el momento de la interrupción. El retraso de replicación suele ser al menos varios minutos, pero puede ser mucho más largo. Para más información, consulte Supervisión de la replicación.

• Tiempo de inactividad esperado: La promoción forzada se completa normalmente en un plazo de 1 a 3 minutos después de desencadenarse. Es posible que las aplicaciones también necesiten volver a conectarse al punto de conexión correcto. Los puntos de conexión virtuales se actualizan como parte del proceso de promoción forzada. Las aplicaciones deben respetar el período de vida (TTL) de los registros DNS del punto de conexión para asegurarse de que se vuelven a conectar rápidamente a la réplica correcta una vez completada la promoción.

• Reenrutamiento del tráfico: El punto de conexión virtual del servidor redirige automáticamente el tráfico de la aplicación a la nueva réplica principal.

  Nota:

  Después de que una réplica de lectura es promovida a servidor principal, no tiene activada la configuración de Alta Disponibilidad. Debe habilitar la configuración de alta disponibilidad manualmente o agregarla a sus propios procesos de automatización.

Recuperación de regiones

Cuando se usan puntos de conexión virtuales, una vez recuperada la región primaria, el servidor principal antiguo se configura automáticamente como una réplica de lectura. Puede realizar otra promoción para devolver las operaciones principales a la región primaria preferida.

Prueba de fallos de región

Pruebe periódicamente los procedimientos de promoción de réplica de lectura para asegurarse de que los procesos son válidos y que las funcionalidades cumplen los requisitos de RTO y RPO.

Puede promover una réplica de lectura para convertirse en el servidor principal en cualquier momento, incluso cuando todas las regiones estén en buen estado. Para las pruebas:

• Puede realizar pruebas de promoción forzadas. Se recomienda realizar estas pruebas en un entorno que no sea de producción, ya que puede provocar la pérdida de datos. Las pruebas de promoción forzadas ayudan a simular el comportamiento que se observa durante una interrupción de una región.
• Para el mantenimiento planeado o los escenarios de prueba en los que desea evitar la pérdida de datos, use una promoción planeada en su lugar. Tenga en cuenta que la promoción planeada sigue un proceso diferente al de la promoción durante una interrupción de la región.

Para obtener instrucciones paso a paso, consulte Conmutar réplica de lectura a principal.

Como parte de la estrategia de recuperación ante desastres, ejecute periódicamente los simulacros de recuperación completa. Estos simulacros deben incluir la validación de datos, las pruebas de funcionalidad de la aplicación y los procedimientos de reversión documentados.

Copias de seguridad y restauración

Azure Database for PostgreSQL realiza automáticamente copias de seguridad que proporcionan funcionalidades de recuperación a un momento dado y le ayudan a protegerse frente a daños accidentales y la eliminación de datos. Microsoft administra completamente las copias de seguridad, no interrumpe la disponibilidad del servidor e incluye copias de seguridad completas y copias de seguridad del registro de transacciones.

• Almacenamiento de copia de seguridad: Si el servidor está configurado con alta disponibilidad con redundancia de zona, las copias de seguridad se almacenan en el almacenamiento con redundancia de zona (ZRS). En el caso de los servidores configurados sin alta disponibilidad o con alta disponibilidad zonal (zona única), las copias de seguridad se almacenan en almacenamiento con redundancia local (LRS).

  En regiones de Azure con pares, puede configurar el almacenamiento de copia de seguridad con redundancia geográfica (GRS) en el momento de la creación del servidor para replicar copias de seguridad en la región emparejada de Azure para una protección adicional frente a errores de región. Las copias de seguridad se replican de forma asincrónica.

  El período de retención de copia de seguridad predeterminado es de 7 días, con la opción de ampliar la retención hasta 35 días. También puede usar Azure Backup para el almacenamiento a largo plazo de copias de seguridad manuales durante hasta 10 años. Todas las copias de seguridad están cifradas.

• Restaurar: La recuperación a un momento dado le permite restaurar la base de datos a cualquier momento dentro del período de retención de copia de seguridad. El proceso de restauración crea un nuevo servidor de bases de datos con un nuevo nombre de servidor proporcionado por el usuario, desde el que puede usar as-is o copiar datos.

  Al restaurar una copia de seguridad con redundancia geográfica, se crea un nuevo servidor en la región emparejada.

  Esta funcionalidad es útil para recuperarse de modificaciones accidentales de datos, errores de aplicación o escenarios de prueba.

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.

Para más información, consulte Copia de seguridad y restauración en Azure Database for PostgreSQL.

Resistencia al mantenimiento del servicio

Azure Database for PostgreSQL controla automáticamente las tareas de mantenimiento críticas, incluida la aplicación de revisiones del hardware subyacente, el sistema operativo y el motor de base de datos. El servicio incluye actualizaciones de seguridad, actualizaciones de software y actualizaciones de versiones secundarias como parte del mantenimiento planeado.

Para asegurarse de que el servidor permanece disponible durante las ventanas de mantenimiento, siga estas recomendaciones:

• Habilitar alta disponibilidad: Durante el mantenimiento, es posible que el servidor deba reiniciarse como parte del proceso de actualización. Si tiene alta disponibilidad habilitada, las operaciones de mantenimiento suelen usar actualizaciones graduales para minimizar el tiempo de inactividad. Las actividades de mantenimiento periódicas, como las actualizaciones de versiones secundarias, se producen primero en la réplica en espera. 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. Esta secuenciación se aplica tanto si el servidor utiliza alta disponibilidad con redundancia de zona como si utiliza alta disponibilidad zonal.

  En el caso de los servidores sin alta disponibilidad habilitada, espere un breve tiempo de inactividad durante las operaciones de mantenimiento. Con alta disponibilidad habilitada, las operaciones de mantenimiento normalmente se completan con un tiempo de inactividad mínimo o sin tiempo de inactividad.

• Configurar ventanas de mantenimiento personalizadas: Puede configurar la programación de mantenimiento para que se administre por el sistema o definir una ventana de mantenimiento personalizada para minimizar el impacto en las operaciones empresariales. Programe el mantenimiento durante períodos de baja actividad para minimizar el impacto empresarial. Para obtener más información, consulte Programación del mantenimiento.

• Implemente la lógica de reintento: Asegúrese de que las aplicaciones pueden controlar breves interrupciones de conectividad que pueden producirse durante los reinicios de mantenimiento. Para que las aplicaciones sean resistentes a estos tipos de problemas, consulte Guía sobre resistencia a errores transitorios .

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Azure Database for PostgreSQL proporciona acuerdos de nivel de servicio de disponibilidad diferentes en función de la configuración del servidor:

• Servidores configurados con redundancia de zona para alta disponibilidad.
• Servidores configurados con alta disponibilidad zonal (zona única).
• Servidores configurados sin alta disponibilidad.

Contenido relacionado

• confiabilidad Azure
• Procedimientos recomendados de arquitectura para Azure Database for PostgreSQL
• Introducción a la continuidad empresarial con Azure Database for PostgreSQL
• Recuperación ante desastres geográfica en Azure Database for PostgreSQL
• Acelerador de soluciones de resiliencia de Azure Database for PostgreSQL: scripts de Terraform para implementar muchos de los principios de resiliencia y capacidad de recuperación descritos en este artículo.