Replica geográfica de SQL Database Azure

Uno de los principales factores para los sistemas de misión crítica y de alta disponibilidad para asegurar la continuidad operativa es la disponibilidad de la base de datos.

Si bien, en forma interna, Azure realiza distintas instancias de cada base de datos que instanciamos de SQL Database, dichas copias existen para asegurar la operación por parte de Azure.

Con la replica geográfica permite configurar hasta cuatro bases de datos secundarias legibles en las mismas ubicaciones de centros de datos o en otras (regiones). Las bases de datos secundarias están disponibles en caso de una interrupción del centro de datos o de imposibilidad para conectarse a la base de datos principal.

Si, por cualquier motivo, se produce un error en la base de datos principal o, simplemente, debe desconectarse, puede conmutar a cualquiera de las bases secundarias. Cuando se activa la conmutación, las demás bases de datos secundarias se vinculan automáticamente a la nueva base de datos principal.

La Replicación geográfica implementa un mecanismo para proporcionar redundancia de base de datos en la misma región de Microsoft Azure o en distintas regiones. Esta funcionalidad replica de forma asincrónica las transacciones confirmadas desde una base de datos en hasta cuatro copias de la base de datos en servidores diferentes.

Cuando se configura la replicación geográfica, se crea una base de datos secundaria en el servidor especificado y la base de datos original se convierte en la principal. La base de datos principal replica de forma asincrónica las transacciones confirmadas en cada una de las bases de datos secundarias. Aunque, en un momento dado, la base de datos secundaria puede estar algo retrasada respecto a la principal, se garantiza que los datos secundarios guarden siempre coherencia transaccional con los confirmados en la base de datos principal.

Una de las principales ventajas de la replicación geográfica es que ofrece una solución de recuperación ante desastres en el nivel de base de datos con un tiempo de recuperación muy reducido.

La redundancia entre regiones permite que las aplicaciones se recuperen de la pérdida permanente de todo un centro de datos, o de partes de él, causada por desastres naturales, errores humanos catastróficos o actos malintencionados. En la siguiente ilustración, se muestra un ejemplo de replicación geográfica configurada en una base de datos Premium con una principal en la región centro-norte de EE. UU. y una secundaria en la región centro-sur de EE. UU.

geo-replication-relationship

Una muy buena ventaja de la utilización de bases de datos secundarios es la posibilidad de reducir la carga de la aplicación para los procesos que solo requieren lectura y que muchas veces alteran la performance, como la generación de reportes. Si la replica se la crea con este fin se la puede crear en la misma región que la principal, pero en dicho caso no sería útil como DRP.

Debido a la elevada latencia de las redes de área extensa, la copia usa un mecanismo de replicación asincrónica. Esto hace inevitable cierta pérdida de datos si se produce un error. Sin embargo, es posible que algunas aplicaciones requieran que no se pierdan datos. Para proteger estas actualizaciones críticas, podemos llamar al stored procedure 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 replica la última transacción confirmada en la base de datos secundaria. El procedimiento esperará hasta que la base de datos secundaria confirme todas las transacciones en cola.

Automatización de Backups SQL Database Windows Azure

Anteriormente publiqué en mi blog una solución para realizar backups automatizados de SQL Database. Actualmente Windows Azure cuenta con la configuración necesaria para realizar esta actividad sin la necesidad de publicar componentes adicionales a nuestra solución.

Para configurar esto debemos seguir los siguientes pasos.

  • Seleccionar la base de datos que deseamos automatizar el backup en el portal de Windows Azure.

image

  • Seleccionamos la solapa de Configuración

image

  • Habilitamos la exportación automática

image

  • Especificamos la cuenta de storage donde se almacenarán los backups y determinamos la periodicidad de los mismos. Si seleccionamos una periodicidad menor a los 7 días nos indicará que puede afectar a la performance.

image

  • Configuramos la cantidad de tiempo que permanezca cada backup en storage

image

  • Por último se ingresan las credenciales de la base de datos y se guardan los cabios de la configuración

image

Una vez que la tarea de backup sea ejecutada podremos revisar el archivo almacenado en storage.

backup

Como pueden ver, en forma automática ha creado un container de blobs denominado automated-sql-export en el cual vamos a encontrar cada uno de los archivos de backup. La nomenclatura del archivo es [server]-[nombre-base-datos]-[FECHA].bacpac. Por tal motivo la misma cuenta de storage puede ser utilizada para almacenar los backups de distintas bases de datos.

Para restablecer una base de datos a partir de un backup generado utilizando este mecanismo podemos ir nuevamente la solapa de configuración donde encontraremos una opción para este fin.

image

image

Seleccionamos el Backup, el nombre de la base de datos y el servidor donde la queremos, permitiendo incluso crear uno nuevo

image

Una vez configurada la restauración y finalizada la ejecución podemos revisar la base de datos creada.

image

image