Confiabilidad en Azure SQL Database

Azure SQL Database es un motor de base de datos de plataforma como servicio (PaaS) totalmente administrado que se encarga de la mayoría de las funciones de administración de bases de datos, como actualizar, aplicar revisiones, crear copias de seguridad y supervisar sin intervención del usuario.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Azure SQL Database sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de regiones. También se describe cómo puede usar copias de seguridad para recuperarse de otros tipos de problemas, cómo controlar el mantenimiento del servicio y resaltar cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Azure SQL Database.

Recomendaciones de implementación de producción

Para obtener información sobre cómo implementar Azure SQL Database para admitir los requisitos de confiabilidad de la solución y cómo afecta la confiabilidad a otros aspectos de la arquitectura, consulte Procedimientos recomendados de arquitectura para Azure SQL Database en Azure Well-Architected Framework.

Introducción a la arquitectura de confiabilidad

SQL Database se ejecuta en el motor de base de datos de SQL Server estable más reciente del sistema operativo Windows, incluidas todas las revisiones aplicables.

SQL Database logra redundancia almacenando tres copias de los datos en un único centro de datos de la región primaria de forma predeterminada. Este enfoque protege los datos si se produce un error localizado, como un error de red a pequeña escala o un error de energía, y también durante los siguientes eventos:

• Operaciones de administración iniciadas por el cliente que dan lugar a un breve tiempo de inactividad.

• Operaciones de mantenimiento de servicio

• Problemas y interrupciones del centro de datos, donde el centro de datos tiene los siguientes componentes:

  • Bastidores, donde se ejecutan las máquinas que impulsan el servicio

  • Máquinas físicas que hospedan la máquina virtual (VM) que ejecuta el motor de SQL Database

• Otros problemas con el motor de SQL Database

• Otras posibles interrupciones localizadas no planeadas

SQL Database usa Azure Service Fabric para administrar la replicación de la base de datos.

La redundancia se implementa de maneras diferentes para distintos niveles de servicio de SQL Database. Para obtener más información, consulte Disponibilidad mediante redundancia: SQL Database.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

SQL Database controla automáticamente las tareas de mantenimiento críticas, como la aplicación de revisiones, las copias de seguridad, Windows y las actualizaciones del motor de SQL Database. También controla automáticamente eventos no planeados, como errores de red, software o hardware subyacentes. SQL Database está diseñado para recuperarse rápidamente de errores críticos, lo que garantiza que los datos estén siempre disponibles. La mayoría de los usuarios no observan que las actualizaciones se realizan continuamente.

Cuando una base de datos se revisa o transfiere, el tiempo de inactividad no es disruptivo si emplea lógica de reintento en su aplicación.

Puede probar la resistencia de la aplicación a errores transitorios siguiendo las instrucciones de Prueba de resistencia de errores de la aplicación.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Para ver información sobre la compatibilidad de zona de disponibilidad con otros niveles de servicio, asegúrese de seleccionar el nivel de servicio adecuado al principio de esta página.

Requisitos

Resistencia a errores en toda la región

En esta sección se proporciona información general sobre dos características relacionadas pero independientes que se pueden usar para la replicación geográfica en varias regiones de SQL Database:

• La replicación geográfica activa replica una base de datos única en una base de datos secundaria sincronizada.

• Los grupos de conmutación por error se basan en la replicación geográfica activa y permiten realizar una conmutación por error de un grupo de bases de datos.

Replicación geográfica activa

La replicación geográfica activa crea una base de datos secundaria legible sincronizada continuamente (que a veces se conoce como réplica geográfica secundaria o geográfica) en cualquier región para una base de datos principal única. La replicación geográfica activa puede crear bases de datos secundarias en la misma región, pero esta configuración no proporciona protección contra una interrupción de la región. Al usar la replicación geográfica activa para lograr redundancia geográfica, busque la base de datos secundaria en una región diferente a la base de datos principal.

Requisitos

Al usar la replicación geográfica activa, tenga en cuenta los siguientes requisitos:

• Compatibilidad con regiones: la replicación geográfica activa se puede habilitar en todas las regiones de Azure y no requiere que use pares de regiones de Azure.

  Sugerencia

  SQL Database sigue una práctica de implementación segura en la que Azure se esfuerza por no implementar actualizaciones en regiones emparejadas al mismo tiempo. Si configura la replicación geográfica activa para usar regiones no emparejadas, establezca diferentes ventanas de mantenimiento para los servidores de cada región. Este enfoque ayuda a reducir la posibilidad de que ambas regiones experimenten problemas de conectividad causados por el mantenimiento al mismo tiempo.

• Configuración: Tanto el principal como el secundario geográfico deben tener el mismo nivel de servicio y deben tener el mismo nivel de proceso, tamaño de proceso y redundancia de almacenamiento de copia de seguridad.

• Firewall: Tanto el servidor principal como el secundario geográfico deben tener las mismas reglas de firewall de direcciones IP.

• Suscripciones de Azure: La replicación geográfica activa es compatible con bases de datos en distintas suscripciones de Azure.

Consideraciones

• La replicación geográfica activa está diseñada para proporcionar conmutación por error de una única base de datos. Si necesita conmutar por error varias bases de datos, considere la posibilidad de usar en su lugar grupos de conmutación por error.

• Dado que la replicación geográfica es asincrónica, la pérdida de datos es posible cuando se produce una conmutación por error. Si necesita eliminar la pérdida de datos de la replicación asincrónica durante los fallos, configure la aplicación para bloquear el subproceso de llamada hasta que se transmita y endurezca la última transacción confirmada en el registro de transacciones de la base de datos secundaria. Este enfoque requiere desarrollo personalizado y reduce el rendimiento de la aplicación. Para obtener más información, consulte Evitar la pérdida de datos críticos.

• Para más información sobre las limitaciones y consideraciones, consulte Replicación geográfica activa.

Cost

Las bases de datos secundarias se facturan como bases de datos independientes.

Configuración de la compatibilidad con varias regiones

• Habilite la replicación geográfica activa: Para más información sobre cómo habilitar la replicación geográfica activa en Azure Portal, consulte Configuración de la replicación geográfica activa para SQL Database o Replicación geográfica activa.

  Después de habilitar la replicación geográfica activa, un paso de propagación inicial puede tardar algún tiempo.

• Deshabilitar la replicación geográfica activa: Para obtener más información sobre cómo deshabilitar la replicación geográfica activa en una base de datos, consulte Eliminación de la base de datos secundaria.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando una base de datos está configurada para usar la replicación geográfica activa y todas las regiones están operativas.

• Enrutamiento del tráfico entre regiones: La aplicación debe configurarse para enviar solicitudes de lectura y escritura a la base de datos principal. Opcionalmente, puede enviar solicitudes de solo lectura a una base de datos secundaria, lo que ayuda a reducir el impacto de las cargas de trabajo de solo lectura en la base de datos principal.

• Replicación de datos entre regiones: La replicación entre las bases de datos principal y secundaria se produce de forma asincrónica, lo que significa que puede haber un retraso entre el momento en que se aplica un cambio a la base de datos principal y cuando se replica en la base de datos secundaria.

  Al realizar una conmutación por error, decide cómo gestionar el riesgo de pérdida de datos.

Comportamiento durante una falla de región

En esta sección se describe qué esperar cuando una base de datos está configurada para usar la replicación geográfica activa y hay una interrupción en la región primaria:

• Detección y respuesta: usted es responsable de detectar la interrupción de una base de datos o región y de desencadenar la conmutación por error.

• Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: Las solicitudes activas durante la conmutación por error se finalizan y se deben reintentar.

• Pérdida de datos esperada: si la base de datos principal está disponible, opcionalmente puede realizar una conmutación por error sin pérdida de datos. El proceso de conmutación por error sincroniza los datos entre las bases de datos principal y secundaria antes de cambiar de roles.

  Si la base de datos principal no está disponible, es posible que tenga que realizar una conmutación por error forzada, lo que da lugar a la pérdida de datos. Puede calcular la cantidad de pérdida de datos mediante la supervisión del retraso de replicación. Para obtener más información, consulte Supervisión de SQL Database con métricas y alertas.

• Tiempo de inactividad esperado: Normalmente, hay hasta 60 segundos de tiempo de inactividad durante una conmutación por error. Asegúrese de que la aplicación controla los errores transitorios para que pueda recuperarse de breves períodos de tiempo de inactividad. Además, la rapidez con la que reconfigura la aplicación para conectarse a la nueva base de datos principal afecta al tiempo de inactividad que experimenta.

• Reenrutamiento del tráfico: Es responsable de volver a configurar la aplicación para enviar solicitudes a la nueva base de datos principal. Si necesita tener conmutación por error transparente, considere la posibilidad de usar grupos de conmutación por error.

Recuperación de regiones

Una vez recuperada la región primaria, puede realizar manualmente una conmutación por restablecimiento en la región primaria realizando otra conmutación por error.

Prueba de fallos de región

Puede simular una interrupción de región desencadenando una conmutación por error manual en cualquier momento. Puede desencadenar una conmutación por error (sin pérdida de datos) o una conmutación por error forzada.

Grupos de conmutación por error

Los grupos de conmutación por error se basan en la replicación geográfica activa. Con los grupos de conmutación por error, puede realizar las siguientes operaciones:

• Replique un conjunto de bases de datos desde un único servidor lógico en cualquier combinación de regiones de Azure.

• Realice la conmutación por error en las bases de datos como grupo.

• Use puntos de conexión que dirijan automáticamente las conexiones a la principal.

Requisitos

• Compatibilidad regional: Los grupos de conmutación de emergencia se pueden crear en todas las regiones de Azure y no es necesario utilizar pares de regiones de Azure.

  Sugerencia

  Si configura un grupo de conmutación por error con regiones no emparejadas, considere la posibilidad de establecer diferentes ventanas de mantenimiento para los servidores de cada región. Este enfoque ayuda a reducir la posibilidad de que ambas regiones experimenten problemas de conectividad causados por el mantenimiento al mismo tiempo.

• Configuración: Las bases de datos secundarias de un grupo de conmutación por error deben tener el mismo nivel de servicio, nivel de proceso, tamaño de proceso, reglas de firewall de direcciones IP y redundancia de almacenamiento de copia de seguridad que la base de datos principal.

Consideraciones

• Posible pérdida de datos: Dado que la replicación geográfica es asincrónica, es posible que se pierdan datos cuando se produce una conmutación por error. Si necesita eliminar la pérdida de datos de la replicación asincrónica durante las conmutaciones por error, puede configurar la aplicación para bloquear el subproceso de llamada hasta que la última transacción confirmada se ha transmitido y protegido en el registro de transacciones de la base de datos secundaria. Este enfoque requiere desarrollo personalizado y reduce el rendimiento de la aplicación. Para obtener más información, consulte Evitar la pérdida de datos críticos.

• Para obtener más información sobre las limitaciones y consideraciones, consulte Grupos de conmutación por error.

Cost

Las bases de datos secundarias se facturan como bases de datos independientes.

Configuración de la compatibilidad con varias regiones

• Habilite los grupos de conmutación por error: Usted configura un grupo de conmutación por error en un servidor lógico. Puede agregar todas las bases de datos del servidor lógico al grupo de conmutación por error, o bien puede seleccionar un subconjunto de bases de datos que se van a agregar.

  Al crear un grupo de conmutación por error, seleccione la directiva de conmutación por error, que especifica quién es responsable de detectar una interrupción y realizar una conmutación por error. Puede configurar la conmutación por error administrada por el cliente, que se recomienda, o bien la conmutación por error administrada por Microsoft.

  Importante

  Es probable que se produzca una conmutación por error automatizada iniciada por Microsoft después de un retraso significativo y se lleva a cabo de la mejor manera posible. La conmutación por error de las bases de datos puede producirse en un momento diferente a cualquier conmutación por error de otros servicios de Azure. Para obtener más información, consulte Configuración de un grupo de conmutación por error para SQL Database.

  Después de configurar el grupo de conmutación por error, el paso de inicialización puede tardar algún tiempo.

• Deshabilitar grupos de conmutación por error: Puede quitar una base de datos individual de un grupo de conmutación por error, quitar un grupo de conmutación por error completo o mover una base de datos a otro grupo de conmutación por error.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando una base de datos está configurada dentro de un grupo de conmutación por error y todas las regiones están operativas.

• Enrutamiento del tráfico entre regiones: En el caso de las cargas de trabajo de lectura y escritura y de solo lectura, los grupos de conmutación por error proporcionan dos puntos de conexión de escucha donde puede conectar sus aplicaciones. Utilice los puntos de conexión del escucha del grupo de conmutación para minimizar el tiempo de inactividad durante las conmutaciones. Durante las operaciones normales, se produce el siguiente comportamiento de enrutamiento:

  • El punto de conexión del escuchador de lectura y escritura enruta todas las solicitudes a las bases de datos primarias.

  • El punto de conexión de escucha de solo lectura enruta todas las solicitudes a una base de datos secundaria legible.

• Replicación de datos entre regiones: La replicación geográfica entre las bases de datos principal y secundaria se produce de forma asincrónica. Esta latencia significa que puede haber un retraso entre un cambio que se aplica a la base de datos principal y cuando se replica en la base de datos secundaria.

  Al realizar una conmutación por error, decide cómo gestionar el riesgo de pérdida de datos.

Comportamiento durante una falla de región

En esta sección se describe qué esperar cuando una base de datos está configurada dentro de un grupo de conmutación por error y hay una interrupción en la región primaria:

• La detección y la respuesta dependen de la política de conmutación por error que use.

  • Conmutación por error iniciada por el cliente: Es responsable de detectar la interrupción de una base de datos o región y de desencadenar la conmutación por error.

  • Conmutación por error iniciada por Microsoft: Microsoft desencadena la conmutación por error para todos los grupos de conmutación por error de la región afectada. Microsoft espera realizar este tipo de conmutación por error solo en situaciones excepcionales. No confíe en la conmutación por error administrada por Microsoft para la mayoría de las soluciones. Para obtener más información, consulte Directiva de conmutación por error: administrada por Microsoft.

• Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: Las solicitudes activas durante la conmutación por error se finalizan y se deben reintentar.

• Pérdida de datos esperada: La pérdida de datos depende de la directiva de conmutación por error que use.

  • Conmutación por error iniciada por el cliente: Si la base de datos principal está disponible, opcionalmente puede realizar una conmutación por error sin pérdida de datos. El proceso de conmutación por error sincroniza los datos entre las bases de datos principal y secundaria antes de cambiar de roles.

    Si la base de datos principal no está disponible, es posible que tenga que realizar una conmutación por error forzada, lo que da lugar a la pérdida de datos. Puede calcular la cantidad de pérdida de datos mediante la supervisión del retraso de replicación. Para obtener más información, consulte Supervisión de SQL Database con métricas y alertas.

  • Conmutación por error iniciada por Microsoft: Una conmutación por error administrada por Microsoft solo se desencadena en situaciones excepcionales. Las conmutaciones por error administradas por Microsoft son conmutaciones por error forzadas, lo que significa que se espera una pérdida de datos. No puede controlar la cantidad de pérdida de datos que puede experimentar.

• Tiempo de inactividad esperado: El tiempo de inactividad depende de la directiva de conmutación por error que use.

  • Conmutación por error iniciada por el cliente: Normalmente, hay hasta 60 segundos de tiempo de inactividad durante una conmutación por error. Asegúrese de que la aplicación controla los errores transitorios para que pueda recuperarse de breves períodos de tiempo de inactividad.

  • Conmutación por error iniciada por Microsoft: Puede especificar un período de gracia que determine cuánto tiempo debe esperar Microsoft antes de iniciar la conmutación por error. El período de gracia mínimo es una hora. Sin embargo, es probable que el tiempo de respuesta de Microsoft sea de varias horas al menos.

• Reenrutamiento del tráfico: durante la conmutación por error, SQL Database actualiza los puntos de conexión de escucha de lectura y escritura y de solo lectura para dirigir el tráfico a la nueva base de datos primaria y secundaria según sea necesario.

  Si la nueva base de datos secundaria (anteriormente la base de datos principal) no está disponible, el punto de conexión del agente de escucha de solo lectura no se puede conectar hasta que esté disponible la nueva base de datos secundaria.

Recuperación de regiones

Usted es responsable de restablecer la región primaria si es necesario. Puede realizar manualmente una conmutación por recuperación en la región primaria mediante la realización de una conmutación por error administrada por el cliente.

Incluso si Microsoft inició la conmutación por error original, usted sigue siendo responsable de la conmutación por recuperación a la región anterior, si elige hacerlo.

Prueba de fallos de región

Puede simular una interrupción de región desencadenando una conmutación por error manual en cualquier momento. Puede desencadenar una conmutación por error (sin pérdida de datos) o una conmutación por error forzada.

Copias de seguridad y restauración

Realice copias de seguridad de las bases de datos para protegerse frente a diversos riesgos, incluida la pérdida de datos. Las copias de seguridad se pueden restaurar para recuperarse de pérdida accidental de datos, daños u otros problemas. Las copias de seguridad difieren de la redundancia de zona, la replicación geográfica activa o los grupos de conmutación por error, y tienen diferentes propósitos. Para obtener más información, consulte Redundancia, replicación y copia de seguridad.

SQL Database proporciona copias de seguridad automáticas de las bases de datos. Para obtener más información sobre la frecuencia de copia de seguridad, que puede afectar a la cantidad de pérdida de datos si necesita restaurar desde una copia de seguridad, consulte Copias de seguridad automatizadas en SQL Database.

Almacenamiento de copia de seguridad

Puede elegir almacenar las copias de seguridad automatizadas en LRS o ZRS. Si usa una región emparejada, puede optar por replicar las copias de seguridad automatizadas en la región emparejada mediante el almacenamiento con redundancia geográfica. Esta funcionalidad permite la restauración geográfica de las copias de seguridad en la región emparejada. Para obtener más información, consulte Copias de seguridad automatizadas en SQL Database.

Si usa una región no emparejada o si necesita replicar copias de seguridad en una región distinta de la región emparejada, considere la posibilidad de exportar la base de datos y almacenar el archivo exportado en una cuenta de almacenamiento que use la replicación de objetos de blob para replicar en una cuenta de almacenamiento de otra región. Para obtener más información, consulte Exportación de una base de datos.

Resistencia al mantenimiento del servicio

Cuando SQL Database realiza el mantenimiento en sus bases de datos y grupos elásticos, puede conmutar por error automáticamente la base de datos para usar una réplica secundaria. Las aplicaciones cliente pueden observar breves interrupciones de conectividad cuando se produce una conmutación por error. Las aplicaciones cliente deben seguir las instrucciones de resistencia a errores transitorios para minimizar los efectos.

SQL Database permite especificar una ventana de mantenimiento que se usa normalmente para las actualizaciones de servicio y otras operaciones de mantenimiento. La configuración de una ventana de mantenimiento puede ayudarle a minimizar los efectos secundarios, como las conmutaciones por error automáticas, durante el horario comercial. También puede recibir notificaciones anticipadas del mantenimiento planeado.

La plataforma mantiene automáticamente las puertas de enlace usadas para procesar las conexiones a SQL Database. Las actualizaciones o las operaciones de mantenimiento también pueden provocar interrupciones breves de conectividad que los clientes pueden reintentar.

Para obtener más información, vea Ventana de mantenimiento en SQL Database.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

El acuerdo de nivel de servicio (SLA) para SQL Database describe la disponibilidad esperada del servicio y el punto de recuperación esperado y el tiempo de recuperación para la replicación geográfica activa.

Al implementar una base de datos con redundancia de zona o un grupo elástico y usar un nivel de servicio compatible, el SLA de tiempo de actividad es mayor.

Contenido relacionado

• Introducción a la continuidad empresarial con SQL Database
• Lista de comprobación de alta disponibilidad y recuperación ante desastres: SQL Database
• Confiabilidad en Azure