Migración a La Cumbre de innovación:
Obtenga información sobre cómo migrar y modernizar a Azure puede aumentar el rendimiento, la resistencia y la seguridad de su empresa, lo que le permite adoptar completamente la inteligencia artificial.Regístrese ahora
Este explorador ya no se admite.
Actualice a Microsoft Edge para aprovechar las características y actualizaciones de seguridad más recientes, y disponer de soporte técnico.
El servicio de Azure SQL Managed Instance garantiza automáticamente que todas las bases de datos están en línea y en un estado correcto, y procura en todo momento que se logra el Acuerdo de Nivel de Servicio publicado.
En esta guía se proporciona una revisión detallada de los pasos proactivos que se pueden realizar para maximizar la disponibilidad, garantizar la recuperación y estar preparados para una interrupción de Azure. Esta guía se aplica a todos los niveles de servicio de Azure SQL Managed Instance.
Lista de comprobación de disponibilidad
Estas son las configuraciones recomendadas que se pueden implementar para maximizar la disponibilidad:
Incorpore lógica de reintento en la aplicación para controlar errores transitorios.
Use las ventanas de mantenimiento para que los eventos de mantenimiento de alcance sean predecibles y menos disruptivos.
A continuación se muestra la configuración recomendada para lograr una alta disponibilidad:
Habilite la redundancia de zona cuando esté disponible para la instancia administrada de SQL a fin de garantizar la resiliencia para fallos en zonas.
Lista de comprobación de recuperación de desastres
Aunque Azure SQL Managed Instance mantiene automáticamente la disponibilidad, hay instancias en las que incluso contar con alta disponibilidad (redundancia de zona) podrían no garantizar la resiliencia, ya que el alcance de la interrupción llega a toda una región. Una interrupción de Azure SQL Managed Instance regional puede requerir el inicio de una recuperación ante desastres.
Para prepararse mejor para la recuperación ante desastres, sigue estas recomendaciones:
Use los puntos de conexión del agente de escucha de lectura y escritura y de solo lectura en la aplicación cadena de conexión para que las aplicaciones se conecten automáticamente a cualquier instancia principal.
Asegúrese de que la instancia secundaria geográfica se crea con el mismo nivel de servicio, generación de hardware y tamaño de proceso que la instancia principal.
Cuando se escala verticalmente, escale verticalmente primero la geoárea secundaria y, después, escale verticalmente la principal.
Al reducir verticalmente, invierta el orden: primero escale verticalmente la principal y, a continuación, escale verticalmente la secundaria.
Por naturaleza, la recuperación ante desastres está diseñada para usar la replicación asincrónica de datos entre la región primaria y la secundaria. Para priorizar la disponibilidad de los datos sobre una mayor latencia de confirmación, considere la posibilidad de llamar al procedimiento almacenado sp_wait_for_database_copy_sync inmediatamente después de confirmar una transacción. La llamada a sp_wait_for_database_copy_sync bloquea el subproceso de llamada hasta que se transmite y protege la última transacción confirmada en el registro de transacciones de la base de datos secundaria.
Supervisa el retraso con respecto al objetivo de punto de recuperación (RPO) usando la columna replication_lag_sec de la vista de administración dinámica (DMV) sys.dm_geo_replication_link_status en la base de datos principal. Las DMV muestran el retardo, en segundos, entre las transacciones confirmadas en la base de datos principal y las reforzadas en el registro de transacciones de la secundaria. Por ejemplo, supón que el retraso es de un segundo en un momento dado, si la principal se ve afectada por una interrupción y se inicia una conmutación por error geográfica en ese momento, se perderán las transacciones confirmadas en el último segundo.
Preparación de la base de datos secundaria para una interrupción
Para que la recuperación se realice correctamente en otra región de datos mediante los grupos de conmutación por error o la restauración geográfica, debe preparar una instancia de Azure SQL Managed Instance en otra región. Esta instancia secundaria puede pasar a ser la nueva instancia principal si es necesario. También debe tener pasos bien definidos documentados y probados para garantizar una recuperación fluida. Estos son algunos de los pasos correspondientes a la fase de preparación:
En una restauración geográfica, identifique la instancia lógica en otra región que va a pasar a ser la nueva instancia principal. Suele ser una instancia en la región asociada para la región donde esté la instancia principal. El uso de una instancia en una región emparejada con la región primaria elimina el coste del tráfico adicional durante las operaciones de restauración geográfica.
Determine cómo va a redirigir a los usuarios al nuevo servidor principal. Redirigir a los usuarios podría lograrse cambiando manualmente las cadenas de conexión de la aplicación o las entradas DNS. Si tiene configurados grupos de conmutación por error y usa el agente de escucha de solo lectura y escritura en las cadenas de conexión de la aplicación, no es necesaria ninguna acción más, ya que las conexiones se dirigen automáticamente al nuevo principal después de la conmutación por error.
Identificar y, de manera opcional, crear los inicios de sesión que deben estar presentes en la base de datos master del nuevo servidor principal, así como asegurarse de que tienen los permisos adecuados en la base de datos master, si procede.
Documente la configuración de auditoría en la principal actual y haga que sea idéntica en la instancia secundaria.
Administre una infraestructura de base de datos de SQL Server para bases de datos relacionales locales e híbridas en la nube mediante las ofertas de bases de datos relacionales PaaS de Microsoft.
Descubra cómo recuperar una base de datos tras un error o una interrupción de un centro de datos regional con varias características de Azure SQL Managed Instance.
Obtenga información de instrucciones y procedimientos recomendados para usar Azure SQL Managed Instance a fin de realizar exploraciones en profundidad de la recuperación ante desastres.
Obtenga información sobre cómo Azure SQL Managed Instance admite la continuidad empresarial y recuperación ante desastres en la nube, y ayuda a que las aplicaciones críticas en la nube se sigan ejecutando.
Obtenga información sobre la arquitectura de Azure SQL Managed Instance que logra la disponibilidad mediante la redundancia local y la alta disponibilidad mediante la redundancia de zona.
Los grupos de conmutación por error permiten administrar la replicación geográfica y la conmutación por error o coordinada de todas las bases de datos de usuario de una instancia administrada en Azure SQL Managed Instance.