Lista de comprobación de Alta disponibilidad y recuperación ante desastres: Azure SQL Managed Instance
Se aplica a: Azure SQL Managed Instance
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.
- Prueba la resistencia a errores de la aplicación; para ello, desencadena manualmente una conmutación por error para ver la resiliencia en acción.
Lista de comprobación de alta disponibilidad
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:
- Habilite los grupos de conmutación por error para una instancia.
- 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.
- Establece la directiva de conmutación por error en administrada por el cliente.
- 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. - Si no es posible habilitar grupos de conmutación por error, considera la posibilidad de establecer la opción de redundancia de almacenamiento de copia de seguridad en Almacenamiento de copia de seguridad con redundancia geográfica para usar la funcionalidad de restauración geográfica.
- Esta opción no está disponible en regiones sin par de regiones.
- Planea y ejecuta simulacros de recuperación ante desastres con frecuencia para estar mejor preparado en caso de una interrupción real.
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.
- Identifique y, opcionalmente, defina la configuración del grupo de seguridad de red y la tabla de rutas que los usuarios necesitan para acceder a la nueva base de datos principal en la nueva principal.
- 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 datosmaster
, si procede. - Documente la configuración de auditoría en la principal actual y haga que sea idéntica en la instancia secundaria.
Contenido relacionado
Para obtener más información, revise:
- Alta disponibilidad para Azure SQL Managed Instance
- Escenarios de continuidad
- Guía de recuperación ante desastres
- Acuerdo de Nivel de Servicio de Azure SQL Managed Instance
- Copias de seguridad automatizadas
- Restauración de una base de datos a partir de las copias de seguridad iniciadas por el servicio
- Grupos de conmutación por error
- Restauración geográfica