Replicación de Datos en SQL
Server
- Resumen
- Componentes del modelo de
replicación - Escenarios típicos de la
replicación - Tipos de
replicación - Factores para elegir el
método de replicación a
utilizar - Fases generales para implementar
y supervisar la replicación - Consideraciones
finales - Referencias
Bibliográficas
La replicación de datos consiste en
el transporte de
datos entre dos o más servidores,
permitiendo que ciertos datos de la base de datos
estén almacenados en más de un sitio, y así
aumentar la disponibilidad de los datos y mejorar el rendimiento
de las consultas globales. El modelo de
replicación está formado por: publicador,
distribuidor, suscriptor, publicación, artículo y
suscripción; y varios agentes responsabilizados de copiar
los datos entre el publicador y el suscriptor. A los tipos
básicos de replicación (de instantáneas,
transaccional y de mezcla), se le incorporan opciones para
ajustarse aún más a los requerimientos del
usuario.
La replicación de datos permite que ciertos datos
de la base de datos
sean almacenados en más de un sitio, y su principal
utilidad es
que permite aumentar la disponibilidad de los datos y mejora el
funcionamiento de las consultas globales a la base de datos.
[Elm00]
La replicación en SQL Server
consiste, en el transporte de
datos entre dos o más instancias de servidores. Para
ello SQL Server
brinda un conjunto de soluciones que
permite copiar, distribuir y posiblemente modificar datos de toda
la
organización. Se incluyen, además, varios
métodos y
opciones para el diseño,
implementación, supervisión y administración de la replicación,
que le ofrecen la funcionalidad y flexibilidad necesarias para
distribuir datos y mantener su coherencia [Mic01].
En la replicación se utiliza una metáfora
de la industria de
la publicación para representar los componentes y procesos de
una topología de replicación. De esta
forma el modelo se
compone, básicamente, de los siguientes elementos:
publicador, distribuidor, suscriptores, publicaciones,
artículos y suscripciones [Mic01].
2. Componentes del modelo de
replicación
Para representar los componentes y procesos de
una topología de replicación se utilizan
metáforas de la industria de
la publicación. El modelo se compone de los siguientes
objetos: el publicador, el distribuidor, el suscriptor, la
publicación, el artículo y la suscripción;
así como de varios agentes, que son los procesos
responsabilizados de copiar los datos entre el publicador y el
suscriptor. Estos agentes son: agente de instantáneas,
agente de distribución, agente del lector del
registro,
agente del lector de cola y agente de mezcla [Mic01].
La replicación de datos es un asunto
exclusivamente entre servidores de datos, en nuestro caso
hablamos de servidores SQL Server.
Los servidores SQL Server pueden desempeñar uno o varios
de los siguientes roles: publicador, distribuidor o
suscriptor.
El publicador es un servidor que pone
los datos a disposición de otros servidores para poder
replicarlos. El distribuidor es un servidor que
aloja la base de datos de distribución y almacena los datos
históricos, transacciones y metadatos. Los
suscriptores reciben los datos replicados.
Una publicación es
un conjunto de artículos (este concepto:
"artículo de una publicación", es diferente del
concepto
"artículo o registro de una
base de datos", como explicaremos más adelante) de una
base de datos. Esta agrupación de varios artículos
facilita especificar un conjunto de datos relacionados
lógicamente y los objetos de bases de datos
que desea replicar conjuntamente. Un artículo de una
publicación puede ser una tabla de datos la cual puede
contar con todas las filas o algunas (filtrado horizontal) y
simultaneamente contar de todas las columnas o algunas (filtrado
vertical), un procedimiento
almacenado, una definición de vista, la ejecución
de un procedimiento
almacenado, una vista, una vista indizada o una función
definida por el usuario.
Una suscripción es una petición de
copia de datos o de objetos de base de datos para replicar. Una
suscripción define qué publicación se
recibirá, dónde y cuándo. Las suscripciones
pueden ser de inserción o de extracción; y una
publicación puede admitir una combinación de
suscripciones de inserción y extracción. El
publicador (en las suscripciones de inserción) o el
suscriptor (en las suscripciones de extracción) solicita
la sincronización o distribución de datos de una
suscripción.
El publicador puede disponer de una o más
publicaciones, de las cuales los suscriptores se suscriben a las
publicaciones que necesitan, nunca a artículos
individuales de una publicación. El publicador,
además, detecta qué datos han cambiado durante la
replicación transaccional y mantiene información acerca de todas las
publicaciones del sitio.
La función
del distribuidor varía según la metodología de replicación
implementada. En ocasiones se configura como distribuidor el
mismo publicador y se le denomina distribuidor local. En el resto
de los casos el distribuidor será remoto, pudiendo
coincidir en algún caso con un suscriptor.
Los suscriptores además de obtener sus
suscripciones, en dependencia del tipo y opciones de
replicación elegidas, puede devolver datos modificados al
publicador. Además puede tener sus propias publicaciones
[Mic01].
3. Escenarios típicos de la
replicación
En una solución de replicación pudiera ser
necesario utilizar varias publicaciones en una combinación
de metodologías y opciones. En la replicación los
datos o transacciones fluyen del publicador al suscriptor pasando
por el distribuidor.
Por lo tanto en su configuración mínima
una topología de replicación se compone de al menos
dos o tres servidores SQL Server que desempeñan los tres
roles mencionados.
Variando la ubicación del servidor distribuidor
podríamos contar con las siguientes variantes:
- El rol de distribuidor desempeñado por el
publicador (Fig. 1.1). - El rol de distribuidor desempeñado por el
suscriptor (Fig. 1.2) - Un servidor de distribución, independiente del
publicador y del suscriptor (Fig. 1.3)
Fig.1 Publicador-Distribuidor Fig.2
Distribuidor-Suscriptor Fig. 3 Distribuidor
independiente
En la mayoría de las configuraciones, el peso
fundamental de la replicación recae, sobre el servidor de
distribución. Por tanto éste puede ser un criterio
para determinar su ubicación, teniendo en cuenta las
configuraciones (posibilidades físicas) de los servidores,
así como otras responsabilidades que pueden estar
desempeñando (servidor de dominio, servidor
de páginas
web entre otras) [Mic01].
Existe
la posibilidad de contar con un servidor que se suscriba a una
publicación y a la vez la publique para el resto de los
suscriptores, esto puede ser muy útil cuando se cuente con
una conexión muy costosa con el publicador principal. Por
ejemplo el publicador principal en Madrid y los suscriptores en
Ciudad Habana, Varadero, Cayo Coco, Cayo Largo, etc. En casos
como este, se puede elegir un suscriptor, digamos el servidor de
Ciudad Habana el cual se suscribe al publicador en Madrid y a la
vez actúa como servidor de publicación para los
servidores de Varadero, Cayo Coco, Cayo Largo y demás.
Evidentemente en una configuración tal pueden nuevamente
combinarse la ubicación de los dos distribuidores y
aumentar el número de variantes que pueden presentarse
pero las consideraciones para determinar la ubicación del
servidor que fungirá como distribuidor son las ya
mencionadas.
Los tipos básicos de replicación
son:
- replicación de instantáneas
- replicación transaccional
- replicación de mezcla
Para ajustarse aún más a los
requerimientos de los usuarios se incorporan opciones como son la
actualización inmediata en el suscriptor, la
actualización en cola y la transformación de datos
replicados [Mic01].
3.1
Replicación de instantáneas
En la replicación de instantáneas los
datos se copian tal y como aparecen exactamente en un momento
determinado. Por consiguiente, no requiere un control continuo
de los cambios. Las publicaciones de instantáneas se
suelen replicar con menos frecuencia que otros tipos de
publicaciones. Puede llevar más tiempo propagar
las modificaciones de datos a los suscriptores. Se recomienda
utilizar: cuando la mayoría de los datos no cambian con
frecuencia; se replican pequeñas cantidades de datos; los
sitios con frecuencia están desconectados y es aceptable
un periodo de latencia largo (la cantidad de tiempo que
transcurre entre la actualización de los datos en un sitio
y en otro). En ocasiones se hace necesario utilizarla cuando
están involucrados algunos tipos de datos
(text, ntext, e image) cuyas modificaciones no se registran en el
registro de transacciones y por tanto no se pueden replicar
utilizando la metodología de replicación
transaccional.
Los servidores OLAP son candidatos a la
replicación de instantáneas. Las consultas ad-hoc
que aplican los administradores de sistemas de
información son generalmente de solo lectura y los
datos con antigüedad de horas o días no afectan sus
consultas. Por ejemplo un departamento desea hacer una investigación sobre demografía de los artículos vendidos
hace dos meses. La información de la semana pasada no
afectará sus consultas; además el departamento no
está planeando hacer cambio en los
datos, solo necesita el almacén de
datos. Hay que destacar además que cuando están
involucrados algunos tipos de datos
(text, ntext, e image) cuyas modificaciones no se registran en el
registro de transacciones [Mic01] y por lo tanto es necesario
transportar estos datos del publicador al suscriptor para lo cual
es necesario utilizar la replicación de
instantáneas, al menos como una solución
parcial.
Con la opción de actualización inmediata
en el suscriptor se permite a los suscriptores actualizar datos
solamente si el publicador los va a aceptar inmediatamente. Si el
publicador los acepta, se propagan a otros suscriptores. El
suscriptor debe estar conectado de forma estable y continua al
publicador para poder realizar
cambios en el suscriptor. Esta opción es útil en
escenarios en los que tienen lugar unas cuantas modificaciones
ocasionales en los servidores suscriptor.
En este caso se propaga una instantánea inicial
de datos a los suscriptores, y después, cuando se
efectúan las modificaciones en el publicador, las
transacciones individuales se propagan a los suscriptores. SQL
Server 2000 almacena las transacciones que afectan a los objetos
replicados y propaga esos cambios a los suscriptores de forma
continua o a intervalos programados. Al finalizar la
propagación de los cambios, todos los suscriptores
tendrán los mismos valores que el
publicador. Suele utilizarse cuando: se desea que las
modificaciones de datos se propaguen a los suscriptores,
normalmente pocos segundos después de producirse; se
necesita que las transacciones sean atómicas, que se
apliquen todas o ninguna al suscriptor; los suscriptores se
conectan en su mayoría al publicador; su aplicación
no puede permitir un periodo de latencia largo para los
suscriptores que reciban cambios.
Es útil en escenarios en los que los suscriptores
pueden tratar a sus datos como de sólo lectura, pere
necesitan cambios a los datos con una cantidad mínima de
latencia. Ejemplo: un sistema para el
procesamiento y distribución de pedidos. En este tipo de
escenario, podría tener varios publicadores recibiendo
pedidos de mercancías. Estos pedidos se replican entonces
a un almacén
central donde se despachan los pedidos. El almacén puede
tratar los datos como de sólo lectura y requiere nueva
información en forma periódica.
Con el uso de la opción de atualización
inmediata en el suscriptor se pierde aún más la
autonomía de sitio, pero se reduce el tiempo en el cual
los sitios actualizan sus copias de los datos. Para hacer
modificaciones en la base de datos del suscriptor éstas se
realizan (o intentan) también en la base de datos
publicador en una confirmación de dos fases (2PC) por lo
que si su modificación se confirma indica que es
válida y luego en cuestión de minutos, o
según la planificación hecha, estos cambios son
duplicados a las demás bases de datos
suscriptoras.
3.3 Replicación de mezcla
Permite que varios sitios funcionen en línea o
desconectados de manera autónoma, y mezclar más
adelante las modificaciones de datos realizadas en un resultado
único y uniforme. La instantánea inicial se aplica
a los suscriptores; a continuación SQL Server 2000 hace un
seguimiento de los cambios realizados en los datos publicados en
el publicador y en los suscriptores. Los datos se sincronizan
entre los servidores a una hora programada o a petición.
Las actualizaciones se realizan de manera independiente, sin
protocolo de
confirmación, en más de un servidor, así el
publicador o más de un suscriptor pueden haber actualizado
los mismos datos. Por lo tanto, pueden producirse conflictos al
mezclar las modificaciones de datos. Cuando se produce un
conflicto, el
Agente de mezcla invoca una resolución para determinar
qué datos se aceptarán y se propagarán a
otros sitios. Es útil cuando: varios suscriptores
necesitan actualizar datos en diferentes ocasiones y propagar los
cambios al publicador y a otros suscriptores; los suscriptores
necesitan recibir datos, realizar cambios sin conexión y
sincronizar más adelante los cambios con el publicador y
otros suscriptores; el requisito de periodo de latencia de la
aplicación es largo o corto; la autonomía del sitio
es un factor crucial.
Es útil en ambientes en los que cada sitio hacen
cambios solamente en sus datos pero que necesitan tener la
información de los otros sitios. Por ejemplo podría
crearse una base de datos que registre la historia delictiva de
individuos. En cada municipio de Villa Clara, se puede tener una
copia de la base de datos de toda la provincia y no se requiere
estar conectado permanentemente a la base de datos de la
instancia provincial.
4. Factores para elegir el método de
replicación a utilizar
En la elección de un método
adecuado para la distribución de los datos en una organización influyen varios factores. Los
cuales podemos agruparlos en dos grupos: factores
relacionados con los requerimientos de la aplicación y
factores relacionados con el entorno de red.
Dentro de los factores relacionados con los
requerimientos de la aplicación, los fundamentales son
[Gar99]:
- Autonomía
- Consistencia transaccional
- Latencia
La autonomía de un sitio da la medida de cuanto
puede operar el sitio desconectado de la base de datos
publicadora. La consistencia transaccional de un sitio viene dado
por la necesidad de ejecutar o no inmediatamente todas las
transacciones que se han ejecutado en el servidor, o si es
suficiente con respetar el orden de las mismas. La latencia de un
sitio se refiere al momento en que se deben de sincronizar las
copias de los datos. ¿Necesitan los datos estar el 100% en
sincronía? O si es admisible determinada latencia
¿de qué tamaño es aceptable el rezago?
[Gar99].
Entre los factores relacionados con el entorno de
red están
la velocidad de
transmisión de datos de la red, deben considerarse
preguntas como ¿Cómo luce la red? ¿Es
rápida? Debe analizarse además la confiabilidad de
la red y responder preguntas como ¿Cuán confiable
es la red? Por otra parte en el caso que los servidores SQL no
permanezcan todo el día encendidos, como pudiera suceder
en algunas organizaciones,
deben considerarse los horarios de disponibilidad de cada
servidor.
La
consideración de estos factores sirven de guia en la
configuración del ambiente de
replicación. Además debe considerar las siguientes
preguntas: ¿Qué datos se van a publicar?
¿Reciben todos los suscriptores todos los datos o
sólo subconjuntos de ellos? ¿Se deben particionar
los datos por sitio? ¿Se debe permitir que los
suscriptores envíen actualizaciones de los datos? Y en
caso de permitirlas ¿Cómo deben implementarse?
¿Quiénes pueden tener acceso a los datos?
¿Se encuentran estos usuarios en línea? ¿Se
encuentran conectados mediante enlaces caros?
5. Fases generales para implementar y supervisar
la replicación
A pesar de que existen varias formas de implementar y
supervisar la replicación, y el proceso de
replicación es diferente según el tipo y las
opciones elegidas, en general, la replicación se compone
de las siguientes fases:
- configuración de la
replicación - generación y aplicación de la
instantánea inicial - modificación de los datos
replicados - sincronización y propagación de los
datos.
6. Consideraciones finales
La replicación es muy útil para mejorar la
disponibilidad de datos, lo cual pudiera llevarse al caso
extremo, conocido como bases de datos distribuidas replicadas
totalmente, en el cual consiste en la replicación de la
base de datos completa en cada sitio en el sistema
distribuido y garantiza notablemente la disponibilidad de datos,
pues el sistema puede continuar operando cuando exista en
servicio al
menos uno de los servidores SQL Server. La desventaja es un alto
costo para
mantener la consistencia de las copias en cada sitio
[Elm00].
Referencias
Bibliográficas
[Elm00] Elmasri, R y Navathe, S. B. Fundamentals of
database systems. Addison-Wesley, Third Edition,
2000.
[Gar99] García, C. Escenario de red para la
supervisión de fallas en centrales
telefónicas. Informe
Final de Tesis de
Maestría en Computación Aplicada, Universidad
Central de "Marta Abreu" de Las Villa, Santa Clara,
1999.
[Mic01] Microsoft
Corporation, Libros en
pantalla de SQL Server, 2001.
Autor:
Lic. Daniel Eduardo Castro Morell
Licenciado en Cibernética-Matemática. Profesor Instructor del
Departamento de Computación. Universidad
Central "Marta Abreu" de las Villas. Santa Clara. Cuba
Dr. Ramiro Pérez Váquez
Doctor en Ciencias
Técnicas. Profesor Titular del Departamento
de Computación. Universidad Central "Marta Abreu" de las
Villas. Santa Clara. Cuba