Compartir a través de

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

  • Artículo

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:

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á 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 podría 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.
    • 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 servidor, y la base de datos es la principal actual.
    • 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 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 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.
  • 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 la replicación geográfica activa, los grupos de conmutación por error o la restauración geográfica, debe 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 un 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 una región emparejada a la principal 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 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) las reglas de firewall que los usuarios necesitan para acceder a 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 en el servidor principal actual y haga que sea idéntica en el servidor secundario.

Contenido relacionado