Lista de comprobación de alta disponibilidad y recuperación ante desastres de Azure SQL Database

Se aplica a:Azure SQL Database

El servicio de Azure SQL Database 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 es válida para todos los modelos de compra y niveles de servicio de Azure SQL Database.

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:

• Habilita la redundancia de zona cuando esté disponible para la base de datos o el grupo elástico, así garantizarás la resiliencia para fallos en zonas.

Lista de comprobación de recuperación de desastres

Aunque Azure SQL Database 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 Database regional puede requerir el inicio de una recuperación ante desastres.

Para prepararse mejor para la recuperación ante desastres, sigue estas recomendaciones:

• Habilita grupos de conmutación por error para un grupo de bases de datos.
  • Usa 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 servidor y base de datos principal.
  • Establece la directiva de conmutación por error en administrada por el cliente.
• De manera alternativa a los grupos de conmutación por error, habilita la replicación geográfica activa para tener una base de datos secundaria legible en otra región de Azure.
• Asegúrese de que la base de datos secundaria geográfica se crea con el mismo nivel de servicio, el nivel de proceso (aprovisionado o sin servidor) y el tamaño de proceso (DTU o núcleos virtuales) que la base de datos 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.
• 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 la 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 o replicación geográfica activa, 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 usando la replicación geográfica activa, los grupos de conmutación por error o la restauración geográfica, debes preparar un servidor lógico de Azure SQL Database secundario en otra región. Este servidor secundario puede pasar a ser el nuevo servidor 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 el servidor lógico en otra región que va a pasar a ser el nuevo servidor principal. Suele ser un servidor en la región asociada para la región principal donde esté la base de datos. El uso de un servidor en la misma región elimina el coste adicional del tráfico 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 tienes configurados grupos de conmutación por error y usas 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) las reglas de firewall necesarias para que los usuarios accedan la nueva base de datos 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 datos master, si procede. Para obtener más información, vea Seguridad de Azure SQL Database después de una recuperación ante desastres.
• Identifique las reglas de alerta que deben actualizarse para que se asignen a la nueva base de datos principal.
• Documente la configuración de auditoría de la base de datos principal actual.

Contenido relacionado

• Revise Guía de recuperación ante desastres de Azure SQL Database.
• Revise el Acuerdo de Nivel de Servicio de Azure SQL Database.
• Para saber en qué consisten las copias de seguridad automatizadas de Azure SQL Database, consulte Información general: copias de seguridad automatizadas de SQL Database.
• Para obtener información sobre los escenarios de recuperación y diseño de la continuidad empresarial, vea Escenarios de continuidad.
• Si quiere saber cómo utilizar las copias de seguridad automatizadas para procesos de recuperación, consulte Recover an Azure SQL database using automated database backups(Recuperación de una base de datos SQL de Azure mediante copias de seguridad de base de datos automatizadas).
• Obtenga más información sobre la replicación geográfica activa.
• Más información sobre los grupos de conmutación por error.
• Obtenga más información sobre la restauración geográfica.
• Obtenga más información sobre las bases de datos con redundancia de zona.