Sistemas Distribuídos · 2018. 1. 30. · Sistemas Distribuídos Replicação Vinícius Fernandes...

Sistemas Distribuídos

Replicação

Vinícius Fernandes Soares Mota

O Papel da replicação

DECSI/ICEA UFOP

Melhorando serviços com dados replicados• Balanceamento de carga

• carga de trabalho é compartilhada entre servidores amarrando-se vários IPs a um único nome de DNS. Endereços IP são retornados utilizando uma política tipo round-robin.

DECSI/ICEA UFOP

Melhorando serviços com dados replicados• Balanceamento de carga

• carga de trabalho é compartilhada entre servidores amarrando-se vários IPs a um único nome de DNS.

DECSI/ICEA UFOP

Melhorando serviços com dados replicados• Tolerância à falha

• se f de f + 1 servidores falham, pelo menos um mantém-se ativo e provendo o serviço

• Aumento da disponibilidade• serviço pode não estar disponível quando servidores

falham ou quando a rede é particionada

DECSI/ICEA UFOP

Melhorando serviços com dados replicados• Aumento da disponibilidade

P: probabilidade de falha de um servidor

1 – P: disponibilidade do serviço

Por exemplo, se P = 5%

Serviço está disponível 95% do tempo.

Pn: probabilidade de n servidores falharem

1 – Pn: disponibilidade do serviço

por exemplo, se P = 5%, n = 3

=> serviço está disponível 99.875% do tempo

DECSI/ICEA UFOP

Detectando falhas - Exercício

• Três computadores juntos fornecem um serviço replicado. Os fabricantes dizem que cada computador tem um tempo médio entre falhas de cinco dias; normalmente, uma falha demora quatro horas para ser corrigida. Qual é a disponibilidade do serviço replicado?

DECSI/ICEA UFOP

Detectando falhas - Exercício

• Três computadores juntos fornecem um serviço replicado. Os fabricantes dizem que cada computador tem um tempo médio entre falhas de cinco dias; normalmente, uma falha demora quatro horas para ser corrigida. Qual é a disponibilidade do serviço replicado?

DECSI/ICEA UFOP

Probabilidade Falha individual = 4/(5*24 ) ~ 0.03.

Disponibilidade do serviço:

1 – 0.033 = 0.999973.

Modelo arquitetural básico para o gerenciamento de dados replicados

Requisições

e respostas

ReplicaC

ServiçoClientes Front ends

managers

Transparência de replicaçãousuário/cliente não precisa saber que existem diversas cópias do recurso

Consistência de replicaçãoos dados são consistentes entre todas as réplicas, ou estão no processo de se

tornarem consistentes

DECSI/ICEA UFOP

Gerenciamento de replicação

• 5 Fases que afetam o desempenho de acesso a objetos replicados

• Requisição

• Coordenação

• Execução

• Acordo

• Resposta

DECSI/ICEA UFOP

• Requisições- requisições podem ser feitas a um RM

- Via multicast a múltiplos RM

• Coordenação: os RM devem decidir:- se a requisição será aplicada

- a ordem em que as requisições serão aplicadasordem FIFO: se um FE envia uma requisição r e então uma requisição r’, então toda RM deve tratar r e depois r’ordem causal: se a requisição r “happens-before” r’, então toda RM deve tratar r e depois r’ordem total: se uma RM trata r e depois r’, então todas as RM devem tratar r e depois r’

• Execução: Tentativas de executar a requisição

DECSI/ICEA UFOP

• Acordo/Consenso: • as RMs tentam alcançar o consenso sobre o efeito da requisição

• exemplo: Two-phase commit através de um coordenador

• se bem sucedido, a requisição se torna permanente

• Resposta: • uma ou mais RM respondem ao FE

• o FE retorna a primeira resposta obtida

DECSI/ICEA UFOP

Comunicação de grupos

• Grupos estáticos: membros são pré-definidos

• Grupos dinâmicos: membros podem entrar (join) e sair (leave) do grupo

• Um serviço de gerenciamento de membros em um grupo mantém visões de grupo (views):• listas dos membros atuais do grupo

• não é uma lista mantida por um membro, mas cada membro possui sua view local

DECSI/ICEA UFOP

Modo de visualização - Views

• Uma view Vp(g) é o entendimento do processo p de seu grupo (lista de membros)

Exemplo: Vp.0(g) = {p}, Vp.1(g) = {p, q}, Vp.2 (g) = {p, q, r}, Vp.3 (g) = {p,r}

• Uma nova view é disseminada através do grupo sempre que um membro entra ou sai do grupo• membros que detectarem uma falha de um outro

membro, envia um multicast confiável notificando a mudança da view (requer ordem total para multicasts)

• Mensagens enviadas em uma view devem ser enviada a todos os membros do grupo

DECSI/ICEA UFOP

• Requisitos para entrega de uma view• Ordem: se p entrega uma vi(g), e então uma vi+1(g),

então nenhum outro processo q envia vi+1(g) antes de vi(g)

Garantia de consistência

• Integridade: se p envia vi(g), então p está na view vi(g)

Garantia de sanidade

• Não trivialidade: se o processo q entra em uma view e se torna alcançável pelo processo p, então, eventualmente, q estará sempre presente nas viewsentregues a p

Previne soluções triviais

DECSI/ICEA UFOP

Comunicação síncrona em uma view• Usa serviço de comunicação de grupo + multicast

confiável

• Garantias providas pelo protocolo multicastconfiável:

• Integridade: se p enviou a mensagem m, p não irá enviar mnovamente, e p grupo(m).

• Validade: processos corretos sempre entregam todas as suas mensagens

• Acordo/Consenso: processos corretos entregam o mesmo conjunto de mensagens em uma view

DECSI/ICEA UFOP

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5

Grupos de comunicação

DECSI/ICEA UFOP

Considere um grupo com três processos p, q e r .Suponha que p envie uma mensagem m enquanto está no modo de visualização (p, q, r);P falha após o envio

DECSI/ICEA UFOP

Considere um grupo com três processos p, q e r .Suponha que p envie uma mensagem m enquanto está no modo de visualização (p, q, r);P falha após o envio

p crashes

view (q, r)view (p, q, r)

p crashes

a (Permitido). b (Permitido).

p crashes

a (Permitido). b (Permitido).

view (p, q, r)

p crashes

c (Proibido). d (Proibido).

p crashes

view (q, r)

DECSI/ICEA UFOP

Serviços Tolerantes a Falhas

• como fornecer um serviço correto quando ocorrer falhas?• Supõe-se que cada gerenciador de réplica se comporta

de acordo com os objetos que gerencia

• Exemplo: contas bancárias incluiria a garantia de que os fundos transferidos entre as contas nunca poderia desaparecer

DECSI/ICEA UFOP

• como fornecer um serviço correto quando ocorrer falhas?• Supõe-se que cada gerenciador de réplica se comporta

de acordo com os objetos que gerencia

• Exemplo: contas bancárias incluiria a garantia de que os fundos transferidos entre as contas nunca poderia desaparecer

• Podem surgir anomalias quando houver vários gerenciadores de réplicas

DECSI/ICEA UFOP

• Inicialmente, x = y = 0

• Cliente 1 atualiza objeto x em uma réplica B

• Réplica B falha

DECSI/ICEA UFOP

• Inicialmente, x = y = 0

• Cliente 1 atualiza objeto x em uma réplica B

• Réplica B falha

DECSI/ICEA UFOP

Houve atualização de X no servidor B

X não foi atualizado no servidor A

• Entender o que é um comportamento correto em um sistema replicado

• Como “serializar” as operações?

• Critérios de correção para objetos replicados:• Capacidade de linearização

• Interposição das operações para todos os clientes, para qualquer operação.

• Consistência sequencial• Interposição das operações

DECSI/ICEA UFOP

Capacidade de linearização

• Um serviço de compartilhamento de objetos replicado é dito linearizável se

• Obedecem à especificação de uma única cópia do objeto

• É consistente com os tempos reais com que cada operação ocorreu durante a execução

DECSI/ICEA UFOP

• A capacidade de linearização diz respeito à interposição de operações individuais e não se destina a ser transacional.

• Uma execução que pode ser linearizada pode violar as noções de consistência específicas da aplicação, caso não seja aplicado controle de concorrência.

DECSI/ICEA UFOP

• O exemplo anterior não pode ser linearizado

• Não há interposições das operações que leve ao resultado correto

DECSI/ICEA UFOP

• Linearização é difícil (ou quase impossível) de ser alcançada em sistemas reais

• Um critério menos restritivo é o de consistência sequencial

DECSI/ICEA UFOP

Consistência sequencial

• Um serviço de compartilhamento de objetos replicado é sequencialmente consistente se, para qualquer execução (real) existe alguma intercalação de operações do cliente (virtual) que:

• Obedecem à especificação de uma única cópia do objeto

• É consistente com ordem individual em que cada cliente executou a operação

DECSI/ICEA UFOP

• Não exige ordenação total ou tempo absoluto.

• Para cada cliente, a ordem de execução da sua sequencia de operações deve ser consistente com a ordem do programa (~FIFO)

• Linearização implica em consistência sequencial, mas não vice versa• Como garantir consistência sequencial: garantindo que todas as

réplicas de um objeto sejam consistentes.

DECSI/ICEA UFOP

O critério do tempo real para a capacidade de linearização

não é satisfeito, pois getBalanceA(x) 0 ocorre depois de

setBalanceB(x,1);

A interposição das operações do Cliente 2 serem

executadas antes do cliente 1 satisfaz os dois critérios da

consistência sequencial:

getBalanceA(y) 0, getBalanceA(x) 0

setBalanceB(x, 1), setBalanceA(y, 2).

Modelo de tolerância à falhas baseado em replicação passiva (backup primário)

Primary

Backup

DECSI/ICEA UFOP

Replicação passiva (backup primário)• Comunicação: a requisição é encaminhada para o RM primário e

possui um único identificador de requisição

• Coordenação: o RM primário recebe todas as requisições atomicamente, em ordem, checa o id (reenvia resposta se não é novo identificador)

• Execução: RM primário executa e armazena as requisições

• Acordo/Consenso: se é atualização, RM primário envia estado atualizado/resultado do objeto, identificador de requisição e resposta para todos os RM de backups (1-phase commit).

• Resposta: RM primário envia resposta ao front end

DECSI/ICEA UFOP

Tolerância à falhas na replicação passiva• Implementa linearização

• Se RM primário falha, um backup se torna o líder por eleição e as RM que sobreviveram concordam sobre o conjunto de operações que foram realizados até o ponto em que o novo líder assume• requisito é alcançado se as RM estão organizadas como

um grupo e a réplica primária utiliza visão síncrona de grupo para comunicar updates

• O sistema permanece linearizável após a queda do servidor primário

DECSI/ICEA UFOP

Replicação ativa

FE CFEC RM

DECSI/ICEA UFOP

Replicação ativa

1. Comunicação: a requisição contém um identificador único e é enviada por multicast confiável ordenado a todos os RM

2. Coordenação: comunicação de grupo garante que as requisições são entregues a cada RM na mesma ordem (pode ser em instantes físicos diferentes)

3. Execução: cada réplica executa a requisição (réplicas corretas retornam a mesma resposta)

4. Acordo/consenso: não é necessário acordo, devido às primitivas semânticas do multicast

5. Resposta: cada réplica envia a resposta diretamente para o front end

DECSI/ICEA UFOP

Tolerância à falhas na replicação ativa• RM exercem papeis equivalente -> respondem a uma

sequencia de requisições da mesma forma

• Se alguma RM cai, o estado é mantido pelas demais RMscorretas

• Implementa consistência sequencial

• Ordenação total de requisições garante que todas as réplicas executem a mesma sequencia de requisições

• Cada requisição do front end é executada na ordem FIFO, porque o FE espera pela resposta para fazer nova requisição

DECSI/ICEA UFOP

Serviços de alta Disponibilidade

Sistemas que oferecem serviços de alta disponibilidade

•Gossip

•Bayou

•Coda

DECSI/ICEA UFOP

Arquitetura Gossip (Fofoca)

• Desenvolvida para implementar serviços de alta disponibilidade por meio da replicação de dados próximos aos pontos onde os grupos de clientes precisam deles

• Os gerenciadores de réplicas trocam mensagens periodicamente para transmitir as atualizações que cada um recebeu dos clientes

• Oferece dois tipos básicos de operação: • somente de leitura

• atualizações que modificam mais não leem o estado.

DECSI/ICEA UFOP

Arquitetura Gossip (Fofoca)

• Vantagem • Clientes podem continuar a obter um serviço mesmo

quando são separados do resto da rede• Desde que pelo menos um gerenciador de réplica continue a

funcionar na partição.

• Desvantagem • Escalabilidade de seu sistema

• a medida que o número de gerenciadores de réplica aumenta, também aumenta o número de mensagens de fofoca.

DECSI/ICEA UFOP

Operações de consulta (query) e updates no serviço gossip

Query Val

Query, prev Val, new

Update

Update, prev Update id

Clients

gossip

DECSI/ICEA UFOP

Operações de consulta (query) e updates no serviço gossip

Query Val

Query, prev Val, new

Update

Update, prev Update id

Clients

gossip

DECSI/ICEA UFOP

1. Requisição

2. Resposta de atualização

3. Coordenação

4. Execução

5. Resposta de Consulta

6. Acordo

Carimbo de tempo

Clients

Service

Vector

timestamps

gossip

DECSI/ICEA UFOP

Front ends propagam seus timestamps sempre que um cliente se comunica diretamente

Os componentes principais do estado de uma RM gossip

Other replica managers

Replica timestamp

Update log

Value timestamp

Executed operation table

Stable

updates

Updates

Gossip

messages

Replicatimestamp

Replica log

OperationID Update Prev

Replica manager

Timestamp table

DECSI/ICEA UFOP

Processamento das operações

• Front-end envia a requisição

• RM verifica se já não processou baseado na tabela de operações realizadas

• Se não processou, incrementa seu relógio

• Atribui um carimbo de tempo da operação

• Armazena a operação no log

• Verifica se a atualização é estável (ao receber as msg gossip de outros RMs)

• Realiza as atualizações

DECSI/ICEA UFOP

Ao receber uma mensagem Gossip

• Integrar o log recebido com o seu próprio

• Aplicar as atualizações que se tornaram estáveis e não foram executadas antes

• Eliminar registros do log e entradas na tabela de operações executadas• Quando for conhecido que as atualizações foram

aplicadas por toda parte e para as quais não há perigo de repetições

• Entradas redundantes

DECSI/ICEA UFOP

Replica timestamp

Update log

Value timestamp

Stable

updates

Updates

Gossip

messages

Replicatimestamp

Replica log

Replica manager

Timestamp table

DECSI/ICEA UFOP

• mantém as atualizações em um log

• Realiza apenas atualizações consistentes com suas garantias de ordenação

• Mantem no log até que outras réplicas também tenham recebido a atualização

Replica timestamp

Update log

Value timestamp

Stable

updates

Updates

Gossip

messages

Replicatimestamp

Replica log

Replica manager

Timestamp table

DECSI/ICEA UFOP

• Carimbo de tempo vetorial

• Atualizações que foram aceitas pelo gerenciador de réplica

Replica timestamp

Update log

Value timestamp

Stable

updates

Updates

Gossip

messages

Replicatimestamp

Replica log

Replica manager

Timestamp table

DECSI/ICEA UFOP

valor do estado da

aplicação

Replica timestamp

Update log

Value timestamp

Stable

updates

Updates

Gossip

messages

Replicatimestamp

Replica log

Replica manager

Timestamp table

DECSI/ICEA UFOP

carimbo de tempo vetorial que representa as atualizaçõesrefletidas no valor

Replica timestamp

Update log

Value timestamp

Stable

updates

Updates

Gossip

messages

Replicatimestamp

Replica log

Replica manager

Timestamp table

DECSI/ICEA UFOP

• Contém um carimbo de tempo vetorial de todos os outros gerenciadores de réplica

• Preenchido com carimbos de tempo que chegam deles em mensagens de fofoca

Replica timestamp

Update log

Value timestamp

Stable

updates

Updates

Gossip

messages

Replicatimestamp

Replica log

Replica manager

Timestamp table

DECSI/ICEA UFOP

• impede que uma atualização seja aplicada duas vezes

• contendo os identificadores únicos, fornecidos pelo front-end

Considerações sobre o Gossip

• Depende do tempo entre as mensagens gossip• Muito alto: Inunda a rede

• Muito baixo: Pode inviabilizar sistemas de tempo real

• Escalabilidade• R gerenciadores de réplica normalmente reúne G

atualizações em uma mensagem de fofoca, então o número de mensagens trocadas é de

2 + (R – 1)/G.

DECSI/ICEA UFOP

• Garantia de disponibilidade menor que Gossip

• Suporta conectividade variável

• Permite a detecção/solução de conflitos

DECSI/ICEA UFOP

• Mantido na forma de um banco de dados

• consultas e atualizações

• Desfaz e refaz as atualizações no banco de dados

• cada gerenciador de réplica receberá o mesmo conjunto de atualizações e aplicará essas atualizações de maneira tal que os bancos de dados dos gerenciadores de réplica sejam idênticos

DECSI/ICEA UFOP

Committed updates e tentativeupdates no Bayou• Atualizações são marcadas como de tentativa

quando são aplicadas a um banco de dados pela primeira vez• o sistema pode desfazê-las e reaplicá-las

• Atualizações de tentativa são colocadas em uma ordem canônica, e após aplicadas são confirmadas• permanecem aplicadas em sua ordem definida.

DECSI/ICEA UFOP

Committed updates e tentativeupdates no Bayou

c0 c1 c2 cN t0 t1 ti

Committed Tentative

Tentative update ti se torna o próximo committed update

E é inserido após o último committed update cN.

DECSI/ICEA UFOP

Considerações Bayou

• Voltado para aplicações de “co-working”• Focar que o que foi feito por um usuário, não conflite

com outro

• Maior complexidade para o desenvolvedor • precisa fornecer verificações de dependência e

procedimentos de integração

• Maior complexidade para o usuário• Usuário pode lidar com dados que ainda não foram

confirmados

DECSI/ICEA UFOP

Sistema de arquivos Coda

• Um sistema de arquivo distribuído com réplicas

• Desenvolvido na Universidade de Carnegie Melon

DECSI/ICEA UFOP

Arquitetura CODA

• Venus Cliente

• Vice Servidores

DECSI/ICEA UFOP

Estratégia de replicação do CODA

• Permite que a modificação dos arquivos prossiga quando a rede é particionada ou durante a operação desconectada

• Mantém histórico de atualização de cada réplica de arquivo• Histórico baseado em carimbo de tempo

• Permite que conflitos em potencial possam ser detectados e submetidos à intervenção manual

DECSI/ICEA UFOP

Estratégias de replicação

• Gossip

• Focado em manter todos os servidores atualizados

• Bayou

• Focado em resolver conflitos

• Permite que usuários operem “offline”

• CODA

• Sistema de arquivo distribuído

DECSI/ICEA UFOP

Transações em dados replicados

• Uma transação sobre objetos replicados deve ser idêntica à dos objetos não replicados.• capacidade de serialização de uma cópia

• Principais problemas• se a requisição de um cliente pode ser tratada em

qualquer um dos gerenciadores de réplica;

• se o gerenciador de réplica contatado por um cliente pode adiar o encaminhamento das requisições até que uma transação seja confirmada

• como executar um protocolo de confirmação de duas fases.

DECSI/ICEA UFOP

Arquitetura para Transações replicadas

Client + front end

BB BA A

getBalance(A)

Client + front end

Replica managersReplica managers

deposit(B,3);

DECSI/ICEA UFOP

Um lê/Todos EscrevemRead-one/write all

Arquitetura para Transações replicadas• Estratégia preguiçosa de atualização

• gerenciador de réplica adia o encaminhamento das requisições de atualização para outros gerenciadores de réplica do grupo, até que uma transação seja confirmada

• Estratégia ávida de atualização• encaminha cada requisição de atualização para todos os

gerenciadores de réplica necessários dentro da transação e antes de confirmar

DECSI/ICEA UFOP

Arquitetura para Transações replicadasProtocolo de confirmação de duas fases

• Primeira fase:• coordenador envia a requisição de canCommit? para os

operários,

• os quais a passam para os outros gerenciadores de réplica e reúnem suas respostas, antes de responder para o coordenador.

• Segunda fase:• o coordenador envia a requisição de doCommit ou

doAbort, a qual é passada para os membros dos grupos de gerenciadores de réplica.

DECSI/ICEA UFOP

Replicação Cópias disponíveis

Client + front end

Replica managers

deposit(A,3);

deposit(B,3);

getBalance(B)

getBalance(A)

Replica managers

DECSI/ICEA UFOP

O que acontece se um servidor falhar antes de replicar?

Client + front end

Replica managers

deposit(A,3);

deposit(B,3);

getBalance(B)

getBalance(A)

Replica managers

DECSI/ICEA UFOP

X e N falham após a operação getBalance

Client + front end

Replica managers

deposit(A,3);

deposit(B,3);

getBalance(B)

getBalance(A)

Replica managers

DECSI/ICEA UFOP

• O controle de concorrência de A no gerenciador de réplica X não impede que a transação U atualize A no gerenciador de réplica Y.

• O controle de concorrência de B no gerenciador de réplica N impede que a transação T atualize B nos gerenciadores de réplica M e P

Partição de rede

Client + front end

withdraw(B, 4)

Client + front end

Replica managers

deposit(B,3);

UTNetwork

partition

DECSI/ICEA UFOP

Partição de rede

• Estratégia otimista• permitem atualizações em todas as partições

• Pode levar a inconsistências entre as partições, as quais deverão ser resolvidas quando o particionamento for reparado

• Estratégia pessimista• limita a disponibilidade

• mas impede a ocorrência de inconsistências durante o particionamento

DECSI/ICEA UFOP

Partição de rede

• Em caso de partição deve-se estabelecer regras que as operações só sejam executadas em uma partição

• Protocolo de consenso de Quórum• Um quorum é um subgrupo degerenciadores de réplica

cujo tamanho proporciona a ele o direito de executar operações.

DECSI/ICEA UFOP

Protocolo Quorum Consensus

Sistema de Quóruns:

• Conjunto de subconjuntos das réplicas, tal que quaisquer dois subconjuntos se intersectam.• N réplicas -> Quórum: qualquer maioria: |Q|>N/2

• Cada réplica guarda:• valor do objeto (registo)

• Timestamp e versão

• A cópia mais atualizada mantém a versão corrente

73DECSI/ICEA UFOP

• Operação de Leitura• Envia pedido de leitura para todas as réplicas

(retransmitindo-o até concluir a operação, para superar falhas temporárias na rede)

• Ao receber pedido, • réplica responde ao cliente comvalor atual de <val,ts>

• Cliente aguarda resposta de um quórum

• Escolhe valor associado ao maior timestamp

74DECSI/ICEA UFOP

• Operação de Escrita (2 fases – leitura e escrita)• Efetua pedido de leitura a todas as réplicas (ler

timestamp atual)

• Aguarda resposta de um quórum

• Escolha o maior timestamp, t, e incrementa

• Efetua um novo pedido a todas as réplicas para escrever <novo-val, t+1>

• Servidores respondem ack, e apenas guardam novo-valse o timestamp for maior do que o atual

• Cliente aguarda acknowledge de um quórum

75DECSI/ICEA UFOP

• Problema: • Duas escritas concorrentes podem escolher o mesmo

timestamp

• Solução: timestamp = <Nº seq., client-id>

76DECSI/ICEA UFOP

Cenários para o protocolo Quorum concensus de Gifford

Example 1 Example 2 Example 3

Latency Replica 1 75 75 75

(milliseconds) Replica 2 65 100 750

Replica 3 65 750 750

Voting Replica 1 1 2 1

configuration Replica 2 0 1 1

Replica 3 0 1 1

Quorum R 1 2 1

sizes W 1 3 3

Derived performance of file suite:

Read Latency 65 75 75

Blocking probability 0.01 0.0002 0.000001

Write Latency 75 100 750

Blocking probability 0.01 0.0101 0.03

DECSI/ICEA UFOP

Protocolo Quorum Consensus de Gifford• Vantagens:

• Primeiro protocolo que tolera falhas silenciosas em sistemas assíncronos

• Réplica que falhe temporariamente e recupera está imediatamente pronta para participar

• Ficará naturalmente atualizada quando receber próximo pedido de escrita

• Desvantagens:• À medida que os nós falham, há uma degradação da

disponibilidade.

• Quoruns são grandes

DECSI/ICEA UFOP

Concluindo

• Replicação visa aumentar a disponibilidade do sistema

• As réplicas devem manter consistência entre si

• A replicação pode ser passiva ou ativa

• Transações com dados replicados podem usarreplicação passiva• Em caso de partição, protocolo consensus permite as

operações nas cópias disponíveis

DECSI/ICEA UFOP

Questões

DECSI/ICEA UFOP

Vinícius Fernandes Soares Mota

Replicação

Sistemas Distribuídos · 2018. 1. 30. · Sistemas Distribuídos Replicação Vinícius Fernandes...

Documents

Transcript of Sistemas Distribuídos · 2018. 1. 30. · Sistemas Distribuídos Replicação Vinícius Fernandes...

Aula Medicina - Replicação Viral

Aula 10 replicação viral - texto

Resumo - Replicação e Transcrição

Aula 3 Replicação DNA Oceano

3 ª ReplicaçãO Leitura2

Técnicas de Replicação

3 ª ReplicaçãO Leitura3

MongoDB - Replicação

UNIFAL - MySQL 5.6 - Replicação

Modelo Tcc Decsi Atual

Vírus: Características Gerais e Replicação

REPLICAÇÃO DE DNA

Apresentação 5ª replicação

Sistemas Distribuídos - Replicação de Banco de Dados

Replicação do DNA

Estrutura, Morfologia e Replicação Viral

FERRAMENTA PARA REPLICAÇÃO DE DADOS NO SGBD …campeche.inf.furb.br/tccs/2007-I/2007-1... · O trabalho engloba os temas sistemas distribuídos, banco de dados, PostgreSQL, replicação

Replicação de DNA

Fundamentos Replicação MySQL

Aula Teórica - Estrutura e Replicação