Configurar la alta disponibilidad para Azure Database for PostgreSQL: servidor flexible

En este artículo se describe cómo habilitar o deshabilitar la alta disponibilidad (HA) en el servidor flexible Azure Database for PostgreSQL. La información se aplica tanto si usa servidores en la misma zona como si usa un modelo de implementación con redundancia de zona.

La característica de alta disponibilidad implementa réplicas principales y en espera separadas físicamente. Es posible aprovisionar las réplicas dentro de la misma zona de disponibilidad o en zonas diferentes, en función del modelo de implementación elegido. Para más información, consulte el artículo sobre los conceptos de alta disponibilidad. Puede habilitar la alta disponibilidad durante o después de la creación del servidor flexible de Azure Database for PostgreSQL.

Habilitar alta disponibilidad para servidores existentes

Puede habilitar la alta disponibilidad en un servidor flexible Azure Database for PostgreSQL existente en cualquier momento. Al habilitar la alta disponibilidad, el servicio crea una réplica en espera que refleje el servidor principal. Según la capacidad regional y las opciones de configuración, el modo de espera se puede implementar en una zona de disponibilidad diferente para la máxima protección o en la misma zona que la principal.

Usa el portal de Azure:

  1. Seleccione su servidor flexible de Azure Database for PostgreSQL. Mediante Azure Portal:

  2. Seleccione su servidor flexible de Azure Database for PostgreSQL.

  3. En el menú de recursos, en la sección Configuración , seleccione Alta disponibilidad.

La opción Resistencia zonal controla si el servidor está protegido entre zonas de disponibilidad. Tiene dos opciones:

  • Deshabilitado (99.9% SLA): la alta disponibilidad no está configurada.
  • Habilitado (99.99% Acuerdo de Nivel de Servicio): al seleccionar esta opción, Azure intenta crear el servidor en espera en una zona de disponibilidad diferente a la principal. Esta opción ofrece la mejor protección frente a errores de nivel de zona.

Si habilita la resistencia zonal pero la región carece de capacidad para una configuración con redundancia de zona, aparece una casilla adicional en la opción Habilitado (99.99% SLA). Active esta casilla para permitir que el servidor en espera se cree en la misma zona que el servidor principal. Cuando haya capacidad zonal disponible, Azure migrará automáticamente sus cargas de trabajo de la misma zona a una zona redundante.

  1. Si no habilitó la resistencia zonal, seleccione la opción Habilitado .

    Captura de pantalla que muestra la página Alta disponibilidad para configurar la alta disponibilidad.

  2. Al seleccionar la opción Habilitado , la opción Con redundancia de zona se aplica de forma predeterminada para las regiones que admiten zonas de disponibilidad. Esta configuración protege contra errores zonales.

    Captura de pantalla que muestra el botón de radio seleccionado para habilitar la alta disponibilidad.

  3. Si la región no tiene capacidad zonal, para asegurarse de que la alta disponibilidad (HA) esté habilitada en su región preferida, active la casilla de la opción habilitada para permitir la creación de alta disponibilidad con el modo Same-Zone de la región:

    Captura de pantalla que muestra la selección de la misma opción de zona para alta disponibilidad.

  4. Cuando haya terminado de configurar las opciones, seleccione Guardar para aplicar los cambios.

  5. Un cuadro de diálogo muestra del aumento del coste asociado a la implementación del servidor en espera. Si decide continuar, seleccione Habilitar alta disponibilidad.

    Captura de pantalla que muestra el cuadro de diálogo para confirmar la habilitación de alta disponibilidad.

  6. Se inicia una nueva implementación para habilitar la alta disponibilidad en el servidor flexible Azure Database for PostgreSQL.

    Captura de pantalla que muestra la implementación en curso de una configuración de alta disponibilidad.

  7. Cuando se complete la implementación, puede seleccionar Ir al recurso para volver al servidor flexible de Azure Database for PostgreSQL.

    Captura de pantalla que muestra la implementación completada correctamente para habilitar una configuración de alta disponibilidad.

Deshabilitación de la alta disponibilidad

Puede deshabilitar la alta disponibilidad en el servidor flexible Azure Database for PostgreSQL cuando ya no necesite la protección de una réplica en espera. Al deshabilitar la alta disponibilidad, se quita el servidor en espera y se reducen los costos, pero el servidor ya no está protegido frente a errores de zona o servidor.

Usa el portal de Azure:

  1. Seleccione su servidor flexible de Azure Database for PostgreSQL.

  2. En el menú de recursos, en la sección Configuración , seleccione Alta disponibilidad.

  3. Si la alta disponibilidad está habilitada, el botón de radio Habilitado para resistencia zonal ya está seleccionado. Además, el modo Alta disponibilidad se establece en el modo configurado y el valor de Estado de alta disponibilidad suele ser Correcto.

    Captura de pantalla que muestra el panel para configurar la alta disponibilidad, con opciones de alta disponibilidad ya seleccionadas y un estado de Correcto.

  4. Seleccione el botón de radio Deshabilitado para deshabilitar la alta disponibilidad.

    Captura de pantalla que muestra la casilla para habilitar la alta disponibilidad desactivada.

  5. Seleccione Guardar para aplicar los cambios.

  6. Un cuadro de diálogo muestra la reducción del coste asociada a la eliminación del servidor en espera. Si decide continuar, seleccione Deshabilitar alta disponibilidad.

    Captura de pantalla que muestra el cuadro de diálogo para confirmar la desactivación de la alta disponibilidad.

  7. Se inicia una implementación. Al finalizar, una notificación muestra que se deshabilitó correctamente la alta disponibilidad.

    Captura de pantalla que muestra una notificación sobre la deshabilitación correcta de la alta disponibilidad.

Habilitar Crítico para el Negocio (Alta Disponibilidad) durante el aprovisionamiento del servidor

Puede configurar la alta disponibilidad cuando cree por primera vez el servidor flexible Azure Database for PostgreSQL. Al habilitar la alta disponibilidad durante el aprovisionamiento, se implementa una réplica en espera junto con el servidor principal, por lo que se obtiene protección inmediata frente a errores de zona o servidor.

Usa el portal de Azure:

  1. Durante el aprovisionamiento de un nuevo servidor flexible de Azure Database for PostgreSQL, ve a la sección Crítico para el negocio (alta disponibilidad). Seleccione la opción Habilitado en la sección Resistencia zonal .

    • De forma predeterminada, el servidor intenta crear un servidor en espera en una zona de disponibilidad diferente con modo de alta disponibilidad con redundancia de zona para lograr la máxima resistencia zonal.

    Captura de pantalla que muestra cómo habilitar la alta disponibilidad con la opción de redundancia por zona.

    • Si la capacidad zonal no está disponible, active la casilla Permitir espera en la misma zona si se produce un error en la resistencia zonal como reserva. Si no selecciona esta opción, no puede continuar con el paso siguiente en el flujo de trabajo de creación. Esta comprobación garantiza que la alta disponibilidad permanezca habilitada. Cuando la capacidad zonal está disponible, Azure migra automáticamente las cargas de trabajo de Same-Zone HA a Zone-redundant HA.

      Captura de pantalla que muestra el mensaje de error de validación para la opción de alta disponibilidad en la misma zona.

    • Después de activar la casilla, vaya a la sección Autenticación del flujo de trabajo de creación.

      Captura de pantalla que muestra la alta disponibilidad con la opción de alta disponibilidad en la misma zona.

  2. Seleccione una zona específica para el servidor principal estableciendo zona de disponibilidad en cualquier valor distinto de Sin preferencias.

    Captura de pantalla que muestra la selección de zonas de disponibilidad específicas para el servidor principal.

Iniciar una conmutación por error forzada

Siga estos pasos para forzar una conmutación por error del servidor principal al servidor en espera en Azure Database for PostgreSQL.

Cuando se inicia una conmutación por error forzada, el servidor principal deja de funcionar inmediatamente y desencadena una conmutación por error al servidor en espera. Iniciar una conmutación por error forzada resulta útil cuando se desea comprobar cómo afecta a la carga de trabajo una conmutación por error provocada por una interrupción no planificada.

Importante

  • No realice conmutaciones por error inmediatas consecutivas. Espere al menos de 15 a 20 minutos entre conmutaciones por error. Este tiempo de espera permite establecer completamente el nuevo servidor en espera.

  • El tiempo general de la operación de un extremo a otro, tal y como se indica en el portal, podría ser mayor que el tiempo de inactividad real que experimente la aplicación. Mida el tiempo de inactividad desde la perspectiva de la aplicación.

Usa el portal de Azure:

  1. Seleccione el Azure Database for PostgreSQL servidor flexible que tenga habilitada la alta disponibilidad.

  2. En el menú de recursos, en la sección Configuración , seleccione Alta disponibilidad.

  3. Si los servidores principales y en espera se implementan en distintas zonas, tenga en cuenta los valores asignados a la zona de disponibilidad principal y a la zona de disponibilidad en espera. Estos valores se invierten después de que finalice la operación de conmutación por error.

    Captura de pantalla que muestra las zonas de disponibilidad de principal y en espera.

  4. Seleccione Conmutación por error forzada para iniciar el procedimiento de conmutación por error manual. Un cuadro de diálogo le informa del tiempo de inactividad esperado hasta que finalice la conmutación por error. Si decide continuar, seleccione Iniciar conmutación por error forzada.

    Captura de pantalla que muestra el cuadro de diálogo que se muestra antes del inicio de una conmutación por error forzada.

  5. Aparece una notificación y menciona que una conmutación por error está en curso.

    Captura de pantalla que muestra una notificación sobre una conmutación por error en curso tras el inicio de una conmutación por error forzada.

  6. Una vez completada la conmutación por error al servidor en espera, una notificación le informa de la finalización.

    Captura de pantalla en la que se muestra la notificación cuando finaliza una conmutación por error forzada.

  7. Si los servidores principal y de reserva están implementados en zonas diferentes, comprueba que los valores de Zona de disponibilidad principal y Zona de disponibilidad de reserva se hayan invertido, en comparación con cómo estaban antes de que se iniciara la conmutación por error.

Inicio de una conmutación por error planeada

Siga estos pasos para realizar una conmutación por error planeada desde el servidor principal al servidor en espera en Azure Database for PostgreSQL. Al iniciar esta operación, prepara el servidor en espera y, a continuación, realiza la conmutación por error.

Esta operación de conmutación por error proporciona el menor tiempo de inactividad, ya que realiza una conmutación por error correcta al servidor en espera. Resulta útil para situaciones como devolver el servidor principal a la zona de disponibilidad preferida después de una conmutación por error inesperada.

Importante

  • No realice conmutaciones por error inmediatas consecutivas. Espere al menos de 15 a 20 minutos entre conmutaciones por error. Este tiempo de espera permite establecer completamente el nuevo servidor en espera.

  • Realice conmutaciones por error programadas durante períodos de baja actividad.

  • El tiempo general de la operación de un extremo a otro, tal y como se indica en el portal, podría ser mayor que el tiempo de inactividad real que experimente la aplicación. Mida el tiempo de inactividad desde la perspectiva de la aplicación.

Usa el portal de Azure:

  1. Seleccione el Azure Database for PostgreSQL servidor flexible que tenga habilitada la alta disponibilidad.

  2. En el menú de recursos, en la sección Configuración , seleccione Alta disponibilidad.

  3. Si los servidores principales y en espera se implementan en distintas zonas, tenga en cuenta los valores asignados a la zona de disponibilidad principal y a la zona de disponibilidad en espera. Estos valores se invierten después de que finalice la operación de conmutación por error.

    Captura de pantalla que muestra las zonas de disponibilidad de principal y en espera.

  4. Seleccione Conmutación por error planeada para iniciar el procedimiento de conmutación por error manual. Un cuadro de diálogo le informa del tiempo de inactividad esperado hasta que finalice la conmutación por error. Si decide continuar, seleccione Iniciar conmutación por error planeada.

    Captura de pantalla que muestra el cuadro de diálogo que se muestra antes del inicio de una conmutación por error planeada.

  5. Aparece una notificación y se menciona que la conmutación por error está en curso.

    Captura de pantalla que muestra una notificación sobre una conmutación por error en curso tras el inicio de una conmutación por error planificada.

  6. Una vez completada la conmutación por error al servidor en espera, una notificación le informa de la finalización.

    Captura de pantalla en la que se muestra la notificación cuando finaliza una conmutación por error planeada.

  7. Si el modo de alta disponibilidad está configurado con Redundancia de zona, confirme que los valores de Zona de disponibilidad principal y Zona de disponibilidad en espera ahora estén invertidos.

Limitaciones y consideraciones

  • Al habilitar o deshabilitar la alta disponibilidad en un servidor flexible Azure Database for PostgreSQL, el servicio no cambia otras configuraciones. Estas opciones incluyen la configuración de red, la configuración del firewall, los parámetros y la retención de copia de seguridad. Habilitar o deshabilitar la alta disponibilidad es una operación en línea. Esta operación no afecta a la conectividad y las operaciones de la aplicación.

  • Azure Database for PostgreSQL admite alta disponibilidad con ambas réplicas implementadas en la misma zona. Puede usar esta configuración en todas las regiones admitidas. Sin embargo, la alta disponibilidad con redundancia de zona solo está disponible en determinadas regiones.

  • El nivel Ampliable no admite la alta disponibilidad. Solo los niveles de uso general y optimizados para memoria admiten alta disponibilidad.

  • Al implementar un servidor en una región que conste de una sola zona de disponibilidad, solo se podrá habilitar la alta disponibilidad en el mismo modo de zona. Si Microsoft amplía la región en el futuro con varias zonas de disponibilidad, podrá implementar nuevos servidores flexibles de Azure Database for PostgreSQL con alta disponibilidad configurada como misma zona o redundancia de zona.

    Sin embargo, no puede habilitar directamente la alta disponibilidad en modo con redundancia de zona para cualquier servidor que implementó en la región cuando la región consta de una sola zona de disponibilidad. Como solución alternativa, puede usar la opción de restauración o la opción de réplica de lectura:

Opción Restaurar

  1. Restauración al punto de restauración más reciente.
  2. Después de crear el nuevo servidor, habilite la alta disponibilidad con redundancia de zona.
  3. Después de la comprobación de datos, si lo desea, puede eliminar el servidor antiguo.
  4. Asegúrese de modificar las cadenas de conexión de los clientes para que apunten al servidor recién restaurado.

Opción de réplica de lectura

  1. Cree una réplica de lectura en la misma región que el servidor principal.

  2. Promueva la réplica de lectura y hágala el nuevo servidor primario.

  3. Para conservar el nombre original, use puntos de conexión virtuales o quite la réplica principal anterior y a continuación, cree y promueva una nueva réplica de lectura.

  4. En el caso de los usuarios del portal, habilite resistencia zonal. Para las herramientas de desarrollo, establezca Alta disponibilidad con la opción Zone-Redundant.

  5. Cree una réplica de lectura en la misma región que el servidor principal.

  6. Promueva la réplica de lectura y hágala el nuevo servidor primario.

  7. Para conservar el nombre original, use puntos de conexión virtuales o quite la réplica principal anterior y a continuación, cree y promueva una nueva réplica de lectura.

  8. En el caso de los usuarios del portal, habilite resistencia zonal. Para las herramientas de desarrollo, establezca Alta disponibilidad con la opción Zone-Redundant.

Contenido relacionado

  • Last updated on