Ordenación. Las operaciones de difusión permiten seleccionar distintos tipos de orden de entrega de los mensajes. Normalmente, si queremos garantizar una consistencia fuerte entre las réplicas habría que solicitar una entrega en orden total. Es decir, todos los mensajes deben entregarse en idéntico orden en todos los procesos del grupo. No obstante, ciertos tipos de aplicación sólo requieren el uso de orden causal (esto es, bastaría con ordenar aquellos mensajes con relación causa-efecto entre ellos) que permite una entrega más rápida.
Los protocolos de replicación resultan necesarios para garantizar cierto grado de consistencia entre las réplicas de la aplicación. La complejidad de un protocolo de replicación depende de:
1. El modelo de replicación utilizado. Existen dos modelos de replicación básicos: activo y pasivo. En el modelo activo el cliente difunde su petición a todas las réplicas del servidor (bien
directamente, realizando el propio cliente la difusión, o a través de una de las réplicas, que difundirá su petición antes de intentar servirla; siendo esta segunda opción la más sencilla de implantar al utilizar grupos cerrados). Estas réplicas servidoras procesan cada una de ellas la petición de manera local, sin necesidad de ninguna coordinación, y retornan su resultado al cliente. En el modelo pasivo el cliente sólo interactúa con una réplica primaria, que es la única con capacidad para procesar activamente cada petición. Posteriormente, esta réplica primaria difunde las actualizaciones al resto de réplicas y responde al cliente. A pesar de que estos dos modelos son los más importantes y más ampliamente implantados, para obtener un buen rendimiento se llegan a necesitar soluciones intermedias que precisan un protocolo de replicación más elaborado.
2. El modelo de fallos asumido. Existen dos modelos básicos: caída no recuperable (fallo de parada) y caída recuperable. En el primero se asume que cuando un proceso falle, jamás se recuperará. Esto es equivalente a asumir que cuando una réplica falle, perderá por completo su estado y, cuando llegue a recuperarse, se presentará ante el resto como una réplica nueva, necesitando una transferencia completa del estado de la aplicación. En el segundo modelo, la caída de un proceso no implica la pérdida completa del estado. Se supone que parte de tal estado se mantiene de manera persistente. Así, cuando vaya a reincorporarse al grupo, una réplica bajo este modelo sólo necesita recuperar aquella parte de su estado (y las actualizaciones) que haya perdido.
3. El número de réplicas que puedan estar procesando distintas peticiones de manera simultánea. Esto depende del modelo de replicación empleado. Sólo plantearía dificultades en caso de adoptar un modelo diferente a los dos básicos comentados en el punto 1.
El protocolo de recuperación dirige los pasos a llevar a cabo cuando una réplica se reincorpora al grupo, o cuando una nueva réplica es añadida. Su complejidad dependerá principalmente del modelo de fallos que esté siendo asumido y del protocolo de replicación en el que deba ser integrado.
El protocolo más sencillo de este tipo, se llega a obtener combinando un modelo de fallos de caída no recuperable, con un protocolo de replicación que se apoye en la sincronía virtual proporcionada por el SCG. Así, en ese entorno, el protocolo de recuperación se limitaría a transferir una copia completa del estado desde cualquiera de las réplicas que ya estén funcionando con normalidad, garantizando que tal transferencia de estado haya sido aplicada antes de que llegue a procesarse la primera de las operaciones (en caso de utilizar el modelo de replicación activo), o la primera de las actualizaciones de estado (en el modelo pasivo) entregadas, en esa réplica que se recupera, en esa nueva composición del grupo. Debe considerarse que el entorno utilizado en este ejemplo sólo tiene sentido para aquellas aplicaciones cuyo estado no esté compuesto por una gran cantidad de información.
Por el contrario, cuando las aplicaciones necesiten utilizar un modelo de fallos de caída recuperable y mantengan gran cantidad de información, los protocolos de recuperación serán ciertamente complejos.
Esquemas de replicación y actualización de réplicas
La replicación de la información puede darse de varias maneras. En el caso más extremo, una replicación total de la BD, mejora notablemente la disponibilidad de la información, dado que es altamente probable que algún sitio siempre permanezca activo. También se mejora el rendimiento de las consultas que se hacen sobre la BD, dado que cualquier sitio dispone de información necesaria para contestar a la requisitoria. La desventaja de la replicación completa es que puede reducir drásticamente la rapidez de las operaciones de actualización, por el motivo que una sola actualización lógica se deberá ejecutar en todas y cada una de las copias de la BD.
El extremo opuesto al esquema de replicación total, lo constituye la no replicación de los datos. Cada fragmento se almacena en un solo sitio. Esta solución conlleva ventajas y desventajas opuestas al caso anterior.
En general, estas soluciones no resultan aplicables como respuesta a un problema de BDD, salvo para situaciones muy puntuales. Por este motivo, se considera que una replicación parcial de datos es la mejor solución. Esta replicación parcial tiene una amplia gama de soluciones. Se denomina esquema de replicación al formato seleccionado.
¿Qué es la replicación de datos?
La replicación de datos es mucho más que la simple copia de datos entre varias localidades. Ha sido utilizada, tradicionalmente, como el mecanismo básico para incrementar la disponibilidad y la perfomance de una BDD.
La replicación debería estar acompañada del análisis, diseño, implementación, administración y monitoreo de un servicio que garantice la consistencia de los datos a lo largo de múltiples administradores de recursos en ambientes distribuidos. Por este motivo, un servicio de replicación de datos debería proveer la siguiente funcionalidades:
Ser escalable. Con respecto a la replicación, la escalabilidad significa la habilidad de replicar volúmenes de datos pequeños o grandes a lo largo de recursos heterogéneos (hardware, redes, sistemas operativos).
Proveer transformación de datos y mapeo de servicios. Estos servicios permiten que los esquemas de datos diferentes coexistan sin perder su semántica esencial. Por ejemplo, las copias pueden ser idénticas o semánticamente equivalentes. Las copias idénticas podrían tener la misma plataforma, el mismo contenido de información y el mismo tipo de datos, en tanto que copias semánticamente equivalentes podrían tener el mismo contenido de información pero diferentes plataformas y, posiblemente, diferentes tipos de datos.
Soportar replicación en modo sincrónico (tiempo real) o asincrónico.
Proveerse un mecanismo que describa los datos y objetos que se van a replicar (diccionario de datos).
Proveerse un mecanismo para inicializar un nodo, esto es para indicar la recepción de datos replicados.
Soportar administración end-to-end de seguridad y calidad de servicios. Por ejemplo, el servicio debe garantizar que no puede ocurrir corrupción en los datos durante la proceso de replicación. En otras palabras, los datos pueden cambiar de formato pero no de contenido.
Proveerse un mecanismo de bitácora que administre cualquier esfuerzo de replicación fallado.
Proveer un mecanismo de recuperación automático.
Metodología de replicación de datos
Es importante seguir una metodología correcta de diseño de una BDD para poder obtener un esquema que sea escalable y adaptables a los cambios de tecnología.
La forma de distribución de información debe ser analizada cuidadosamente buscando una opción que optimice y maximice la utilización todos los factores que se deban considerar para un problema particular.
El factor principal para la determinación de la distribución de datos va a estar dado, básicamente, por los requerimientos de usuario. Cuestiones como por ejemplo la performance del sistema puede llevar a generar mayor replicación en los datos, a fin de colocar la información "cerca" del usuario, evitando el costo de la transmisión de datos en la red. Obviamente esta apreciación puede tornarse rápidamente en un inconveniente. Si la replicación de la información aumenta los protocolos de cometido van a demorar más en completar su ejecución, o mantener las copias actualizadas "en línea" resulta más costoso.
Se puede obtener replicación de datos considerando diferentes criterios. Uno de ellos, quizá el más simple, consiste en clasificar la replicación por el costo de latencia que existe para lograr la consistencia de los datos a lo largo de todas las réplicas. De esta manera se puede hablar de dos tipos de replicación: sincrónica o asincrónica (eager o lazy).
La replicación sincrónica provee un mecanismo que asegura que todas las réplicas se mantengan actualizadas en línea. De esta forma, la latencia para lograr consistencia de datos se reduce a cero. La implementación clásica del protocolo de cometido de 2 fases (2PC) garantiza este tipo de replicación. Con este esquema de actualización de réplicas es posible garantizar las propiedades ACID de una transacción. Por el contrario, la replicación asincrónica se limita a asentar las modificaciones en una copia o réplica, dejando para más adelante la actualización del resto. De esta forma, un esquema con estas características debe aceptar inconsistencia temporaria de información.
Mecanismo de actualización de réplicas. Esquema de propagación
En una BD, el mecanismo de control de replicación asegura la consistencia de datos entre copias existentes. Categorizan los mecanismos acorde a la forma en que las modificaciones se propagan y que copia es actualizada primariamente.
La propagación de los cambios sobre la BD puede hacerse dentro o fuera de los límites de una transacción. En el caso de replicación eager, se realiza dentro de una transacción, mientras que el esquema lazy propaga las modificaciones de los datos fuera del alcance de la transacción que los genera. De esta manera, un esquema eager permite la detección de conflictos antes que la transacción cometa. Así, la consistencia en la información se consigue de una forma directa, con un aumento en el costo de respuesta de la transacción. El esquema lazy, por el contrario, demora la propagación de los cambios hasta que la transacción haya finalizado, implementando la propagación de los cambios como un proceso que corre en segundo plano. Para lograr esta solución se debe aceptar inconsistencias entre las diferentes copias de datos que se tiene en diferentes localidades de la red.
Esquema de propagación Eager
Un esquema Eager mantiene todas las copias exactamente sincronizadas en todas las localidades modificando todas las réplicas como parte de una transacción atómica. El esquema de replicación eager permite una ejecución serializable, debido a que no se presentan anomalías de concurrencia. En contraste un esquema Eager reduce la performance de una actualización e incrementa el tiempo de respuesta de una transacción porque la acción determinada por ésta debe resolverse en múltiples emplazamientos, requiriendo mayor cantidad de mensajes.
La utilización del esquema eager permite en todo momento que cualquier lectura sobre una copia del dato obtenga como resultado una información correcta.
Ventajas del esquema de propagación eager o de actualización de replicación sincrónica:
Serialidad: Debido a que todas las actualizaciones dentro del proceso de replicación ocurren como una unidad lógica de trabajo, las transacciones exhiben lo que comúnmente se llaman propiedades ACID, generando, de esta forma, ejecución serializable, sin inconsistencias ningún tipo.
Consistencia firme: Se desprende de la anterior. La actualización original se demora hasta que todas las copias se actualicen, originando una transacción global. Así, cuando una transacción comete, todos las copias tienen el mismo valor, logrando que la latencia antes que se logre consistencia de los datos sea cero.
Sin embargo, estas ventajas tienen los siguientes costos:
Pérdida de performance: debido a que se necesita sincronizar cada acceso a datos con las demás réplicas durante la ejecución de la transacción, lo convierten en un esquema muy caro.
Mayores tiempos de respuesta: corolario del caso anterior. Esta sobrecarga de mensajes tiende a reducir la performance de actualización e incrementar los tiempos de respuestas transaccionales, no pudiendo darle una respuesta al usuario hasta que la actualización haya sido cometida por completo.
No resulta en un esquema que sea fácilmente escalable. La mayor desventaja es que el número de operaciones por transacción aumenta con el grado de replicación de los datos (O(N) donde N es el número de nodos), y debido a que la probabilidad de deadlock (fallos en las transacciones) suben muy rápidamente con el tamaño de la transacción y con el número de nodos, resulta en un esquema inseguros para escalar mas allá de un pequeño número de sitios.
No son apropiados para ambientes móviles. Por un lado reducen la performance de las actualizaciones con sincronizaciones extras, y por el otro, en un ambiente móvil los nodos están normalmente desconectados. De aquí que una actualización sincronizada no sea válida para este tipo de ambientes.
6.3.2 Esquema de propagación Lazy
Un esquema de propagación lazy permite que una réplica sea actualizada por la transacción original. Las actualizaciones de las restantes se propagan asicrónicamente, generalmente con una transacción para cada sitio o localidad.
La actualización asincrónica de réplicas o esquema de propagación lazy proporciona las siguientes ventajas: ??
Mayor performance: el tamaño de las transacciones es reducido, solo se limitan a actualizar la copia primaria de datos y, por consiguiente, son menores los boqueos necesarios. Se mejora, de esta forma, la performance global del sistema. Los esquemas lazy presentan mejores resultados que los eager en la mayoría de los casos que se pueden plantear.
Mayor facilidad de escalabilidad: una conclusión del caso anterior, el número de deadlock es menor que los esquemas eager debido a que las transacciones son más cortas. Sin embargo, cada actualización genera N-1 transacciones para actualizar las demás réplicas, esto lleva a que el número de transacciones concurrentes aumente en O(N) (donde N es el número de nodos)
Aptos para ambientes móviles: estos esquemas dan una respuesta inmediata al usuario, los cambios de la propagación son realizados luego; este tipo de respuesta es de gran importancia dada la proliferación de aplicaciones para usuarios móviles, donde una copia no está siempre conectada al resto del sistema y no tiene sentido esperar hasta las actualizaciones se hayan cometido para permitir al usuario ver los cambios.
Desventajas surgidas con este tipo de esquemas:
Consistencia débil: debido a que cada transacción ejecuta localmente e independientemente, el sistema no requiere protocolos de cometido como los discutidos en capítulos anteriores (2PC o sus variantes o 3PC). Estos protocolos los cuales tienden a introducir bloqueos y no son fácilmente escalables. Consecuentemente, este esquema debilita la propiedad de consistencia mutua asegurada por 2PC y proporciona una consistencia más débil, en la cual la latencia antes de lograr la consistencia de los datos es siempre mayor que cero. Como conclusión, existe siempre algún grado de retraso entre el tiempo de cometer la copia origen y el tiempo para disponerla en las demás réplicas, permitiendo que las copias puedan divergir y se produzcan posibles inconsistencias en los datos.
Acceso a "datos viejos": surge como consecuencia de la consistencia débil. Existe la posibilidad que la propagación asincrónica pueda causar que una transacción de actualización obtenga valores viejos de algún dato, resultando una ejecución que genera un estado inconsistente de la base de datos. Por ejemplo: si se dispone de dos cuentas bancarias C1 y C2 en dos sitios diferente S1 y S2. El banco requiere que la suma de las cuentas sea positiva y ambas cuentas están replicadas en ambos sitios. Suponga que dos personas P1 y P2 comparten esas cuentas con $ 300 en C1 y $ 700 en C2. P1 extrae $900 de la cuenta C1 desde el sitio S1 y, aproximadamente al mismo tiempo, P2 extrae $900 de la cuenta C2 en el sitio S2. Debido a la demora de actualización que presenta el esquema lazy en la propagación de los resultados, ambas transacciones pueden acometerse. A pesar de que las transacciones fueron propagadas, ambas cantidades tienen un balance negativo, violando el requerimiento bancario.
6.3.3 Esquema propietario master slave
Un esquema propietario master slave asigna un dueño a cada objeto de datos. Las modificaciones sobre ese elemento se hacen primero sobre la copia maestra (o primaria) y luego se propagan a las copias esclavas (o secundarias). Bajo este esquema cada objeto puede tener un propietario diferente.
Cuando una transacción necesita modificar un objeto de dato, envía un RPC (remote procedure call) al nodo propietario del objeto. Para alcanzar seriabilidad, una operación de lectura debería enviar un bloqueo de lectura en el RPC a cada propietario de objeto que necesita leer.
Una posibilidad de implementación de este esquema consisten en que solo la copia primaria es de lectura-escritura; el resto de las copias son exclusivamente de lectura. Todas las transacciones que deben modificar un objeto de datos deben concentrarse en hacer dicha modificación en la copia maestra, siendo esta la encargada de actualizar a las esclavas.
La principal ventaja de este modelo es la simplicidad. El modelo permite que las actualizaciones sean aceptadas sólo en un lugar, logrando que las modificaciones sobre las réplicas fluyan de una sola manera. Además simplifica el esquema de control de la concurrencia. Esta ventaja trae consigo los siguientes costos:
Funcionalidad limitada Un modelo simple sobreviene con una funcionalidad limitada. La copia esclavo es de solo lectura, sólo pueden realizarse modificaciones a la copia primaria, debiendo sincronizar cada slave directamente con la copia master. Esto puede ser un inconveniente para situaciones donde los usuarios requieren tener la habilidad de actualizar directamente sus datos locales como es el caso de ambientes móviles.
Diferenciación de replicas: demostrar ser más simple no significa que el sistema en conjunto lo sea, en este caso se debe enfrentar la presencia de dos clases de réplicas. Se debe manipular de diferente manera los cambios en datos de nodos master, de los cambios sobre copias slave. Esto puede significar un retraso en la actualización y, por consiguiente, se podría acceder a un dato desactualizado.
La disponibilidad de los datos puede verse afectada por varios factores:
cuello de botella: todos los pedidos de actualización están asociados al sitio que contiene la copia primaria, con lo cual se genera un cuello de botella
punto simple de falla: si un nodo master no puede ser accedido (por fallo propio o del enlace de comunicaciones), las copias master no pueden aceptar actualizaciones hasta la recuperación de los mismos, introduciendo un único punto de falla. Nuevamente, esta opción torna imposible su utilización en entornos móviles.
Escalabilidad: la escalabilidad de un sistema replicado está determinado por el método de regulación de actualizaciones. A medida que aumenta el número de réplicas, aumenta la demora en la propagación de las actualizaciones y a veces crea cargas de trabajo desequilibradas entre las réplicas. El esquema mastar-slave, en particular, lo hace debido a que es el responsable de propagar las actualizaciones a las otras réplicas. Estos esquemas experimentan O(N) conflictos de actualización (N es el número de réplicas). Una solución es conectar las réplicas en una estructura de árbol, localizando el master en la root, y las actualizaciones se van propagando hacia abajo desde la raíz. Esto acorta el retraso de propagación de O(N) a O(log2 N) (N es el número de réplicas) y reduce la carga sobre el master a un nivel constante.
6.3.4 Esquema propietario Group
Un esquema propietario group permite que cualquier nodo con una copia de datos pueda actualizar sobre ese nodo. Este método es, generalmente, denominado como de actualización dondequiera.
Cuando una transacción ocurre, se envía otra transacción a cada nodo con copia del dato para aplicar la misma actualización. El inconveniente que puede surgir en este caso es que dos nodos actualicen el mismo objeto y que, por lo tanto, intenten propagar dicha actualización al resto de los nodos. Este esquema debe detectar esta situación y debe, además, reconciliar las dos transacciones para que ningún cambio se pierda.
Las ventajas que presenta el esquema group mejoran los costos asociados con el esquema Master-Slave:
Igualdad de replicas: no existe el concepto de master o sitio primario, todas las réplicas son iguales, se actualizan al mismo tiempo y se puede acceder a cualquiera de ellas sin tratamiento especial.
Mayor disponibilidad: este tipo de esquemas no introduce cuellos de botella, permitiendo obtener, de esta forma, esquemas más robustos y facilitar la distribución de cargas entre diferentes sitios.
Mayor funcionalidad: la comunicación de este esquema es más robusta, permitiendo que cualquier par de réplicas se comuniquen e intercambien actualizaciones.
Mayor flexibilidad: esta cualidad se logra al eliminar restricciones de tiempo de diseño donde se debe decidir el tipo de operaciones que pueden realizar los usuarios y sobre que localidades se pueden efectuar. Sin embargo, generalmente, se presenta el costo subsecuente de padecer problemas de escalabilidad.
Entre las desventajas se encuentran:
Escalabilidad: las actualizaciones pueden arribar concurrentemente a dos copias diferentes del mismo elemento de dato, pudiendo generarse un conflicto de actualizaciones. [Gray et al., 1996] Este tipo de esquemas no pueden soportar muchas replicas del mismo elemento de datos porque podría significar O(N²) de conflictos de actualización. Esto significa que, salvo en aquellas situaciones donde el número de operaciones de lectura respecto de la carga global de trabajo sea alto, el sistema puede no ser escalable a medida que se agregan nuevos nodos.
Diseño: la elección del modelo de replicación es vital en este tipo de esquemas. Como corolario del caso anterior, si el número de replicaciones de elementos de datos aumenta se corre el peligro de un alto costo de comunicación y/o conflictos en el proceso de actualización de información.
La replicación es un mecanismo utilizado para propagar y diseminar datos en un ambiente distribuido, con el objetivo de tener mejor performance y confiabilidad, mediante la reducción de dependencia de un sistema de base de datos centralizado. Dada la diversidad de contextos donde se aplican mecanismos de replicación, se puede disponer de una gama de posibilidades, en vez de utilizar una única forma de replicar datos. Cada uno de los tipos de replicación se adapta en mayor o menor medida y pueden utilizarse en forma combinada para un caso específico. Los tipos de replicación disponibles permiten moverse desde contextos donde los sitios trabajan en forma completamente unos de otros, hasta contextos donde se requiere una alta consistencia transaccional.
La investigación en áreas de BD es una actividad muy activa en el desarrollo informático. Esto se debe básicamente a que las aplicaciones de software actuales y las futuras requieren controlar el acceso a los datos con un índice de fiabilidad siempre creciente, a pesar de problemas de concurrencia, fallos o disponibilidad de esta información.
Los DBMS deberán seguir garantizando las propiedades de ACID de una transacción ante las posibles situaciones de fallos y operando de manera cada vez más eficiente minimizando o eliminando los problemas que puedan surgirá a partir de actualización de la información en la BDD.
La tendencia actual, además, tiende a administrar sistemas que aparecen "desconectados" o careciendo de una conexión full-time, lo que agrega un conjunto nuevo de problemas que no pueden ser tratados con los métodos clásicos empleados anteriormente.
Un objetivo con las BDD es aumentar la disponibilidad de la información, colocando la misma "cerca" del usuario. Esto significa que la replicación de la información tiende a aumentar generando más inconvenientes potenciales al momento de su actualización. Conceptos como seguridad, performance, optimización, casos de uso deben ser tenidos en cuenta cuando se plantea el esquema de distribución, y en particular el de replicación de este esquema.
Si se combinan los conceptos de replicación y aseguramiento de integridad de datos por medio de transacciones y protocolos de cometido, se puede observar que el tiempo de respuesta de estos últimos está en directa dependencia de la cantidad de sitios de la red que contienen réplica de datos, más allá de la performance en sí del protocolo.
Se puede concluir que los sistemas de actualización de réplicas con esquema de propagación Lazy tienden a ser superiores en performance que los Eager. De esta forma, la escalabilidad del sistema estaría asegurada, dado que con esquemas Lazy se pueden incorporar nuevas réplicas de datos, y no afectar en demasía la performance final del sistema.
Sin embargo, no se debe perder de vista que los esquema lazy en general y utilizando el método propietario Group en particular, introducen una nueva situación posible de inconsistencia al no mantener actualizada la información "en línea". En estos esquemas se cambia la situación de esperas e interbloqueos (deadlock) por posibilidad de inconsistencia y mecanismos de reconciliación.
Bajo este esquema se contradicen las propiedades ACID definidas para una transacción. Las condiciones de atomicidad, consistencia y durabilidad son conceptos que, o bien son difíciles de lograr. o bien es directamente imposible alcanzarlos en el caso-problema real. Para analizar esto en detalle se debe repasar la idea de una transacción cometida bajo este entorno. Así, de acuerdo a las definiciones presentadas en los capítulos iniciales, una transacción cometida es aquella que ha finalizado su ejecución y que ha dejado la BD de manera consistente. Entonces, no se puede considerar una transacción como terminada hasta que no haya actualizado todas las réplicas de la BD.
Para finalizar el análisis de los mecanismos de actualización, se puede concluir que los esquemas de propagación Eager y propietario MasterSlave resultan poco interesantes si se tiene un modelo de red donde determinados sitios aparecen parcialmente conectados (lo que comúnmente se denomina sitios o nodos móviles). El primero de ellos debido a que si una réplica reside en un nodo móvil no podrá ser actualizada "en línea" y esto demorará innecesariamente (y eventualmente por un tiempo no conocido a priori) el cometido de la transacción. El segundo aspecto en tanto, obligará a que un sitio móvil no pueda contener la copia maestra de algún dato, dado que si se encontrara desconectado no se podrían realizar actualizaciones, obligando a fallar a todas aquellas transacciones que actualicen esa información cuando el sitio no se encuentra accesible. Los problemas que surgen a partir de la utilización de sitios móviles son muy interesantes. En la sección de trabajos futuros y en el apéndice A se describen en más detalle estas situaciones con algunas consideraciones propuestas.
[Özsu et al., 1991] Principles of Distributed Database Systems. Second Edition. M.Tamer Özsu,
Patrick Valduriez. Prentice Hall. 1991.
[Bertone et al., 2001] Distributed processing in replicated image Data Bases. Efficiency analysis. R. Bertone, S. Ruscuni, A. De Giusti, A. Mauriello. Miami, USA 2001
[Buretta 1997] Data Replication. Tools and techniques for managing distributed information. Marie
Buretta. Editorial: John Wiley & Sons, Inc. 1997.
[Holliday et al., 1998] Database Replication: If you must be Lazy, be Consistent. JoAnne Holliday,
Divyakant Agrawal, Amr El Abbadi. Departement of Computer Science.
University of California at Stan Barbara. 1998.
[Len 2001] Actualización de Réplicas de datos en entornos de BDD. Sergio Len. Tesina de Grado.
Facultad de Informática. 2000. Director: Rodolfo Bertone.
Autor:
Vivian Romero Buchilla N
| Página siguiente |