Hola amig@s:
En el artículo anterior vimos una introducción al servicio de sincronización de datos de SQL Azure Data Sync, en esta oportunidad vamos a ver el primer escenario de sincronización de datos entre bases de datos de SQL Server On-Premise (locales) y base de datos de Windows Azure SQL Database (Anteriormente conocido como SQL Azure). Ver Fig. 1.
Fig. 1 – Escenario de sincronización de base de datos de SQL Server On-Premise y base de datos de Windows Azure SQL Database.
Ahora describiré con un ejemplo práctico como realizar una sincronización de datos entre ambas plataformas: SQL Server On-Premise (SSOP) y Windows Azure SQL Database (WASD). Ver Fig. 2.
Fig. 2 – Escenario de Sincronización SSOP y WASD.
Escenario
En SSOP tenemos una base de datos llamada BDotNet_On-Premise en una instancia de SQL Server 2012 que se encuentra instalada en el equipo local.
En WASD tenemos una base de datos llamada BDotNet_Cloud con la misma estructura.
En ambas bases de datos se tiene una tabla llamada Miembros, la única diferencia entre estas bases de datos es que la tabla Miembros de la base de datos de WASD tiene información (24 registros) y la base de datos de SSOP no contiene registros. Ver Fig. 3.
Fig. 3 – Estructura de la base de datos tanto en WASD y SSOP.
Para iniciar el proceso de sincronización seleccionamos la opción de Data Sync del portal de Windows Azure. Ver Fig. 4.
Fig. 4 – Opción de Data Sync dentro del portal de Windows Azure.
Posteriormente seleccionamos la suscripción y el servidor donde vamos a realizar este proceso, por lo tanto se habilita la opción de “Sincronización entre bases de datos de SSOP y WASD”, para continuar damos clic en el icono mostrado en la Figura 5.
Fig. 5 – Opción de Sincronización entre bases de datos de SSOP y WASD en el módulo de Data Sync.
Cuando iniciamos el proceso de sincronización debemos crear un grupo de sincronización donde especificamos la suscripción y el servidor donde deseamos crear este grupo. Ver Fig. 6.
Fig. 6 – Popup con la opción de crear el grupo de sincronización.
Para realizar esta tarea debemos completar 6 pasos. El primer paso es especificar un nombre al grupo de sincronización. Ver Fig. 7.
Fig. 7 – Popup donde especificamos el nombre del grupo de sincronización.
En el segundo paso debemos agregar una nueva base de datos de SSOP al grupo de sincronización. Ver Fig. 8.
Fig. 8 – Popup donde agregamos una base de datos de SSOP.
Siendo esta la primera sincronización que estamos realizando seleccionamos la opción de agregar una nueva base de datos de SSOP al grupo de sincronización. Ver Fig. 9.
En la opción de dirección de sincronización, Data Sync admite tres tipos de sincronización:
-
Bidireccional: permite que los cambios se sincronicen entre la base de datos seleccionada y la base de datos concentrador en las dos direcciones.
-
Sincronizar desde el concentrador: permite que los cambios se sincronicen desde la base de datos concentrador hacia la base de datos seleccionada en una sola dirección.
-
Sincronizar hacia el concentrador: permite que los cambios se sincronicen desde la base de datos seleccionada hacia la base de datos del concentrador en una sola dirección.
Fig. 9 – Popup donde agregamos una base de datos al grupo de sincronización y su dirección de sincronización.
Para registrar la base de datos de SSOP debemos instalar un agente de sincronización que es una aplicación cliente que ejecutamos en la máquina local, si ya la tenemos instalada y configurada simplemente seleccionamos la opción “Mediante un agente existente”. Ver Fig. 10.
Fig. 10 – Popup donde seleccionamos un agente o instalamos uno nuevo.
Para nuestro ejemplo vamos a instalar el agente de sincronización, lo primero que debemos hacer es descargar y posteriormente instalar el agente de sincronización en nuestro equipo local, especificamos un nombre y por ultimo generamos una clave de agente. Ver Fig. 11.
Fig. 11 – Popup de instalación y configuración del agente de sincronización.
Copiamos la clave de agente que se generó a través del portal de Windows Azure, ejecutamos en nuestro equipo local la aplicación cliente del agente de sincronización, seleccionamos la opción de “Submit Agent Key Configuration” y enseguida pegamos la clave del agente que se generó, que será validada contra el portal de Windows Azure. Ver Fig. 12 y Fig. 13.
Fig. 12 – Aplicación cliente del agente de sincronización.
Fig. 13 – Ventana donde pegamos la clave del agente que se generó en el portal de Windows Azure.
Una vez validada la clave de agente por el portal de Windows Azure, lo siguiente que debemos hacer es registrar la base de datos de SSOP, en este caso una base de datos que tenemos en una instancia de SQL Server 2012. Ver Fig. 14.
Fig. 14 – Opción registrar en la aplicación cliente del agente de sincronización.
Configuramos la conexión al servidor de SQL Server 2012, podemos realizarlo con autenticación Windows o autenticación SQL, en este caso lo haremos con autenticación SQL donde especificamos el nombre del servidor de SQL Server, la base de datos que queremos registrar en este caso BDotNet_On-Premise, el login y el password. Realizamos el test de conexión para verificar que los datos de configuración son correctos. Ver Fig. 15 y Fig. 16.
Fig. 15 – Ventana de conexión al servidor de SSOP.
Fig. 16 – Test de conexión al servidor de SSOP.
Si la conexión es exitosa, damos clic en guardar y con esto ya registramos la base de datos al agente de sincronización. Ver Fig. 17.
Fig. 17 – Aplicación cliente del agente de sincronización con la base de datos de SSOP registrada.
Regresamos nuevamente al portal de Windows Azure para finalizar la adición de la base de datos de SSOP al grupo de sincronización. Una vez configurado el agente de sincronización obtenemos las bases de datos on-premises registradas y seleccionamos la base de datos con la que queremos trabajar en este caso BDotNet_On-Premise y finalizamos este paso. Ver Fig. 18.
Fig. 18 – Popup donde seleccionamos la base de datos de SSOP.
En el tercer paso agregamos la base de datos de WASD. Ver Fig. 19.
Fig. 19 – Popup donde agregamos una base de datos de WASD.
SQL Data Sync usa una topología en estrella de tipo hub-and-spoke. Donde el concentrador es la base de datos central de un grupo de sincronización y debe ser una base de datos SQL de Windows Azure. Es recomendable que el concentrador esté:
-
En el mismo data center (cuando las bases de datos no están distribuidas geográficamente) o,
-
En la ubicación más centralizada respecto a las demás bases de datos. Los dos factores más importantes para seleccionar una base de datos central son latencia y costo.
La elección de una base de datos central cercana a la mayor parte del tráfico de datos minimiza la latencia y el costo.
Una vez establecido, el concentrador no se puede cambiar a otra base de datos ni quitar. Los cambios de datos en las bases de datos miembro se escriben en la base de datos central o se descartan de acuerdo con la directiva de resolución de conflictos. Una vez que todas las bases de datos miembro han enviado sus cambios al concentrador, este escribe los cambios en todas las bases de datos miembro.
Ahora configuramos la conexión con el servidor de base de datos de Windows Azure donde especificamos el nombre del servidor, la base de datos con la que queremos trabajar, el login y la contraseña. Realizamos el test de conexión y si es esta es correcta damos clic en agregar. Ver Fig. 20.
Fig. 20 – Popup de conexión al servidor de WASD.
En el cuarto paso definimos la programación de la sincronización y la resolución de conflictos.
La programación define la periodicidad con que se ejecutan las sincronizaciones programadas, donde podemos especificarla en minutos, horas, días y en meses. La sincronización se ejecuta solo entre las bases de datos del grupo de sincronización asociado. Ver Fig. 21.
La directiva determina qué datos se conservan y qué datos se pierden cuando se cambia el mismo registro en distintas bases de datos.
-
Prioridad del concentrador: Si se produce un cambio en el registro del concentrador, se conservará siempre y se perderá un cambio de datos en el miembro. El primer cambio escrito en el concentrador se mantiene durante toda la sincronización.
-
Prioridad del cliente: Si se produce un cambio en el registro del miembro, se escribe en el concentrador. Si el registro se cambia en varios miembros, el cambio del último miembro se escribe en el concentrador y se propaga a todos los miembros.
Nota: una vez que se establece la directiva de resolución de conflictos para el grupo de sincronización para cambiarla posteriormente es necesario volver a crear el grupo.
Fig. 21 – Popup de configuración de la programación y la resolución de conflictos.
En el quinto paso seleccionamos las tablas, columnas y filas concretas (filtrando por un valor específico) que se utilizarán en la sincronización con este grupo de sincronización. Cuando se realiza una sincronización, solo se sincronizan las tablas, columnas y filas seleccionadas. Ver Fig. 22.
Por ejemplo, se puede seleccionar la tabla Miembros y las columnas ID, Nombre, Especialidad y filtrar por la Especialidad donde sea igual a SQL Server, de forma que solo se sincronicen los miembros que tengan como Especialidad SQL Server.
Fig. 22 – Popup donde iniciamos la definición de los datos.
El conjunto de datos de sincronización puede modificarse después de crear el grupo de sincronización. Se pueden agregar y quitar tablas y columnas después del aprovisionamiento inicial, pero no se pueden agregar ni quitar columnas filtradas.
En nuestro ejemplo seleccionamos la tabla miembros y todos sus campos (ID, Nombre, Especialidad, Twitter, Rol) y damos clic en aceptar. Ver Fig 23.
Fig. 23 – Popup donde se seleccionan las tablas, columnas y los filtros para la sincronización.
En el sexto y último paso seleccionamos la opción de implementar y con esto aseguramos que toda la configuración del grupo de sincronización quede guardada. Ver Fig. 24.
Fig. 24 – Opción de implementar en el ribbon del portal de Windows Azure.
Una vez guardados los cambios del grupo de sincronización y las bases de datos miembros, veremos en el portal de Windows Azure un resumen de como ha quedado configurado nuestro proceso de sincronización. Ver Fig. 25.
Fig. 25 – Resumen de la configuración del grupo de sincronización.
Para realizar una prueba simplemente seleccionamos la opción de “Sincronizar ahora” e inmediatamente inicia el proceso de sincronización de datos con las bases de datos miembro que registramos y configuramos. Ver Fig. 26.
Fig. 26 – Opción de “Sincronizar ahora” en el ribbon del portal de Windows Azure.
En el mapa de sincronización que muestra el portal de Windows Azure nos indica que estuvo correcta la sincronización entre las bases de datos. Ver Fig 27.
Fig. 27 – Mapa de sincronización.
Verificamos que realmente haya sincronizado los datos de la base de datos de WASD a la base de datos de SSOP. Ver Fig 28.
1: -- Database BDotNet_On-Premise
2:
3: USE [BDotNet_On-Premise];
4: SELECT Count (*) FROM Miembros;
5: SELECT ID, Nombre, Especialidad, Twitter, Rol FROM Miembros;
Fig. 28 – Consulta de la tabla Miembros de la base de datos de SSOP.
Cuando iniciamos el proceso de sincronización de datos, SQL Azure Data Sync crea unas tablas de trabajo en las bases de datos involucradas en el proceso. Ver Fig. 29.
Fig. 29 – Tablas de trabajo creadas por el proceso de sincronización.
En panel de servidor de SQL Azure Data Sync y en el visor de registros podemos monitorear lo que sucede con la sincronización, si tenemos advertencias, errores o si el proceso fue exitoso. Ver Fig. 30 y Fig. 31.
Fig. 30 – Panel de servidor de SQL Data Sync.
Fig. 31 – Visor de registros.
También podemos verificar la información del agente de Sincronización (BDotNet_Agent) y de cada una de las bases de datos miembro que sincronizamos (BDotNet_Cloud y BDotNet_On-Premise). Ver Fig. 32, Fig. 33 y Fig. 34)
Fig. 32 – Información del agente de sincronización
Fig. 33 – Información de la base de datos de WASD.
Fig. 34 – Información de la base de datos de SSOP.
Espero que la información brindada sea de utilidad.
Saludos,
Compartir:
Spanish 
English 