Slides for Chapter 14:
Replication
From Coulouris, Dollimore and Kindberg
Distributed Systems:
Concepts and Design
Edition 3, © Addison-Wesley 2001
Replication
 Replicação é a chave para melhorar a performance de
serviços, para garantir alta disponibilidade de serviços e
tornar serviços em SDs, tolerantes a falhas.
 Alta disponibilidade, atualmente, é de interesse crescente,
tendendo em direção à computação móvel e
conseqüentemente em modo de operação desconectada.
 Tolerância a Falhas atém-se a serviços de segurança crítica
e outros sistemas importantes.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
Replicação é amplamente usada.
Exemplos de uso:
- O “caching” de recursos de servidores Web em
browsers e servidores proxy Web é uma forma de
replicação.
- O serviço de nomeação DNS mantém cópias de
mapeamentos de nomes-para-atributos para
computadores, que servem para acessar serviços
através da Internet.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
Performance aumentada:
O “caching” de dados em clientes e servidores é
bastante conhecido, como um meio de aumentar a
performance de aplicações na Web.
- O “caching” em browsers e servidores proxy de
cópias de recursos Web, evitam a latência de busca
de recursos no servidor mantendo o recurso.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
- Dados são algumas vezes replicados
transparentemente entre servidores em um mesmo
domínio.
A carga de trabalho (“Workload”) é compartilhada
entre os servidores por ligar todos os endereços IP
de servidores ao nome DNS do “site”, digamos,
www.aWebSite.org. Um “lookup” de DNS de
www.aWebSite.org resulta em um dos endereços IP
dos diversos servidores.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
- Replicação de dados que nunca mudam é trivial:
aumenta a performance com um baixo custo para o
sistema.
- Replicação, quando dados mudam, incorre em
“overheads” na forma de protocolos projetados para
garantir que clientes receberão dados atualizados.
- “Overheads” limitam a efetividade de replicação
como uma técnica para aumentar a performance.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
Alta Disponibilidade
Usuários requerem serviços serem altamente
disponíveis. Isto é, a proporção de tempo para o
qual o serviço é acessível com tempo de resposta
razoável, de ser próximo a 100%.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
 Com exceção de, atrasos devidos a conflitos em controle
de concorrência pessimista, os fatores que são relevantes
para alta disponibilidade são:
- Falhas de servidores: replicação é uma técnica para
automaticamente manter a disponibilidade de dados
apesar das falhas de servidores.
- Partições de redes e operações desconectadas:
desconexões de comunicação que são deliberadamente
realizadas ou são frequentemente não planejadas, na
mobilidade de usuários numa rede sem fio.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
 Tolerância a Falhas
Um serviço tolerante a falha, sempre garante um
comportamento estritamente correto, apesar de um certo
número de falhas e tipo de falhas.
- Dados altamente disponíveis, nem sempre são
necessariamente estritamente corretos:
- os dados podem estar fora de data;
- dois usuários em lados opostos de uma partição
de rede podem fazer atualizações que conflitam e
precisam ser resolvidas.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
A correção diz respeito aos efeitos das operações
do cliente sobre os dados, e a atualização recente
dos dados proporcionadas por essas operações
(freshness of data), suprida ao cliente.
A corretude do serviço, também, diz respeito a
escala de tempo (que pode ser curta), quanto a
resposta do serviço.
- Exemplo: o serviço de Controle de Tráfego
Aéreo.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
A mesma técnica usada para alta disponibilidade:
replicação de dados e
funcionalidade entre computadores
é também aplicável para se alcançar tolerância a
falhas.
 Se até f, de f+1 servidores, “crash”, então em
princípio, pelo menos um servidor permanece para
suprir o serviço.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
Se até f, de f+1 servidores, podem exibir falhas
bizantinas, então em princípio um grupo de 2f+1
servidores podem prover um serviço correto, por ter
os servidores corretos substituídos os servidores
falhados.
Um sistema distribuído tolerante a falha deve
gerenciar a coordenação de seus componentes
precisamente, para manter a garantia de correção
em face de falhas, as quais podem ocorrer em
qualquer tempo.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replication
Requisitos comuns quando dados são replicados:
- transparência de replicação
- consistência dos dados:
“as operações realizadas sobre um coleção de
dados replicados produzem resultados que
satisfazem a especificação de correção para
aqueles dados”
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Consistência Forte
Consistência Forte (o mesmo que Estrita)
Garantem que todas as réplicas retém a mesma
atualização mais recente(dados autorizados) em
qualquer instante de tempo dado.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Consistência Forte
Isto é alcançado se:
1. Todas as réplicas recebem o estado atualizado.
2. Todas as réplicas processam o estado
atualizado, na mesma sequência correta
através da comunicação de grupo por
multicast.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Consistência Fraca
Dados replicados são atualizados em um servidormestre e propagados de lá para servidoresescravos, usando comunicação um-a-um, ao
contrário de comunicação em grupo.
É satisfatória para muitos propósitos, tal como
certos tipos de armazenagem de registros de
administração de sistemas.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.1
A basic architectural model for the management of replicated data
Requests and
replies
C
Clients
FE
Front ends
C
FE
RM
RM
Service
RM
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Replica
managers
A basic architectural model for the management of replicated data
Modelo de Sistema
- Dados, em nosso sistema, consistem de uma
coleção de itens, que podem ser um arquivo, ou um
objeto Java.
- Cada objeto lógico (representando um serviço) é
implementado por uma coleção de cópias físicas
chamados réplicas.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
A basic architectural model for the management of replicated data
- Réplicas são objetos físicos, cada um armazenado
em um computador, com dados e comportamento
que dizem respeito a algum grau de consistência
pela operação do sistema.
- As “réplicas” de um dados objeto podem não ser
necessariamente idênticas, pelo menos em um
dado instante no tempo. Algumas réplicas podem ter
recebido atualizações que outras não receberam,
ainda.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
A basic architectural model for the management of replicated data
Um modelo de sistema geral para gerenciar
réplicas.
Descrever um sistema de comunicação de grupo.
Particularmente úteis para alcançar tolerância a
falha através de replicação.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.2
Services provided for process groups
Group
address
expansion
Group
send
Multicast
communication
Leave
Fail
Group membership
management
Join
Process group
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.3
View-synchronous group communication
a (allowed).
b (allowed).
p crashes
p crashes
p
p
q
q
r
r
view (p, q, r)
view (q, r)
c (disallowed).
view (p, q, r)
view (q, r)
d (disallowed).
p crashes
p crashes
p
p
q
q
r
r
view (p, q, r)
view (q, r)
view (p, q, r)
view (q, r)
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Modelo de Sistema
 Assume-se um sistema assíncrono, na qual
processos podem falhar somente por “crash”.
Hipótese default: partições de rede podem não
ocorrer, mas pode-se considerar o que acontece se
partições ocorrem.
Com partições de rede é mais difícil construir
detectores de falhas, os quais usa-se para alcançar
multicast confiável, totalmente ordenado.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Modelo de Sistema
Por questões de generalidade, o modelo descreve
os componentes arquiteturiais pelos seus papéis e
não significando implicar que eles são
necessariamente implementados por processos
distintos.
O modelo envolve réplicas retidas por
gerenciadores distintos, que são componentes que
contém as réplicas sobre um dado computador e
realiza operações sobre elas diretamente.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Modelo de Sistema
Este modelo pode ser aplicado a um ambiente
cliente-servidor, no caso em que um gerenciador de
réplica é um servidor.
Pode ser aplicado a uma aplicação ou processos de
aplicação que agem como ambos, cliente e
gerenciador de réplica.
- Exemplo, o laptop de um usuário viajando num
trem pode conter uma aplicação que age como
um gerenciador de réplica para a sua agenda.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.4
The passive (primary-backup) model for fault tolerance
Primary
C
FE
RM
RM
Backup
C
FE
RM
Backup
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The passive (primary-backup) model for fault tolerance
 No modelo passivo de replicação para tolerância a falha,
existe em qualquer tempo um único gerenciador de réplica
primário e um ou mais gerenciadores de réplicas
secundários.
 Front-ends correspondem ao mecanismo para se obter
transparência de replicação). Podem ser implementados
no espaço de endereçamento do cliente ou ser um processo
separado. Neste caso, se comunicam somente com o
gerenciador de réplica primário, para realizar o serviço.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The passive (primary-backup) model for fault tolerance
 A sequência de eventos quando um cliente “requests” uma
operação a ser realizada é como segue:
1. Request: O front end emite o “request”,
contendo um único identificador de front end, ao
gerenciador de réplica primário.
2. Coordenação: O primário toma cada “request”
atomicamente, na ordem na qual ele recebe (FIFO
ordering). Ele verifica o identificador único do front-end.
Verifica se ele já executou o “request” e se assim, ele
simplesmente reenvia a resposta.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The passive (primary-backup) model for fault tolerance
3. Execução: O primário executa o “request” e
armazena a resposta.
4. Acordo: Gerenciadores de Réplicas alcançam
consenso sobre o efeito do “request”. Se existe o
consenso o “request” ele será realizado (committed).
Se o “request” é uma atualização, então o primário
envia o estado atualizado, a resposta e o
identificador único para todos os backups. Os backups
enviam um acknowledgement.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The passive (primary-backup) model for fault tolerance
5. Resposta: O primário responde ao front end, o
qual envia a resposta de volta ao cliente.
Se o primário falha, um dos backups é promovido a
agir como o primário.
O primário é substituído por um único backup.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The passive (primary-backup) model for fault tolerance
Se o primário falha, um dos backups é promovido a
agir como o primário.
O primário é substituído por um único backup.
Gerenciadores de réplicas que estão funcionando
concordam sobre quais operações foram realizadas,
no tempo quando a substituição do primário toma
lugar.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The passive (primary-backup) model for fault tolerance
O modelo primary-backup pode ser usado mesmo
onde o primário comporta-se nãodeterministicamente. Por exemplo,em operação
multi-threaded.
Um tal sistema não pode tolerar falhas bizantinas.
Se até f, de f+1 servidores, “crash”, então em
princípio, pelo menos um servidor permanece para
suprir o serviço.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The passive (primary-backup) model for fault tolerance
O front end tem pouca funcionalidade para
implementar tolerância a falha. Ele precisa ter
capacidade para procurar o novo primário quando o
primário corrente não responde.
Replicação passiva é usada no Sistema de Arquivos
Replicados Harp [Liskov et al. 1991]. O Sun Network
Information Service (NIS) usa replicação passiva
para alcançar alta disponibilidade e boa
performance.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The passive (primary-backup) model for fault tolerance
 A principal vantagem do modelo passivo de replicação é que
leituras e escritas (atualizações) são manipuladas mais
eficientemente e a recuperação em caso de falha do
servidor primário, é mais rápida.
 Neste caso, um servidor somente falha (o primário).
 Um algoritmo de eleição é executado, quando uma réplica
descobre o servidor falhado, ou ele se torna inacessível
devido a um particionamento de rede.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.5
Active replication
RM
C
FE
RM
FE
RM
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
C
Active replication
Gerenciadores de réplicas são organizados como
um grupo.
O front end “multicast” seus requests para o grupo e
todos os gerenciadores processam o request
independentemente, mas identicamente, e
respondem ao front end.
O front end coleta e compara as respostas que ele
recebe.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Active replication
O número de respostas que o front end coleta
depende do número de réplicas falhadas e do
algoritmo de multicast.
Se a meta é tolerar falhas por crash e o multicast
satisfaz a um acordo uniforme e propriedades de
ordenação, então o front end passa ao cliente a
primeira resposta que chega de volta de descarta
as demais.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Active replication
Acordo (Agreement) – em multicast confiável
Se um processo correto recebe uma mensagem m,
então todos os outros processos corretos em um
grupo g, eventualmente, receberão m.
Esta definição é relacionada a atomicidade, a
propriedade do “tudo ou nada” aplicada a entrega
de mensagens para um grupo
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Active replication
Propriedade Uniforme:
Qualquer propriedade que ocorre, se processos
são ou não corretos, é chamada de uma
propriedade uniforme.
Acordo Uniforme:
Se um processo, se correto ou com falha, recebe
uma mensagem m, então todos os processos
corretos no grupo g eventualmente receberão m.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Active replication
Sequência de eventos quando um cliente “request”
uma operação:
1. Request: O front end coloca um identificador
único ao request e multicast para o grupo de
réplicas de servidores, usando ordenação total,
com primitiva de multicast confiável. Ele não emite
o próximo “multicast” até que ele tenha recebido a
resposta.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Active replication
2. Coordenação: O sistema de comunicação de
grupo entrega o request para todo gerenciador de
réplica correto (sem falha) na mesma ordem total.
Ordem Total: Se um gerenciador de réplica
manipula r antes de r’, então qualquer gerenciador
de réplica correto que manipula r’, manipula r, antes
de r’.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Active replication
3. Execução: Todo gerenciador de réplica executa o
request identicamente.
Eles são máquinas de estado e requests são
entregues na mesma ordem total.
A resposta contém o identificador de request único
do cliente.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Active replication
4. Acordo: Nenhum acordo é necessário, por causa
da semântica de entrega do multicast.
5. Resposta: Cada gerenciador de réplica envia sua
resposta ao front end.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Active replication
Existe uma FIFO ordering quanto ao envio de
multicasts pelo front end, visto que ele sempre
espera a resposta de um multicast r antes de enviar
um multicast r’.
Replicação ativa pode tolerar falhas bizantinas,
porque o front end pode coletar e comparar as
respostas que ele recebe.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Active replication
Sistemas com replicação ativa não alcançam
linearidade, isto é porque a ordem total na qual os
gerenciadores de réplica processam os requests
não é a mesma com a ordem no tempo real no
qual os clientes fazem seus requests.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.6
Query and update operations in a gossip service
Service
RM
gossip
RM
Query, prev
Val, new
Update,prev
FE
Query
RM
Update id
FE
Val
Update
Clients
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.7
Front ends propagate their timestamps whenever clients communicate directly
Service
RM
RM
FE
gossip
Vector
timestamps
RM
FE
Clients
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.8
A gossip replica manager, showing its main state components
Other replica managers
Replica
timestamp
Gossip
messages
Replica log
Replica manager
Timestamp table
Value timestamp
Replica timestamp
Stable
Update log
Value
updates
Executed operation table
Updates
OperationID Update
FE
Prev
FE
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.9
Committed and tentative updates in Bayou
Committed
c0
c1
c2
Tentative
cN
t0
t1
t2
ti ti+1
Tentative update ti becomes the next committed update
and is inserted after the last committed update cN.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.10
Transactions on replicated data
Client + front end
Client + front end
U
T
deposit(B,3);
getBalance(A)
B
Replica managers
Replica managers
A
A
A
B
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
B
B
Figure 14.11
Available copies
Client + front end
T
Client + front end
U
getBalance(B)
deposit(A,3);
getBalance(A)
deposit(B,3);
Replica managers
B
Replica managers
Y
B
B
A
A
X
M
P
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
N
Figure 14.12
Network partition
Client + front end
Client + front end
T
withdraw(B, 4)
Network
partition
U
deposit(B,3);
B
Replica managers
B
B
B
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Page 600
Gifford’s quorum concensus examples
Example 1 Example 2 Example 3
Latency
Replica 1
(milliseconds) Replica 2
Replica 3
Voting
Replica 1
configuration Replica 2
Quorum
sizes
75
65
65
75
100
750
75
750
750
Replica 3
1
0
0
2
1
1
1
1
1
R
W
1
1
2
3
1
3
Derived performance of file suite:
Read
Latency
Blocking probability
65
0.01
75
0.0002
75
0.000001
Write
Latency
Blocking probability
75
0.01
100
0.0101
750
0.03
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.13
Two network partitions
Transaction T
Network partition
Replica managers
X
V
Y
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Z
Figure 14.14
Virtual partition
Virtual partition
Network partition
Replica managers
X
V
Y
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Z
Figure 14.15
Two overlapping virtual partitions
Virtual partition V1
Virtual partition V2
Y
X
V
Z
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 14.16
Creating a virtual partition
Phase 1:
•
The initiator sends a Join request to each potential member. The argument
of Join is a proposed logical timestamp for the new virtual partition.
•
When a replica manager receives a Join request, it compares the proposed
logical timestamp with that of its current virtual partition.
– If the proposed logical timestamp is greater it agrees to join and replies
Yes;
– If it is less, it refuses to join and replies No.
Phase 2:
•
If the initiator has received sufficient Yes replies to have read and write
quora, it may complete the creation of the new virtual partition by sending a
Confirmation message to the sites that agreed to join. The creation timestamp
and list of actual members are sent as arguments.
•
Replica managers receiving the Confirmation message join the new virtual
partition and record its creation timestamp and list of actual members.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000