Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El servidor flexible de Azure Database for MySQL permite configurar la alta disponibilidad con conmutación automática por error. La solución de alta disponibilidad está diseñada para garantizar que los datos confirmados nunca se pierdan debido a errores y que la base de datos no será un único punto de error en la arquitectura de software. Cuando se configura la alta disponibilidad, el servidor flexible aprovisiona y administra automáticamente una réplica en espera. Se le facturará el proceso aprovisionado y el almacenamiento para la réplica principal y secundaria. Hay dos modelos de arquitectura de alta disponibilidad:
Alta disponibilidad con redundancia de zona. Esta opción es preferible para el aislamiento completo y la redundancia de la infraestructura en varias zonas de disponibilidad. Proporciona el máximo nivel de disponibilidad, pero exige configurar la redundancia de las aplicaciones entre zonas. La alta disponibilidad con redundancia de zona es preferible cuando se quiere lograr el máximo nivel de disponibilidad frente a cualquier error de infraestructura en la zona de disponibilidad y cuando la latencia entre las zonas de disponibilidad es aceptable. Solo se puede habilitar cuando se crea el servidor. La alta disponibilidad con redundancia de zona está disponible en un subconjunto de regiones de Azure que admiten varias zonas de disponibilidad y donde hay disponibles recursos compartidos de archivos Premium con redundancia de zona.
Alta disponibilidad en la misma zona. Esta opción es preferible para la redundancia de infraestructura con una menor latencia de red, ya que los servidores principales y en espera estarán en la misma zona de disponibilidad. Proporciona alta disponibilidad sin necesidad de configurar la redundancia de las aplicaciones entre zonas. Se prefiere la alta disponibilidad de la misma zona cuando quiera lograr el mayor nivel de disponibilidad dentro de una sola zona de disponibilidad con la latencia de red más baja. La alta disponibilidad de la misma zona está disponible en todas las Regiones de Azure donde puede usar el servidor flexible de Azure Database for MySQL.
Arquitectura de alta disponibilidad con redundancia de zona
Al implementar un servidor con alta disponibilidad con redundancia de zona, se crearán dos servidores:
- Un servidor principal en una zona de disponibilidad.
- Un servidor de réplica en espera que tiene la misma configuración que el servidor principal (nivel y tamaño de proceso, tamaño de almacenamiento y configuración de red) en otra zona de disponibilidad de la misma región de Azure.
Puede elegir la zona de disponibilidad para la réplica principal y la réplica en espera. La colocación de los servidores de bases de datos en espera y las aplicaciones en espera en la misma zona reduce la latencia. También le permite prepararse mejor para situaciones de recuperación ante desastres y escenarios de "zona inactiva".
Los archivos de datos y de registro se hospedan en almacenamiento con redundancia de zona (ZRS). El servidor en espera lee y reproduce los archivos de registro continuamente desde la cuenta de almacenamiento del servidor principal, que está protegida por la replicación de nivel de almacenamiento.
Si se produce una conmutación por error:
- Se activa la réplica en espera.
- Los archivos de registro binarios del servidor principal se siguen aplicando al servidor en espera para conectarlo a la última transacción confirmada en el servidor principal.
En ZRS, los registros son accesibles incluso cuando el servidor principal no está disponible. Esta disponibilidad ayuda a garantizar que no se pierdan datos. Una vez que se activa la réplica en espera y se aplican los registros binarios, el servidor de réplica en espera actual toma el rol del servidor principal. Se actualiza el DNS para que las conexiones del cliente se dirijan a la nueva réplica principal cuando el cliente se vuelva a conectar. La conmutación por error es totalmente transparente desde la aplicación cliente y no requiere ninguna acción por su parte. A continuación, en cuanto es posible, la solución de alta disponibilidad reactiva el servidor principal antiguo y lo coloca como servidor en espera.
Se utiliza el nombre del servidor de bases de datos para conectar las aplicaciones al servidor principal. La información de la réplica en espera no se expone para el acceso directo. Las confirmaciones y escrituras se confirman una vez que los archivos de registro se vacíen en el almacenamiento ZRS del servidor principal. Debido a la tecnología de replicación de sincronización que se usa en el almacenamiento ZRS, las aplicaciones pueden esperar un aumento de entre el 5 % y el 10 % de la latencia en las escrituras y confirmaciones.
Las copias de seguridad automáticas, tanto las de instantáneas como las de registros, se realizan en un almacenamiento con redundancia de zona desde el servidor de bases de datos principal.
Arquitectura de alta disponibilidad en la misma zona
Al implementar un servidor con alta disponibilidad en la misma zona, se crearán dos servidores en la misma zona:
- Un servidor principal
- Un servidor de réplica en espera que tiene la misma configuración que el servidor principal (nivel y tamaño de proceso, tamaño de almacenamiento y configuración de red).
El servidor en espera ofrece redundancia de infraestructura con una máquina virtual independiente (proceso). Esta redundancia reduce el tiempo de conmutación por error y la latencia de red entre la aplicación y el servidor de bases de datos debido a la coubicación.
Los archivos de datos y de registro se hospedan en almacenamiento con redundancia local (LRS). El servidor en espera lee y reproduce los archivos de registro continuamente desde la cuenta de almacenamiento del servidor principal, que está protegida por la replicación de nivel de almacenamiento.
Si se produce una conmutación por error:
- Se activa la réplica en espera.
- Los archivos de registro binarios del servidor principal se siguen aplicando al servidor en espera para conectarlo a la última transacción confirmada en el servidor principal.
En LRS, los registros son accesibles incluso cuando el servidor principal no está disponible. Esta disponibilidad ayuda a garantizar que no se pierdan datos. Una vez que se activa la réplica en espera y se aplican los registros binarios, la réplica en espera actual toma el rol del servidor principal. Se actualiza el DNS para redirigir las conexiones a la nueva réplica principal cuando el cliente se vuelve a conectar. La conmutación por error es totalmente transparente desde la aplicación cliente y no requiere ninguna acción por su parte. A continuación, en cuanto es posible, la solución de alta disponibilidad reactiva el servidor principal antiguo y lo coloca como servidor en espera.
Se utiliza el nombre del servidor de bases de datos para conectar las aplicaciones al servidor principal. La información de la réplica en espera no se expone para el acceso directo. Las confirmaciones y escrituras se confirman una vez que los archivos de registro se vacíen en el almacenamiento LRS del servidor principal. Dado que la réplica principal y la réplica en espera están en la misma zona, hay menos retraso de replicación y menor latencia entre el servidor de aplicaciones y el servidor de bases de datos. La configuración en la misma zona no proporciona alta disponibilidad en el escenario en que las infraestructuras dependientes quedan sin servicio en la zona de disponibilidad en cuestión. Habrá un tiempo de inactividad hasta que todos los servicios dependientes vuelvan a estar en línea en esa zona de disponibilidad.
Las copias de seguridad automáticas, tanto las instantáneas como las copias de seguridad de registros, se realizan en el almacenamiento con redundancia local desde el servidor de base de datos principal.
Nota
Para alta disponibilidad con redundancia de zona y misma zona:
- Si se produce un error, el tiempo necesario para que la réplica en espera asuma el rol principal depende del tiempo necesario para reproducir el registro binario de la cuenta de almacenamiento principal en espera. Por lo tanto, se recomienda usar claves principales en todas las tablas para reducir el tiempo de conmutación por error. Los tiempos de conmutación por error suelen oscilar entre 60 y 120 segundos.
- El servidor en espera no está disponible para operaciones de lectura o escritura. Es un modo de espera pasivo para permitir una conmutación por error rápida.
- Use siempre un nombre de dominio completo (FQDN) para conectarse al servidor principal. Evite usar una dirección IP para conectarse. Si se produce una conmutación por error, después de intercambiar los roles del servidor principal y en espera, podría cambiar el registro A de DNS. Ese cambio impedirá que la aplicación se conecte al nuevo servidor principal si se usa la dirección IP en la cadena de conexión.
Proceso de conmutación por error
Durante el proceso de conmutación por error en Azure Database for MySQL, el sistema cambia automáticamente del servidor principal a la réplica en espera para garantizar la continuidad y minimizar el tiempo de inactividad. Cuando se detecta un error, se promueve la réplica en espera para convertirla en el nuevo servidor principal. Los archivos de registro binarios del servidor principal original se aplican a la réplica en espera para sincronizarlos con la última transacción confirmada, lo que garantiza que no se pierda ningún dato. Esta transición sin problemas ayuda a mantener la alta disponibilidad y confiabilidad del servicio de base de datos.
Planeado: conmutación por error forzada
La conmutación por error forzada del servidor flexible de Azure Database for MySQL permite forzar manualmente una conmutación por error. Esta funcionalidad le permite probar la funcionalidad con los escenarios de la aplicación y le ayuda a prepararse para interrupciones.
La conmutación por error forzada desencadena una conmutación por error que activa la réplica en espera para que se convierta en el servidor principal con el mismo nombre de servidor de bases de datos al actualizar el registro de DNS. El servidor principal original se reinicia y se cambia a réplica en espera. Las conexiones de cliente se desconectan y deben volver a conectarse para reanudar sus operaciones.
El tiempo total de la conmutación por error depende de la carga de trabajo actual y del último punto de control. En general, se espera que tarde entre 60 y 120 segundos.
Nota
El evento de Azure Resource Health se genera en caso de conmutación por error planeada, que representa el tiempo de conmutación por error durante el cual el servidor no estaba disponible. Los eventos desencadenados se pueden ver cuando se seleccionan en "Resource Health" en el panel izquierdo. La conmutación por error manual/ iniciada por el usuario se representa mediante el estado "No disponible" y se etiqueta como "Planeada". Ejemplo: "Un usuario autorizado (planeado) desencadenó una operación de conmutación por error". Si el recurso permanece en este estado durante un período de tiempo prolongado, abra una incidencia de soporte técnico y le ayudaremos.
No planeado: conmutación automática por error
El tiempo de inactividad no planeado del servicio puede deberse a errores de software o errores de infraestructura, como errores de proceso, red o almacenamiento, o a interrupciones de energía que afectan a la disponibilidad de la base de datos. Si la base de datos deja de estar disponible, la replicación en la réplica en espera se anula y la réplica en espera se activa para ser la base de datos principal. Se actualiza el DNS y los clientes se vuelven a conectar al servidor de bases de datos y reanudan sus operaciones.
Se espera que el tiempo total de la conmutación por error esté entre 60 y 120 segundos. Sin embargo, en función de la actividad del servidor de base de datos principal en el momento de la conmutación por error (como transacciones grandes y tiempo de recuperación), la conmutación por error puede tardar más tiempo.
Nota
El evento de Azure Resource Health se genera en caso de conmutación por error no planeada, que representa el tiempo de conmutación por error durante el cual el servidor no estaba disponible. Los eventos desencadenados se pueden ver cuando se seleccionan en "Resource Health" en el panel izquierdo. La conmutación automática por error se representa mediante el estado "No disponible" y se etiqueta como "No planeada". Ejemplo: "No disponible: se desencadenó automáticamente una operación de conmutación por error (no planeada)". Si el recurso permanece en este estado durante un período de tiempo prolongado, abra una incidencia de soporte técnico y le ayudaremos.
Funcionamiento de la detección automática de conmutación por error en servidores habilitados para alta disponibilidad
El servidor principal y el servidor secundario tienen dos puntos de conexión de red:
- Punto de conexión de cliente: el cliente conecta y ejecuta la consulta en la instancia mediante este punto de conexión.
- Punto de conexión de administración: se usa internamente para las comunicaciones de servicio a los componentes de administración y para conectarse al almacenamiento de back-end.
El componente monitor de estado realiza continuamente las siguientes comprobaciones:
- El monitor hace ping a los nodos de punto de conexión de la red de administración. Si se produce un error en esta comprobación dos veces consecutivas, se desencadena la operación de conmutación automática por error. Los escenarios en los que el nodo no está disponible o no responde debido a un problema del sistema operativo, en los que hay problemas de red entre los componentes de administración y los nodos, etc., se solucionarán mediante esta comprobación de estado.
- El monitor también ejecuta una consulta sencilla en la instancia. Si las consultas no se ejecutan, se desencadenará la conmutación automática por error. Esta comprobación de estado solucionará los escenarios en los que el demonio de MySQL se bloquea o se detiene, en los que hay problemas de almacenamiento de back-end, etc.
Nota
Si hay algún problema de red entre la aplicación y el punto de conexión de red del cliente (acceso privado o público), ya sea en la ruta de acceso de red, en el punto de conexión o problemas de DNS en el lado cliente, la comprobación de estado no supervisa este escenario. Si usa acceso privado, asegúrese de que las reglas del grupo de seguridad de red de la red virtual no bloquean la comunicación con el punto de conexión de red del cliente de la instancia en el puerto 3306. Para el acceso público, asegúrese de que las reglas de firewall estén establecidas y que se permita el tráfico de red en el puerto 3306 (si la ruta de acceso de red tiene otros firewalls). También debe prestarse atención a la resolución DNS del lado de la aplicación cliente.
Supervisión de alta disponibilidad
La opción Estado de alta disponibilidad ubicada en el panel Alta disponibilidad del servidor en el portal se puede usar para determinar el estado de configuración de alta disponibilidad del servidor.
| Estado | Descripción |
|---|---|
| NotEnabled | La alta disponibilidad no está habilitada. |
| ReplicatingData | El servidor en espera está en proceso de sincronizarse con el servidor principal en el momento del aprovisionamiento del servidor de alta disponibilidad o cuando la opción habilite. |
| FailingOver | El servidor de bases de datos está en proceso de conmutar por error desde el principal al de espera. |
| Healthy | La opción alta disponibilidad está habilitada. |
| RemovingStandby | Cuando la opción de alta disponibilidad está deshabilitada y el proceso de eliminación está en curso. |
También puede usar las métricas siguientes para supervisar el estado del servidor de alta disponibilidad.
| Nombre para mostrar de la métrica | Métrica | Unidad | Descripción |
|---|---|---|---|
| Estado de IO de alta disponibilidad | ha_io_running | Estado | Estado de E/S de alta disponibilidad indica el estado de replicación de alta disponibilidad. El valor de métrica es 1 si el subproceso de E/S se está ejecutando y 0 si no lo está. |
| Estado de SQL de alta disponibilidad | ha_sql_running | Estado | El estado de SQL de alta disponibilidad indica el estado de la replicación de alta disponibilidad. El valor de métrica es 1 si el subproceso de SQL se está ejecutando y 0 si no lo está. |
| Intervalo de replicación de alta disponibilidad | retardo de replicación | Segundos | El retraso de replicación es el número de segundos en que el modo de espera está detrás de la reproducción de las transacciones recibidas en el servidor principal. |
Limitaciones
Estas son algunas consideraciones que se deben tener en cuenta al usar la alta disponibilidad:
La alta disponibilidad con redundancia de zona solo se puede configurar durante la creación del servidor.
La alta disponibilidad no se admite en el nivel de proceso ampliable.
Al reiniciar el servidor de base de datos principal para recoger los cambios de parámetro estáticos, también se reinicia la réplica en espera.
Se activará el modo GTID, ya que la solución de alta disponibilidad usa GTID. Compruebe si la carga de trabajo tiene restricciones o limitaciones en la replicación con GTID.
Nota
Si va a habilitar la alta disponibilidad en la misma zona después de crear el servidor, debe asegurarse de que los parámetros del servidor "enforce_gtid_consistency" y "gtid_mode" estén activados antes de habilitar la alta disponibilidad.
Nota
El crecimiento automático de almacenamiento está habilitado de forma predeterminada para un servidor configurado de alta disponibilidad y no se puede deshabilitar.
Comprobaciones de estado
Al configurar la alta disponibilidad (HA) para Azure Database for MySQL, las comprobaciones de estado desempeñan un papel fundamental en el mantenimiento de la confiabilidad y el rendimiento de la base de datos. Estas comprobaciones supervisan continuamente el estado y el mantenimiento de la réplica principal y la réplica en espera, lo que garantiza que los problemas se detecten rápidamente. Mediante el seguimiento de varias métricas, como la capacidad de respuesta del servidor, el retraso de replicación y el uso de recursos, las comprobaciones de estado ayudan a garantizar que los procesos de conmutación por error se puedan ejecutar de forma fluida, lo que minimiza el tiempo de inactividad y evita la pérdida de datos. Las comprobaciones de estado configuradas correctamente son esenciales para lograr el nivel deseado de disponibilidad y resistencia en la configuración de la base de datos.
Supervisión del estado
"Los usuarios pueden supervisar el estado de su configuración de alta disponibilidad a través de Azure Portal. Entre las métricas que se deben observar se encuentran:
- La capacidad de respuesta del servidor: indica si se puede acceder al servidor principal.
- El retraso de replicación: mide el retraso entre la réplica principal y la réplica en espera, lo que garantiza la coherencia de los datos.
- El uso de recursos: supervisa el uso de CPU, memoria y almacenamiento para evitar cuellos de botella".
Preguntas más frecuentes
¿Cuáles son los Acuerdos de Nivel de Servicio para el servidor flexible con redundancia de zona frente a alta disponibilidad con redundancia de zona?
Puede encontrar información del Acuerdo de Nivel de Servicio del servidor flexible de Azure Database for MySQL en SLA for Azure Database for MySQL.
¿Cómo se facturan los servidores de alta disponibilidad? Los servidores habilitados con alta disponibilidad tienen una réplica principal y secundaria. La réplica secundaria puede estar en la misma zona o tener redundancia de zona. Se le facturará por el proceso y el almacenamiento aprovisionados para la réplica principal y secundaria. Por ejemplo, si tiene una réplica principal con 4 núcleos virtuales de proceso y 512 GB de almacenamiento aprovisionado, la réplica secundaria también tendrá 4 núcleos virtuales y 512 GB de almacenamiento aprovisionado. El servidor de alta disponibilidad con redundancia de zona se facturará por 8 núcleos virtuales y 1024 GB de almacenamiento. Dependiendo del volumen de almacenamiento de copia de seguridad, también se le puede facturar por el almacenamiento de copia de seguridad.
¿Puedo usar la réplica en espera para las operaciones de lectura o escritura?
El servidor en espera no está disponible para operaciones de lectura o escritura. Es un modo de espera pasivo para habilitar la conmutación por error rápida.¿Se producirá una pérdida de datos cuando se produzca la conmutación por error?
En ZRS, los registros son accesibles incluso cuando el servidor principal no está disponible. Esta disponibilidad ayuda a garantizar que no se pierdan datos. Una vez que se activa la réplica en espera y se aplican los registros binarios, esta adopta los roles del servidor principal.¿Es necesario realizar alguna acción después de una conmutación por error?
Las conmutaciones por error son totalmente transparentes desde la aplicación cliente. No es necesario realizar ninguna acción. La aplicación solo debe utilizar una lógica de reintento para sus conexiones.¿Qué ocurre cuando no elijo una zona específica para mi réplica en espera? ¿Puedo cambiar la zona más adelante?
Si no elige una zona, se seleccionará una aleatoriamente. Será la que se usa para el servidor principal. Para cambiar la zona más adelante, puede establecer Alta disponibilidad en Deshabilitado en el panel Alta disponibilidad y luego volver a establecerlo en Redundancia de zona y seleccionar una zona.¿La replicación entre las réplicas principal y en espera es sincrónica?
La replicación entre las réplicas principal y en espera es similar al modo semisincrónico de MySQL. Cuando se confirma una transacción, no se confirma necesariamente en el modo de espera. Pero cuando la principal no está disponible, el modo de espera replica todos los cambios de datos de la principal para asegurarse de que no hay pérdida de datos.¿Hay una conmutación por error en la réplica en espera para todos los errores no planeados?
Si hay un bloqueo en la base de datos o un error del nodo, la máquina virtual del servidor flexible se reinicia en el mismo nodo. Al mismo tiempo, se desencadena una conmutación automática por error. Si el reinicio de la máquina virtual con servidor flexible se realiza correctamente antes de que finalice la conmutación por error, se cancelará la operación de conmutación por error. La determinación del servidor que se va a usar como réplica principal depende del proceso que finaliza primero.¿Hay un impacto en el rendimiento cuando uso alta disponibilidad?
En el caso de una alta disponibilidad con redundancia de zona, aunque no hay ningún impacto destacado en el rendimiento de las cargas de trabajo de lectura en las zonas de disponibilidad, puede haber una reducción de hasta el 40 % en la latencia de escritura de consultas. El aumento de la latencia de escritura se debe a la replicación sincrónica en toda la zona de disponibilidad. El impacto en la latencia de escritura suele ser el doble en una alta disponibilidad con redundancia de zona en comparación con una alta disponibilidad en la misma zona. Para la alta disponibilidad de la misma zona, dado que la réplica principal y la réplica en espera están en la misma zona, la latencia de replicación y, por tanto, la latencia de escritura sincrónica es menor. En resumen, si la latencia de escritura es más crítica para usted en comparación con la disponibilidad, es posible que quiera elegir la alta disponibilidad de la misma zona, pero si la disponibilidad y la resistencia de los datos son más críticas para usted a costa de la caída de latencia de escritura, debe elegir alta disponibilidad con redundancia de zona. Para medir el impacto preciso de la caída de latencia en la configuración de alta disponibilidad, se recomienda realizar pruebas de rendimiento para que la carga de trabajo tome una decisión informada.¿Cómo se produce el mantenimiento del servidor de alta disponibilidad?
Los eventos planeados, como el escalado de las actualizaciones de la versión secundaria y de proceso, operan primero en la instancia en espera original, después desencadenan una operación de conmutación por error planeada y, después, operan en la instancia principal original. Puede establecer laventana de mantenimiento programado para los servidores de alta disponibilidad como lo hace para servidores flexibles. La cantidad de tiempo de inactividad será el mismo que el tiempo de inactividad de la instancia del servidor flexible de Azure Database for MySQL cuando la alta disponibilidad esté deshabilitada.¿Puedo realizar una restauración a un momento dado (PITR) de mi servidor de alta disponibilidad?
Puede realizar una PITR para una instancia de servidor flexible de Azure Database for MySQL habilitada para alta disponibilidad en una nueva instancia de servidor flexible de Azure Database for MySQL que tenga deshabilitado la alta disponibilidad. Si el servidor de origen se creó con alta disponibilidad con redundancia de zona, puede habilitar la alta disponibilidad con redundancia de zona o la misma zona en el servidor restaurado más adelante. Si el servidor de origen se creó con alta disponibilidad de la misma zona, solo puede habilitar la alta disponibilidad de la misma zona en el servidor restaurado.¿Puedo habilitar la alta disponibilidad en un servidor después de crear el servidor?
La alta disponibilidad con redundancia de zona debe estar habilitada durante la creación del servidor. Puede habilitar la alta disponibilidad de la misma zona después de la creación del servidor, pero asegúrese de que los parámetros del servidor enforce_gtid_consistency y gtid_mode estén establecidos enON antes de continuar.¿Puedo deshabilitar la alta disponibilidad para un servidor después de crearlo?
Puede deshabilitar la alta disponibilidad en un servidor después de crearlo. La facturación se detiene inmediatamente.¿Cómo puedo mitigar el tiempo de inactividad?
Aunque no use la alta disponibilidad, debe poder mitigar el tiempo de inactividad de la aplicación. El tiempo de inactividad del servicio, como las revisiones programadas, las actualizaciones de versiones secundarias o las operaciones iniciadas por el cliente, como el escalado del proceso, se pueden realizar durante las ventanas de mantenimiento programadas. Para mitigar el impacto de la aplicación en las tareas de mantenimiento iniciadas por Azure, puede programarlas en un día de la semana y una hora que minimice el impacto en la aplicación.¿Puedo usar una réplica de lectura para un servidor habilitado para alta disponibilidad?
Sí, se admiten réplicas de lectura para los servidores de alta disponibilidad.¿Puedo usar la replicación de datos de entrada para servidores de alta disponibilidad?
Soporte con la replicación de datos de entrada para el servidor habilitado para alta disponibilidad (HA) solo está disponible a través de la replicación basada en GTID. El procedimiento almacenado para la replicación mediante GTID está disponible en todos los servidores habilitados para alta disponibilidad por el nombremysql.az_replication_with_gtid.Para reducir el tiempo de inactividad, ¿puedo conmutar por error al servidor en espera durante los reinicios del servidor o al escalar o reducir verticalmente?
Actualmente, el servidor flexible de Azure Database for MySQL ha utlizado la conmutación por error planeada para optar por las operaciones de alta disponibilidad, incluido el escalado o reducción vertical, y el mantenimiento planeado para ayudar a reducir el tiempo de inactividad. Cuando se inician estas operaciones, operaría primero en la instancia de espera original, seguida de desencadenar una operación de conmutación por error planeada y, a continuación, funcionaría en la instancia principal original.Puede cambiar el modo de disponibilidad (alta disponibilidad con redundancia de zona/misma zona) del servidor
Si crea el servidor con el modo de alta disponibilidad con redundancia de zona habilitado, puede cambiar de alta disponibilidad con redundancia de zona a la misma zona y viceversa. Para cambiar el modo de disponibilidad, puede establecer Alta disponibilidad en Deshabilitado en el panel Alta disponibilidad y luego volver a establecerlo en Redundancia de zona o en la misma zona y seleccionar Modo de alta disponibilidad.