REPLICACIN

Presentado por:
Isaac Tisnado
Juan pablo cuevas
Orlando de la rosa
Elias Herrera
Juan torres
 INTRODUCCIN
Es el proceso de copiar y mantener objetos de la base de
datos, como por ejemplo sus relaciones en mltiples bases de
datos
Tambin es una tcnica que mejora el rendimiento de los
servicios, esta mejora se obtiene aumentando la disponibilidad
y creando servicios tolerantes a fallos.
Beneficios -

Disponibilidad
Fiabilidad
Rendimiento
Reduccin de la carga
Generacin de bloqueos
Soporte mltiples usuarios
Formas de replicar - Por consola o por panel administrativo
Replicacin
INTRODUCCIN

Dos requisitos bsicos para todo dato replicado son:

Transparencias frente a la replicacin: Esto quiere decir que
el cliente no debe percibir que existen mltiples copias fsicas de
los datos, slo deben identificar un solo tem cada vez que
requieran que se realice una operacin.

Consistencia: Se define como la coherencia entre todos los

datos de la base de datos. Cuando se pierde la integridad se
pierde tambin la consistencia, pero la consistencia tambin se
puede perder por razones de funcionamiento.
MDULO DE SISTEMA Y COMUNICACIN
EN GRUPO

SISTEMAS DATOS OBJETOS

RPLICAS
 Diversos elementos de un sistema distribuido pueden fallar :
o Procesadores, red, dispositivos, software, etc.
Tipos de Fallos:
Transitorios
Intermitentes
Permanentes
Semntica de fallos :
fail-stop
bizantina: funcionamiento arbitrario y/o malicioso
Soluciones Basadas generalmente en replicacin
 Disponer de copias de datos, servicios o recursos
Objetivos
o Mejorar el rendimiento
o Mejorar la disponibilidad
o Tolerancia a fallos
Requisitos
o Transparencia
o Coherencia
o Rendimiento
 El elemento a replicar se suele denominar objeto.
Un objeto est compuesto por una serie de copias fsicas denominadas
rplicas.

Un sistema replicado debe contemplar:

o Modelo de Sistema: Como funcionan cada uno de los gestores de
rplicas.
o Comunicacin del Sistema: Intercambio de informacin entre los
gestores de rplicas. Muy til mecanismos multicast.
 Rplicas
Las rplicas son objetos fsicos almacenados cada uno de ellos
en un computador individual, con datos y comportamientos que
estn vinculados con un cierto grado de consistencia dentro del
funcionamiento del Sistema.
 Modelo del Sistema
El modelo implica rplicas mantenidas por distintos
gestores de rplicas que son componentes que almacenan
las rplicas en un cierto computador y realizar
directamente operaciones sobre ellas.
Este modelo general puede aplicarse en un entorno cliente servidor , en cuyo
casos el gestor de rplicas es el servidor.Algunas veces se les llamar
simplemente servidores. Igualmente puede referirse a una aplicacin y, en ese
caso,los procesos de la aplicacin pueden actuar tanto como clientes como
gestores de rplicas.
Cada gestor de rplicas debe
garantizar las propiedades de una
transaccin dentro de sus datos
asociados.
Caractersticas:
- Funcionamiento determinista.
- Recuperabilidad.
- Conjunto esttico o dinmico.
Fases de una peticin:
- Recepcin (front-end).
- Coordinacin.
- Ejecucin.
- Acuerdo.
Todos los RMs
- Respuesta.
 Comunicacin en Grupo
se exigir que un gestor de rplicas solicite operaciones a sus rplicas con capacidad de recuperacin.
Esto permite suponer que una operacin en un gestor de rplicas no deja resultados inconsistentes si falla durante el
proceso.
tambin se exigir a cada gestor de rplicas que sea una mquina de estado .
Aplica operaciones atmicas(indivisibles) a sus rplicas, de tal forma que su ejecucin es equivalente a realizar las
operaciones siguiendo una secuencia estricta.
el estado de las rplicas es una funcin determinista de los estados iniciales y de la secuencia de operaciones que se les
ha aplicado.
 Servicios Tolerantes a Fallos

Se refiere a la capacidad de un sistema de acceder a la

informacin, aun en caso de producirse algn fallo o
anomala en el sistema.
Servicios Tolerantes a Fallos
Deben proporcionar un servicio correcto aunque fallen f
procesos, mediante la replicacin de datos y la funcionalidad
asociada a los gestores de rplicas.

Intuitivamente, un servicio es correcto si

Responde a pesar de haber fallos o
El cliente no distingue la ejecucin normal de una con fallos
Servicios Tolerantes a Fallos
Criterios de correccin
Linealizabilidad
Consistencia secuencial

Dos modelos principales

Replicacin pasiva o primario-respaldo
Replicacin activa
 Servicios Tolerantes a Fallos
Criterio de Correccin Linealizable

Un servicio es linealizable si para alguna de las posibles secuencias de operaciones

intercaladas:

El orden de las operaciones en el intercalado es consistente con los tiempos

reales en los que ocurrieron.

Dicho orden en serie real es consistente con las copias u operaciones

realizadas.
 Servicios Tolerantes a Fallos
Criterio de Correccin Consistencia
Secuencial
Un servicio es consistente secuencialmente si para alguna de las posibles secuencias

de operaciones intercaladas:

El orden de las operaciones en el intercalado es consistente con el orden de

programa que ejecuta cada cliente individual.

Dicho orden en serie real es consistente con las copias u operaciones

realizadas .
 Servicios Tolerantes a Fallos
Replicacin Pasiva (Primario-Respaldo)

El gestor de rplicas primario ejecuta las operaciones y enva copias de los datos

actualizados a los gestores de respaldo. Si el primero falla, uno de los secundarios se

promociona para que acte como gestor primario.

Primario

C F GR GR

Respaldo
C F
GR

Respaldo
 Servicios Tolerantes a Fallos :: Replicacin Pasivo

Secuencia de eventos
Peticin: el frontal lanza la peticin, que contiene un identificador nico, al gestor de
rplicas primario.

Coordinacin: el primario acepta cada peticin de forma atmica, en el orden en que

las recibe. Comprueba el identificador nico y, en caso que ya hubiera ejecutado la
peticin, simplemente reenva la respuesta. Primario

C F GR GR

Respaldo
C F
GR

Respaldo
 Servicios Tolerantes a Fallos :: Replicacin Pasivo

Secuencia de eventos
Ejecucin: el primario ejecuta la peticin y guarda la respuesta.

Acuerdo: si la peticin es una actualizacin, entonces el primario enva a todas las

copias de seguridad el estado actualizado, la respuesta y el identificador nico. Los
respaldo enva, a su vez, un acuse de recibo (Justificante de recepcin)

Respuesta: el primario responde al Primario

frontal, que proporciona la respuesta

C F GR GR
de vuelta al cliente.
Respaldo
C F
GR

Respaldo
 Servicios Tolerantes a Fallos :: Replicacin Pasivo

Anlisis
No tolera fallos bizantinos

El frontal requiere poca funcionalidad

Al controlar el orden de modificacin mediante el gestor primario,

mantiene la linealizabilidad.

Problemas de cuello de botella en el gestor primario

Actualizacin de todos los respaldos antes de dar respuesta
Los respaldos no dan servicio directo
 Servicios Tolerantes a Fallos
Replicacin Activa
En este modelo los gestores de rplicas son mquinas de estado que desempean papeles

equivalentes y se organizan como un grupo. Los frontales multidifunden sus peticiones al

grupo de gestores de rplicas y todos los gestores procesan la peticin de forma

independiente , pero idntica, y responden.

GR

C F GR F C

GR
 Servicios Tolerantes a Fallos :: Replicacin Activa

Secuencia de eventos
Peticin: el frontal adjunta un identificador nico a la peticin y la multidifunde. Se
asume que en el peor de los casos, el frontal falle por cada. Adems no emitir la
siguiente peticin hasta que haya recibido una respuesta.

Coordinacin: el sistema de comunicacin en grupo reparte la peticin a cada gestor de

rplicas correcto en el mismo orden (total).

GR

C F GR F C

GR
 Servicios Tolerantes a Fallos :: Replicacin Activa

Secuencia de eventos
Ejecucin: Cada gestor de rplica ejecuta la peticin. Puesto que son mquinas de
estado, y las peticiones se entregan en el mismo orden total, todos los gestores de
rplicas correctos procesan idnticamente la peticin.

Acuerdo: no se necesita fase de acuerdo, debido a la semntica de reparto de la

multidifusin.

GR

C F GR F C

GR
 Servicios Tolerantes a Fallos :: Replicacin Activa

Secuencia de eventos
Respuesta: cada gestor de rplicas enva su respuesta al frontal. El nmero de respuestas

que recoge el frontal depende de las suposiciones de fallo y del algoritmo de multidifusin.

GR

C F GR F C

GR
 Servicios Tolerantes a Fallos :: Replicacin Activa

Anlisis
La multidifusin fiable y totalmente ordenada es la que aporta la tolerancia
a fallos

Dicho tipo de multidifusin es equivalente a un algoritmo de consenso, con

lo que resuelve fallos bizantinos
El frontal recoge f+1 respuestas iguales antes de responder al cliente
 Servicios Tolerantes a Fallos

Replicacin Pasiva vs Activa

Pasiva Activa

Peticin Se enva slo al gestor primario. Multidifusin con ordenacin total a todos.

Correccin FIFO. Total

Ejecucin En el primario. En todos los gestores.

Acuerdo Si es una actualizacin, se enva a No es necesario (debido a la ordenacin

todas las rplicas. total).

Respuesta Tras la actualizacin si es necesaria. El cliente recoge un n de respuestas.

SERVICIOS CON ALTA DISPONIBILIDAD
Para que un sistema cuente con Alta Disponibilidad debera proporcionar
un nivel de servicio aceptable utilizando un conjunto mnimo de gestores
de rplica conectados al cliente.

Sistema de Arquitectura COTILLA

El Sistema BAYOU

El Sistema de Archivos CODA

 Sistema de Arquitectura COTILLA
Creado por Ladin y Otros [1992].
El nombre refleja el hecho de que los gestores de replica intercambian peridicamente
mensajes de cotilleo para transmitir las actualizaciones que ha recibido cada uno por parte
de sus clientes.

El Sistema de cotilla funciona a base de dos tipos de operaciones:

Consultas: Solo lectura.
Actualizaciones: Solo Escritura.

ste sistema garantiza dos cosas:

Cada cliente obtiene un servicio consistente a lo largo del tiempo.
Consistencia relajada entre rplicas (3 tipos: Casual, Orden Forzado, Inmediata).
Sistema de Arquitectura COTILLA
Servicio

GR

Cotilleo
GR GR

Consulta, Val, Actualizacin, Id actualizacin

prev Nuevo prev
F F

Consulta Val Actualizacin

Clientes
 Las marcas temporales de la versin
del Frontal
Cada frontal tiene un vector de marcas temporales con la
versin de los ltimos valores de los datos a los que
accedi (prev).
2
La marca de cada dato tiene una entrada por cada gestor.
1 3
El frontal enva las marcas en cada mensaje de peticin a
un gestor, junto con el tipo de peticin.
El gestor devuelve un nuevo vector de marcas con la
respuesta a las peticiones de pregunta (new).
Se fusiona con el vector que tiene el frontal para registrar
la versin de los datos observada por el cliente hasta
ahora. 1 2 3 Consulta
3 3 3 Descripcin
Mensaje de Cotilleo
Mensaje de Cotilleo

2
1 x 3

1 2
Propagacin de las Actualizaciones

La frecuencia y la duracin de las particiones

de la Red.
La frecuencia con la que los gestores de
rplica envan mensajes de cotillas.
La poltica de seleccin de un socio con el cual
intercambiar mensajes cotillas.
 Sistema de Arquitectura BAYOU
Creado por Terry y Otros [1995].
Petersen y Otros [1997].
Como la arquitectura cotilla, da garantas ms dbiles que la
consistencia secuencial.
Cada gestor recibe el mismo conjunto de actualizaciones
(eventualmente).
Las actualizaciones se aplican de modo que todas las
rplicas sean idnticas (eventualmente).
Tcnicas de resolucin de conflictos especficas del dominio.
Aplicaciones:
Sistemas de edicin distribuida con desconexin permitida
 Actualizaciones Tentativas y
consumadas
La actualizacin tentativa ti se convierte en la siguiente
actualizacin consumada y se inserta tras la ltima
actualizacin consumada CN.
 Desventajas y Comparativa
La replicacin no es transparente al cliente
El programador debe proveer mtodos de chequeo de consistencia
y procedimientos de fusin.
Puede reportar errores si una actualizacin no se puede aplicar.
Las actualizaciones se pueden alterar durante la fusin.
 Sistema de Archivos CODA
Creado por Satyanarayanan y Otros [1990].
Kistler y Satyanarayanan [1992].
El Sistema de Ficheros Distribuido Coda es el sucesor
de Andrew
File System (AFS) y es un desarrollo de la Universidad de
Carnegie-Mellon como ejemplo de entorno de trabajo distribuido.

Coda destaca sobre AFS por permitir la Computacin Mvil (trabajar

en modo desconectado), soportar mejor la tolerancia a fallos del
sistema (por ejemplo cada de los servidores o fallos de la red) y por
disponer de tcnicas de replicacin de los servidores.

Al ser gratuito, su cdigo fuente est diseado para trabajar tanto

en LAN como en WAN.
 Sistema de Archivos CODA Disponibilidad constante de datos

La Arquitectura CODA
VICE = Gestor de Rplica (En los servidores).
Venus = Hbrido entre GR y Frontales. (Computadores
de Clientes).
VSG = Grupo de Almacenamiento del Volumen
(Conjunto de Servidores).
AVSG = Grupo Disponible de Almacenamiento del
Volumen (Subconjunto de VSG).
Un principio del diseo de CODA es que las copias de
los archivos que residan en los servidores sean ms
fiables que aquellas que residan en la memoria cach
de los computadores de los clientes.
 Sistema de Archivos CODA Disponibilidad constante de datos

La Estrategia de Replicacin (CVV = Vector de Versiones de coda)

Una CVV es un vector de marcas temporales con un elemento para cada servidor
en el VSG relevante. Cada elemento de CVV es una estimacin del nmero de
modificaciones realizadas en la versin del archivo que est en el servidor
correspondiente.
Coherencia cach
Las garantas de vigencia del sistema coda, expuestas anteriormente, implican
que el proceso venus en cada cliente debe detectar los siguiente eventos dentro
de los T segundos siguiente a que hayan ocurrido:
Aumento del tamao de un AVSG (Debido a que un servidor que antes
estaba inaccesible se ha vuelto accesible).
reduccin del tamao de un AVSG (Debido a que un servidor se vuelve
inaccesible).
Prdida de un evento de devolucin de llamada.
 Sistema de Archivos CODA Disponibilidad constante de datos

Acceso a las rplicas

La estrategia usada en open y close para acceder a las rplicas de un archivo es
una variante de la aproximacin uno lee / todos escriben.

En open si no hay una copia del archivo en la cach local el cliente identifica,
para ese archivo, un servidor preferido dentro del AVSG. Dicho servidor puede
elegirse de forma aleatoria o basndose en criterios de rendimiento tales como la
proximidad fsica o la carga del servidor.

El cliente solicita al servidor preferido una copia de los atributos y el contenido del
archivo, y cuando los recibe, contacta con el resto de los miembro del AVSG para
verificar que dicha copia es la ltima versin disponible. Si no es as, uno de los
miembro de del AVSG con la ltima versin pasa a ser el sitio preferido.
Transacciones Con Datos Replicados
Transacciones Con Datos Replicados
En un sistema sin replicacin, las transacciones parecen que se realizan, una de cada vez,
siguiendo algn orden. Esto se consigue asegurando un entrelazado secuencial, equivalente
al de las transacciones de los clientes.

El efecto de las transacciones realizadas por los clientes sobre objetos replicados, deber
ser el mismo que si se hubiese realizado una por una, sobre un nico conjunto de objetos. A
esto se le denomina secuenciabilidad de una copia.

Cuando un gestor de rplicas se recupera de un fallo, utiliza la informacin que obtiene de

los otros gestores de rplicas, para restaurar sus propios objetos a sus valores actuales,
teniendo en cuenta todos los cambios que ocurrieron durante el tiempo que no estuvo
disponible.
Transacciones Con Datos Replicados

Se tratara los siguientes temas:

Implementacin de la secuenciabilidad de una copia.

Introduccin a la replicacin de copias disponibles.
Problemas de implementacin de implementar esquemas de replicacin
cuando hay varios servidores que se caen y se recuperan.
Arquitectura para Transacciones
Replicadas
Los diferentes esquemas de replicacin, tienen reglas distintas y relativas a cuntos gestores
de rplicas de un grupo son necesarios para completar con xito una operacin.
Arquitectura para Transacciones
Replicadas

Metodologas de replicaciones:

Aproximacin perezosa a la propagacin de actualizaciones.

Aplaza el paso de peticiones de actualizacin hasta que la transaccin
no se haya consumado.
Aproximacin ansiosa o acuciante.
Se enva la misma peticin de actualizacin a todos los gestores de r
rplicas.
Arquitectura para Transacciones
Replicadas

Protocolo de consumacin en dos fases

Consta de dos niveles o fases; el coordinador de una transaccin se comunica con los
trabajadores, de los cuales tanto el coordinador como los trabajadores pueden ser gestores de
replicacin, donde tendrn la capacidad de comunicarle a los otros gestores de rplica las
peticiones de una transaccin.

Dentro de la primera fase el coordinador enva el mensaje Puede Consumar? a los trabajadores
que lo pasan a los gestores y esperan la respuesta antes de responder al coordinador.

Para la segunda fase el coordinador enva la solicitud Consuma o aborta, que se pasa los
miembros de los grupos de los gestores de rplicas.
Arquitectura para Transacciones
Replicadas

Replicacin de copia primaria

En este esquema, todas las peticiones son llevadas a cabo por un nico gestor de rplica primario,
a este se le aplica el control de concurrencia. Para consumar una transaccin, el primario se
comunica con los gestores de rplicas que son copia de seguridad y luego mediante la
aproximacin ansiosa, responde al cliente.

Este mtodo de replicacin permite a un gestor de rplica de respaldo reemplazar al primario de

forma consistente si este falla. Un respaldo que reemplace a un frontal cado no necesariamente
tendra el ltimo estado de la base de datos.
Arquitectura para Transacciones
Replicadas

Uno leen/Todos Escriben

Toda operacin de escribe debe realizarse en todos los gestores des rplicas, cada uno de
los cuales establece un bloqueo de escritura sobre el objeto al que afecta la operacin. Cada
operacin de lee se realiza por un nico gestor de rplicas, el mismo establece un bloque de
lectura sobre el objeto al que afecta la operacin.

Considere parejas de transacciones distintas sobre el mismo objeto, cualquier par de

operaciones de escribe requerirn bloqueos que entrarn en conflictos en todos los gestores
de rplicas; un operacin de lee y una de escribe el bloqueo se aplicar y entrara en conflicto
en un solo gestor de rplicas. De esta forma se consigue la capacidad de secuenciacin de una
copia.
Replicacin de Copias Disponibles
El esquema de replicacin simple uno lee / todos escriben no es realista.
Cuando ms de una transaccin se est realizando sobre el mismo objeto, la ltima transaccin en
entrar debe esperar hasta que la anterior a ella se haya completado. Esto es manejado por el control
de concurrencia en cada gestor de rplica. Desafortunadamente esto no sucede si uno de los
gestores de rplica falla o se recupera mientras est en conflicto.
Replicacin de Copias Disponibles

Fallo de un gestor
Est entendido de rplicas.
que los gestores de rplicas sufren grandes daos por cada cada. Sin
embargo cada vez que esto sucede, el gestor de rplica es reemplazado por un nuevo
proceso, que recupera el estado consumando de los objetos desde un archivo de
recuperacin. Los frontales utilizan timeouts para determinar si el gestor de rplica est
disponible.

La secuencialidad de una copia requiere que las cadas y recuperacin sean secuenciadas
con respecto a las transacciones. Una transaccin observa que ha ocurrido un fallo una
vez que haya finalizado o antes que comience, en funcin de si puede acceder al objeto o
no.

La secuencialidad de una copia no se consigue cuando transacciones distintas realizan

observaciones sobre fallos que entran en conflicto.
Replicacin de Copias Disponibles

Variacin
Asegura que local.
no ocurra ningn evento asociado a un fallo o a una recuperacin durante el
desarrollo de una transaccin. Antes que se consuma una transaccin se comprueba cualquier
fallo y recuperacin en los gestores de rplica de los objetos que se ha accedido. Este mtodo
puede combinarse con el protocolo de consumacin en dos fases.

Los algoritmos para copias disponibles no pueden utilizarse en entornos, en los cuales los
gestores de rplicas que estn operando son incapaces de comunicarse entre ellos.

N falla -> T lee el objeto A en X; T escribe en el objeto B en M y P -> se Consuma T -> X

falla.

X falla -> U lee el objeto B en N; U escribe en el objeto A en Y-> se Consuma U -> N falla.
Particiones En La Red
Una particin en la red separa un grupo de gestores de rplicas en dos o ms subgrupos, de
tal forma que los miembros de cada subgrupo pueden comunicarse entre ellos, pero los
miembros de distintos grupos no pueden comunicarse.

Estos esquemas estn diseados bajo la suposicin de que las particiones sern reparadas,
por tanto no har inconsistencias al conjunto de rplicas cuando se repare la particin.
Copias Disponibles Con Validacin
El algoritmo de copias disponibles se aplica a cada particin manteniendo alta disponibilidad
para las operaciones lee. Cuando las particiones son reparadas, se valida que las
transacciones que puedan estar en conflicto y que tuvieron lugar dentro de las particiones
separadas. Si falla la validacin, deben darse algunos pasos para salvar las inconsistencias.
Si no hubiese habido particin, se retrasara o abortara una de las transacciones de las que
hayan entrado en conflicto.

Se pueden utilizar vectores de versiones para validar conflictos entre pares de operaciones
escribe. Esto son muy utilizados en sistemas de archivos donde los conflictos de lectura
escritura no son importantes.
Mtodos De Consenso Con Qurum
Un qurum es un subgrupo de rplicas que est autorizado a efectuar las operaciones, por
ejemplo en una operacin de actualizacin de un objeto lgico, podra ser completada con
xito por un subgrupo de su grupo de gestores de rplicas. Por tanto, los otros miembros del
grupo tendrn copias desfasadas del objeto. Los nmeros de versin o las marcas
temporales se podran usar para determinar si las copias estn actualizadas.

Si se usan versiones, las operaciones deberan aplicarse slo a aquellas copias que tengan
el nmero de versin actual.

La principal desventaja del consenso con qurum es que el rendimiento de las operaciones
lee se reduce a la necesidad de recoger un qurum de lectura.
Replicacin MultiMaestra
Es donde se habilitan los datos para ser distribuidos en un
grupo de computadoras, y actualizado por cualquier
miembro del grupo.
Es donde un miembro del grupo est asignado como el
"maestro" para tomas las piezas de datos y es el nico del
nodo habilitado a modificarlos.
Otros miembros solo pueden modificar los datos
comunicndose con el maestro del nodo.
Desventajas
Muchos sistemas de replicacin multimaestra son pobremente
consistentes. Ej: retardo y asincrona, violacin de propiedades ACID
Varios de los sistemas de replicacin son muy complejos y producen
latencia en la comunicacin
Problemas como resolucin de conflictos puede volverse difcil en tanto
incrementa el nmero de nodos lo cual aumenta las latencias
Ventajas
Si un maestro falla, otros maestros continuarn actualizando la base de
datos

Los maestros pueden estar en diferentes lugares fsicos. Ej: a travs de

una red distribuida
Mtodos

Basado en Log - capturar cambios hechos en las bases de datos

Basado en Trigger capturan cambios hechos para a la base de datos y los
envan al publicador. Con captura de transaccin basada en trigger, la base de
datos puede ser distribuida tanto sncronamente como asncronamente.
Implementaciones

OpenLDAP, MySQL, PostgreSQL

 Resumen
La replicacin es poder conseguir servicios con buen
rendimiento alta disponibilidad y tolerancia a fallos de
sistema distribuidos.

Aprendimos que cada objeto lgico se implementa por

medio de un conjunto de rplicas fsicas, mediante una
comunicacin de grupo tambin
Resumen
Replicacin Pasiva: la tolerancia de fallo se consigue dirigiendo
todas las peticiones a travs de los gestores de replica distinguidos y
disponiendo de un gestor de replica de despaldo que asumiera el papel si otro
.
falla
Resumen
Que tipos de fallo podemos encontrar
-Transitorio -Intermitentes -Permanentes - entre otros
Secuencia de eventos
Conocimos desde su peticin a su coordinacin tambin como es su
ejecucin, acuerdo y respuesta.
Servicio con alta disponibilidad
Debe tener un nivel de servicio aceptable utilizando un conjunto mnimo de
gestores de rplica conectados al cliente.
PREMIOS
Sistema de Arquitectura COTILLA por ?????
El Sistema de cotilla funciona a base de dos tipos de operaciones:
Consultas: Solo lectura.
Actualizaciones: Solo Escritura.
Sistema de Arquitectura BAYOU por ???
Cada gestor recibe el mismo conjunto de actualizaciones (eventualmente).
Las actualizaciones se aplican de modo que todas las rplicas sean idnticas
(eventualmente).
Premios
Sistema de Arquitectura COTILLA por

Creado por Ladin y Otros [1992].

Sistema de Arquitectura BAYOU por

Creado por Terry y Otros [1995].
Petersen y Otros [1997].