Guía de recuperación ante desastres: Azure SQL Database

Se aplica a:Azure SQL Database

Azure SQL Database proporciona una garantía de alta disponibilidad líder del sector de al menos el 99,99 % para admitir una amplia variedad de aplicaciones, incluidas aplicaciones críticas, que deben estar siempre disponibles. Azure SQL Database ofrece también la posibilidad de tener una solución de continuidad empresarial clave que permite llevar a cabo una recuperación ante desastres rápida en caso de producirse una interrupción regional. Este artículo contiene información de gran valor que conviene revisar antes de la implementación de una aplicación.

Aunque siempre estamos esforzándonos por proporcionar alta disponibilidad, hay ocasiones en las que el servicio de Azure SQL Database sufre interrupciones, lo que hace que la base de datos deje de estar disponible y, por tanto, afecta a la aplicación. Cuando la supervisión del servicio detecta problemas que provocan errores de conectividad generalizados, averías o problemas de rendimiento, el servicio declara automáticamente una interrupción para mantener al usuario informado.

Interrupción del servicio

En caso de que se produzca una interrupción del servicio de Azure SQL Database, encontraras más detalles relacionados con esa interrupción en los siguientes sitios:

• Banner de Azure Portal

  Si se detecta que tu suscripción está afectada, verás una alerta de interrupción de un problema de servicio en las notificaciones de Azure Portal:

  

• Ayuda y soporte técnico o Soporte y solución de problemas

  Al crear una incidencia de soporte técnico en Ayuda y soporte técnico o en Soporte y solución de problemas, verás información sobre los problemas que afectan a los recursos. Seleccione Ver los detalles de la interrupción para obtener más información y un resumen del alcance. También aparece una alerta en la página Nueva solicitud de soporte técnico.

  

• Estado del servicio

  La página Estado del servicio de Azure Portal contiene información sobre el estado global del centro de datos de Azure. Busca ‘estado del servicio’ en la barra de búsqueda de Azure Portal y, a continuación, consulta Problemas de servicio en la categoría Eventos activos. También puede ver el estado de un recurso concreto en la página Estado de los recursos del recurso en cuestión, en el menú Ayuda. A continuación se muestra una captura de pantalla de ejemplo de la página Estado del servicio con información sobre un problema de servicio activo en el sudeste asiático:

  

• Notificación de correo electrónico

  Si has configurado alertas, recibirás una notificación por correo electrónico de azure-noreply@microsoft.com cuando una interrupción del servicio afecte a tu suscripción y recurso. El cuerpo del correo electrónico suele comenzar con «La alerta del registro de actividad... se activó por un problema de servicio para la suscripción de Azure...». Para obtener más información sobre las alertas de estado de servicios, vea Recepción de alertas del registro de actividad en notificaciones de servicio de Azure mediante Azure Portal.

Cuándo iniciar la recuperación ante desastres durante una interrupción

En caso de producirse una interrupción del servicio que afecta a los recursos de la aplicación, ten en cuenta las siguientes líneas de acción:

• Los equipos de profesionales de Azure trabajan diligentemente para restaurar la disponibilidad del servicio lo antes posible, pero dependiendo de la causa principal, a veces pueden tardar horas. Si la aplicación puede tolerar un tiempo de inactividad considerable, puede esperar hasta que se complete la recuperación. En este caso, no se requieren acciones por su parte. Consulte el estado de un recurso concreto en la página Estado de los recursos del recurso en cuestión, en el menú Ayuda. Consulte la página Estado de los recursos para ver las actualizaciones y la información más reciente sobre una interrupción. Después de la recuperación de la región, se restaura la disponibilidad de la aplicación.

• La recuperación en otra región de Azure puede requerir cambiar las cadenas de conexión de la aplicación o usar el redireccionamiento DNS, lo que puede conllevar una pérdida de datos permanente. Por lo tanto, la recuperación ante desastres solo se debe realizar cuando la duración de la interrupción se aproxime al objetivo de tiempo de recuperación (RTO) de la aplicación. Si la aplicación está implementada en producción, se debe realizar una supervisión periódica del estado de la aplicación y confirmar que la recuperación solo se garantiza cuando se produce un error de conectividad prolongado desde el nivel de aplicación a la base de datos. Dependiendo de la tolerancia de la aplicación a los tiempos de inactividad y de la posible responsabilidad comercial, el usuario puede decidir si esperar a que el servicio se recupere o iniciar la recuperación ante desastres por sí mismo.

Guía de recuperación de interrupciones

Considera la posibilidad de realizar los siguientes pasos si la interrupción de Azure SQL Database en una región no se ha mitigado durante un período de tiempo prolongado y afecta al Acuerdo de Nivel de Servicio (SLA) de la aplicación:

Conmutación por error (sin pérdida de datos) en un servidor secundario con replicación geográfica

Si la replicación geográfica activa o los grupos de conmutación por error están habilitados, comprueba que el estado del recurso de las bases de datos principal y secundaria aparece reflejado como En línea en Azure Portal. Si es así, el plano de datos de las bases de datos tanto principal como secundaria es correcto. Inicia una conmutación por error de la replicación geográfica activa o de los grupos de conmutación por error en la región secundaria mediante Azure Portal, T-SQL, PowerShell o la CLI de Azure.

Usa los siguientes vínculos para iniciar una conmutación por error:

Conmutación por error forzada (posible pérdida de datos) en un servidor secundario con replicación geográfica

Si la conmutación por error no se completa correctamente y surgen errores, o si el estado de la base de datos principal no es En línea, sopesa detenidamente la posibilidad de realizar una conmutación por error forzada, con una posible pérdida de datos en la región secundaria.

Usa los siguientes vínculos para iniciar una conmutación por error forzada:

Geo-restore

Si no se ha habilitado la replicación geográfica activa ni grupos de conmutación por error, puedes usar como último recurso la restauración geográfica para recuperarse de una interrupción. La restauración geográfica usa copias de seguridad con replicación geográfica como origen. Una base de datos situada en cualquier servidor lógico de cualquier región de Azure se puede restaurar desde las copias de seguridad con replicación geográfica más recientes. Puede solicitar una restauración geográfica, incluso si la base de datos o toda la región está inaccesible debido a una interrupción.

Para obtener más información sobre la restauración geográfica a través de la CLI de Azure, Azure Portal, PowerShell o API REST, consulta Restauración geográfica de una base de datos de Azure SQL.

Configuración de la base de datos después de realizar la recuperación

Si se usa la conmutación por error o restauración geográficas para recuperarse tras una interrupción, hay que asegurarse de que la conectividad con la nueva base de datos está configurada correctamente para que se pueda reanudar el funcionamiento normal de la aplicación. Esta es una lista de comprobación de las tareas necesarias para que la producción de la base de datos recuperada esté lista.

Actualización de cadenas de conexión

• Si se usa la replicación geográfica activa o la restauración geográfica para recuperarse tras una interrupción, hay que asegurarse de que la conectividad con las nuevas bases de datos está configurada correctamente para que se pueda reanudar el funcionamiento normal de la aplicación. Dado que la base de datos recuperada reside en otro servidor, es preciso que actualice la cadena de conexión de la aplicación para que apunte a dicho servidor. Para obtener más información sobre cómo cambiar las cadenas de conexión, consulte el lenguaje de desarrollo adecuado para la biblioteca de conexiones.
• Si se usan grupos de conmutación por error para recuperarse de una interrupción y se emplean agentes de escucha de solo lectura y solo escritura en las cadenas de conexión de la aplicación, no será necesaria ninguna acción más, ya que las conexiones se dirigirán automáticamente a la nueva base de datos principal.

Configurar reglas de firewall

Es preciso que se asegure de que las reglas del firewall configuradas tanto en el servidor como en la base de datos coinciden con las configuradas en el servidor principal y en la base de datos principal. Para más información, vea: Cómo: configurar el firewall (Azure SQL Database).

Configuración de inicios de sesión de y de usuarios de la base de datos

Cree los inicios de sesión que deben estar presentes en la base de datos master del nuevo servidor principal y asegúrese 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.

Configuración de alertas de telemetría

Debe asegurarse de que la configuración actual de la regla de alertas está actualizada para asignarla a la nueva base de datos principal y al otro servidor. Para obtener más información sobre las reglas de alerta de las bases de datos, consulte Recibir notificaciones de alerta y Realización de seguimiento del estado.

Habilitar auditoría

Si se requiere una auditoría para tener acceso a una base de datos, será preciso habilitar Auditoría tras la recuperación de la base de datos. Para obtener más información, vea Auditoría de Azure SQL para Azure SQL Database.

Pasos siguientes

• Revise el Acuerdo de Nivel de Servicio de Azure SQL Database.
• Para obtener información sobre las copias de seguridad automatizadas de Azure SQL Database, consulte Copias de seguridad automatizadas de SQL Database
• Para obtener información sobre los escenarios de recuperación y diseño de la continuidad empresarial, consulte el artículo sobre 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
• Obtenga más información sobre la replicación geográfica activa.
• Más información sobre los grupos de conmutación por error
• Más información sobre la restauración geográfica
• Obtenga más información sobre las bases de datos con redundancia de zona.