Bancos de Dados III Replicação de Dados Rogério Costa rogcosta@inf.puc-rio.br 1 Replicação Processo de criar e manter réplicas de versões dos objetos da base de dados (como tabelas) em um ambiente de banco de dados distribuído 2 1
Vantagens Como o objeto existe em mais de um local, novas formas de acesso ao mesmo objeto surgem... Pode aumentar o desempenho... Acesso a dados locais ao invés de dados remotos Acesso a menos dados (caso réplica seja parcial) Redução do tráfego na rede beneficia outras aplicações Pode aumentar a disponibilidade... Se um site estiver inacessível, os dados podem ser consultados no site que contiver a réplica Computação off-line (eg. móvel) 3 Replicação de Dados Principais modelos de replicação Replicação Mestre/Escravo (Master/Slave) Replicação em Grupo Principais estratégias de propagação de dados Replicação Síncrona (Eager) Replicação Assíncrona (Lazy) 4 2
Modelos de Replicação Replicação Mestre/Escravo (Master/Slave) (1/2) Cada objeto possui somente um dono Cópia primária é aquela dona do objeto - nela podem ser realizadas leituras e atualizações. Outras cópias são secundárias - nelas somente poderão ser realizadas leituras (usualmente podemos ter mais de uma cópia secundária) 5 Modelos de Replicação Replicação Mestre/Escravo (Master/Slave) (2/2) Nós mestres - aqueles onde só existem cópias primárias, Nós escravos - aqueles onde só existem cópias secundárias Nós mestreescravo possuem cópias primárias e secundárias Um problema desta abordagem é que qualquer falha em um nó mestre impede que sejam realizadas atualizações 6 3
Modelos de Replicação Replicação em Grupo Todas as cópias são donas dos objetos, de forma que leituras e gravações podem ser realizadas em qualquer uma delas Uma falha em qualquer nó não impede o correto funcionamento dos demais. 7 Estratégias de Propagação Replicação Síncrona (Eager) (1/2) Quando realizamos a atualização em uma tabela que possui cópias, o SGBD realiza a atualização em todas as réplicas dentro da mesma transação A transação só termina quando todas as cópias do objeto tiverem sido atualizadas Sincronismo: todas as réplicas são atualizadas dentro da mesma transação considerando a propriedade da atomicidade 8 4
Estratégias de Propagação Replicação Síncrona (Eager) (2/2) Dados estão consistentes e atualizados permanentemente. Perda de performance em atualizações - está sendo realizada a atualização em várias cópias da relação antes da confirmação final da execução da transação Implementações simples: a paralisação de um site que contenha réplicas paralisa operações em todas as réplicas 9 Estratégias de Propagação Replicação Assíncrona (Lazy) (1/2) A atualização solicitada pelo cliente é realizada apenas em um nó Somente após que a transação em que esta atualização está inserida termina, são disparadas transações de atualização nos vários nós que contém réplicas É disparada uma transação para cada uma das réplicas não atualizadas. 10 5
Estratégias de Propagação Replicação Assíncrona (Lazy) ((2/2) ocorre inicialmente em um único nó como se não houvesse réplicas - uma rápida resposta ao usuário sobre a transação. Dados temporariamente desatualizados em algumas cópias, podendo levar a aparentes inconsistências Réplicas de determinado objeto em N sites, teremos N-1 transações disparadas para cada transação de atualização realizada. 11 Combinando modelos e estratégias Replicação Síncrona Mestre-Escravo Fase 1: Requisição do cliente Fase 2: Coordenação de servidores Fase 3: Execução Fase 4: Confirmação de aceitação Fase 5: Resposta ao cliente Réplica 1 Two- Phase Comm it Réplica 2 Réplica N 12 6
Combinando modelos e estratégias Replicação Síncrona Mestre-Escravo Após a solicitação do cliente, é realizada a atualização na cópia primária. Quando a atualização for realizada, mas antes da confirmação final (commit), a atualização é propagada para as réplicas secundárias. Cada réplica era necessariamente igual àquela onde foi solicitada a atualização - nessas réplicas estão sendo realizadas somente leituras Caso a cópia primária não esteja disponível, não poderão ser realizadas atualizações, embora existam cópias da primeira em um ou mais sites. 13 Combinando modelos e estratégias Replicação Síncrona em Grupo Fase 1: Requisição do cliente Fase 2: Coordenação de servidores Fase 3: Execução Fase 4: Confirmação de aceitação Fase 5: Resposta ao cliente Réplica 1 Two- Phase Commi t Réplica 2 Réplica N 14 7
Combinando modelos e estratégias Replicação Síncrona em Grupo O cliente faz uma requisição a uma cópia. Esta repassa a requisição para todas as outras. A requisição é atendida em todos os sites em paralelo. Em seguida, o protocolo Two-Phase Commit (2PC) é utilizado para confirmar o final de todas as atualizações. 15 Combinando modelos e estratégias Replicação Síncrona em Grupo Como todas as cópias são atualizáveis, clientes podem estar realizando solicitações de atualização em todas elas- possibilidade de deadlocks Sendo N o número de nós na rede e T o tamanho de uma transação, a taxa de ocorrência de deadlocks cresce com N 3 e T 5. 16 8
Combinando modelos e estratégias Replicação Assíncrona Mestre-Escravo Fase 1: Requisição do cliente Fase 2: Coordenação de servidores Fase 3: Execução Fase 4: Resposta ao cliente Fase 5: Confirmação de aceitação Réplica 1 Réplica 2 Réplica N 17 Combinando modelos e estratégias Replicação Assíncrona Mestre-Escravo (12) O usuário recebe rapidamente a confirmação de sua atualização Após essa confirmação, as cópias secundárias ficam, temporariamente, com dados distintos daqueles da cópia primária, têm seus dados atualizados 18 9
Combinando modelos e estratégias Replicação Assíncrona Mestre-Escravo (2/2) Falhas no nó mestre impedem qualquer tipo de atualização. Já falhas em cópias secundárias são, usualmente, contornáveis: quando um nó escravo que se encontrava inacessível se torna novamente disponível, são realizadas neles todas as atualizações realizadas no nó mestre durante sua ausência 19 Combinando modelos e estratégias Replicação Assíncrona em Grupo Fase 1: Requisição do cliente Fase 2: Coordenação de servidores Fase 3: Execução Fase 4: Resposta ao cliente Fase 5: Confirmação de aceitação Réplica 1 Rec onci liaçã o Réplica 2 Réplica N 20 10
Combinando modelos e estratégias Replicação Assíncrona em Grupo (1/4) Todas as cópias são atualizáveis Alterações somente são repassadas para outras cópias após a confirmação de execução para o cliente s diferentes podem estar atualizando de maneiras diferentes a mesma tupla em cópias distintas de uma determinada relação necessidade de reconciliação 21 Combinando modelos e estratégias Replicação Assíncrona em Grupo (2/4) Os conflitos podem ser de três tipos: Conflitos de Update: ocorrem quando são realizados updates na mesma tupla em réplicas diferentes aproximadamente ao mesmo tempo; Conflitos de Unicidade: ocorrem quando em diferentes réplicas são incluídas tuplas com o mesmo valor de um atributo marcado com uma constraint única; Conflitos de Exclusão: ocorre quando uma tupla é excluída em uma réplica e sofre um update em outra 22 11
Combinando modelos e estratégias Replicação Assíncrona em Grupo (3/4) Várias possíveis estratégias de reconciliação Baseadas em timestamp: onde operações realizadas anteriormente são priorizadas em detrimento das posteriores Baseadas em níveis de prioridade atribuídos as cópias - operações realizadas em cópias de determinados sites de mais alto nível de prioridade são mantidas e às realizadas em sites de nível mais baixo são descartadas 23 Combinando modelos e estratégias Replicação Assíncrona em Grupo (4/4) Várias possíveis estratégias de reconciliação Em geral, sistemas implementam algum método automático de resolução de conflitos, mas deixam que o usuário tome a decisão de qual deve ser a versão verdadeira em casos em que não possam decidir. Usuário que recebeu uma confirmação de atualização realizada com sucesso, pode ter sua atualização anulada posteriormente devido a uma estratégia de reconciliação... 24 12
Exemplos - Oracle Peer-to-peer/Multi-master replication Cada site é considerado master aplicações podem atualizar dados em qualquer site Propagação das atualizações entre os sites: Assíncrona ocorre sob demanda ou em intervalos regulares pré-programados (conflitos podem ocorrer depois de terminada a transação...) Síncrona ocorre no momento da atualização 25 Exemplos - Oracle Peer-to-peer/Multi-master replication 26 13
Exemplos - Oracle Snapshot / Materialized View Existe uma versão master do objeto a ser replicado e uma (ou mais) versões que são snapshot ou materialized view Somente a versão master pode ser atualizada pela aplicação Propagação das atualizações entre os sites: Assíncrona ocorre sob demanda ou em intervalos regulares préprogramados (conflitos podem ocorrer depois de terminada a transação...) Síncrona ocorre no momento da atualização 27 Exemplos - Oracle Snapshot / Materialized View 28 14
Exemplos - Oracle Híbrida 29 Questões O que replicar? Onde posicionar as réplicas? Onde ocorrem as atualizações (multimaster X snapshot)? Qual o mecanismo de propagação? Podem ocorrer conflitos? (síncrono X assíncrono) 30 15