Segundo Coulouris et al. (2013) replicação é a chave para prover alta disponibilidade e tolerância a falhas em sistemas distribuídos. A alta disponibilidade é um tópico de crescente interesse, principalmente com a atual tendência em direção à computação móvel e à operação desconectada. A tolerância a falhas é uma preocupação permanente dos serviços fornecidos em sistemas nos quais a segurança funcional (safety) é fundamental e em outros tipos importantes de serviços e sistemas.

A replicação é uma técnica para melhorar serviços. As motivações para a replicação são: melhorar o desempenho de um serviço, aumentar sua disponibilidade ou torná-lo tolerante a falhas.

• Melhoria de desempenho: a colocação dos dados em cache de clientes e servidores é uma maneira conhecida de melhorar o desempenho.

A replicação de dados imutáveis é simples: ela aumenta o desempenho com pouco custo para o sistema. A replicação de dados mutáveis (dinâmicos), como os da Web, acarreta sobrecargas nos protocolos para garantir que os clientes recebam dados atualizados. Assim, existem limites para a eficácia da replicação como uma técnica de melhoria de desempenho.

• Tolerância a falhas: dados de alta disponibilidade não são necessariamente dados rigorosamente corretos. Eles podem estar desatualizados, por exemplo, ou dois usuários em lados opostos de uma rede que foi particionada podem fazer atualizações conflitantes e que precisem ser resolvidas. Em contraste, um serviço tolerante a falhas sempre garante comportamento rigorosamente correto, apesar de certo número e tipo de falhas. A correção está relacionada ao caráter atual dos dados fornecidos para o cliente e aos efeitos das operações do cliente sobre os dados. Às vezes, a correção também está relacionada ao tipo de respostas do serviço – como, por exemplo, no caso de um sistema de controle de tráfego aéreo, no qual dados corretos são necessários em escalas de tempo curtas.

A replicação de dados pode ser realizada via software, quando nos referimos há algumas linhas específicas numa determinada tabela ou ainda um banco de dados. Por outro lado, quando precisamos replicar um volume ou um disco, é comum recorrermos a replicação de hardware.

O uso da replicação permite o uso de vários níveis de granularidade. A replicação de banco de dados, por exemplo, permite desde a replicação de algumas linhas ou colunas específicas até um conjunto de várias tabelas ou eventualmente um banco de dados inteiro.

A replicação de dados é uma das tecnologias mais empregadas para a construção de banco de dados distribuídos.

A replicação é uma técnica para manter automaticamente a disponibilidade dos dados, a despeito das falhas do servidor. Se os dados são replicados em dois ou mais servidores que falham independentemente, então o software cliente pode acessar os dados em um servidor alternativo, caso o servidor padrão falhe ou se torne inacessível.

Exemplo de replicação de dados

Inicialmente a aplicação submete instruções de escrita (insert, update, delete) para o banco de dados. Alterando, posteriormente esse banco de dados é replicado para suas quatro cópias, mantendo-as sincronizadas. Considerando que as réplicas são idênticas ao banco de dados original, uma consulta pode ser feita em qualquer uma das réplicas provendo assim cenários de alta disponibilidade e escalabilidade. A indisponibilidade do banco principal, não compromete as consultas. Uma vez que o banco principal esteja disponível, é possível redirecionar as operações de escritas para uma das réplicas.

• Prover disponibilidade do dado em outros sites no caso da queda do principal.
• Diminuir a contenção em um único site, uma vez que o dado em múltiplos sites evita a concentração de acessos.
• Possibilitar processamento paralelo distribuído entre os sites.
• Melhorar o desempenho aproximado do dado do seu consumidor, evitando assim atrasos na transmissão em links considerados lentos.
• Permitir o uso dos dados em aplicações desconectadas, pois essas podem trabalhar de forma off-line e replicar os dados posteriormente.

Servidores trabalham com um modelo de gerenciador de réplicas, esse gerenciador tem o papel de:

Coordenar o processo de replicação:

• Manter a consistência de estado e transparência do conjunto dos servidores.
• Manter o controle da concorrência;
• E fazer o controle de falhas de servidores.

Tipos de Replicação:

• Replicação passiva;
• Replicação ativa.

No modelo passivo, ou de backup primário, de replicação para tolerância a falhas, existe, em determinado momento, um único gerenciador de réplica (RM) primário e um ou mais gerenciadores de réplica secundários – backups ou escravos. Na forma pura do modelo, os front-ends (FE) se comunicam somente com o gerenciador de réplica primário para obterem o serviço. O gerenciador de réplica primário executa as operações e envia cópias dos dados atualizados para os backups. Se o primário falhar, um dos backups será promovido para atuar como primário.

1. A sequência de eventos, quando um cliente solicita que uma operação seja executada, é a seguinte:
2. Requisição: o front-end emite a requisição, contendo um identificador exclusivo, para o gerenciador de réplica primário.
3. Coordenação: o gerenciador primário trata cada requisição atomicamente, na ordem em que a recebe. Ele verifica o identificador exclusivo, para o caso de já a ter executado e, se assim for, simplesmente envia a resposta novamente.
4. Execução: o gerenciador primário executa a requisição e armazena a resposta.
5. Acordo: se a requisição é uma atualização, o gerenciador primário envia o estado atualizado, a resposta e o identificador exclusivo para todos os gerenciadores de backup. Os gerenciadores de backup enviam uma confirmação.
6. Resposta: o gerenciador primário responde para o front-end, o qual envia a resposta de volta para o cliente.

Detecção de falha do primário

• Cliente estabelece timeout para requisição;
• Backups fazem verificação (keepalive).

Solução: Um novo primário é eleito.

Casos:

• Antes de iniciar o update;
• Durante ou após o update, mas antes de enviar a resposta ao cliente;
• Após enviar a resposta ao cliente.

Vantagens e desvantagens da Replicação Passiva

Vantagens:

• Réplicas não precisam obter sempre o mesmo efeito para uma certa requisição.
• Interação simples entre cliente e servidor.

Desvantagens:

• A frequência de checkpoints pode prejudicar o desempenho do serviço replicado.

       Solução: fazer update a cada n requisições.

• Cliente retransmite requisições entre o último update realizado e a falha do primário.
• Um mecanismo de log em disco armazena todas as requisições desde o último checkpoint.

No modelo ativo de replicação para tolerância a, os gerenciadores de réplica são máquinas de estado que desempenham papéis equivalentes e são organizados como um grupo. Os front-ends enviam suas requisições por multicast para o grupo de gerenciadores de réplica, e todos os gerenciadores de réplica processam a requisição independentemente, mas de forma idêntica, e respondem. Se qualquer gerenciador de réplica falhar, isso não tem nenhum impacto sobre o desempenho do serviço, pois os gerenciadores de réplica restantes continuam a responder normalmente. Veremos que a replicação ativa pode tolerar falhas bizantinas, pois o front-end pode reunir e comparar as respostas que recebe.

Sob a replicação ativa, a sequência de eventos quando um cliente solicita a execução de uma operação é a seguinte:

1. Requisição: o front-end anexa um identificador exclusivo à requisição e a envia por multicast para o grupo de gerenciadores de réplica, usando uma primitiva de multicast totalmente ordenada e confiável. Supõe-se que o front-end pode falhar por colapso, na pior das hipóteses. Ele não emite a próxima requisição até que tenha recebido uma resposta.
2. Coordenação: o sistema de comunicação em grupo envia a requisição para cada gerenciador de réplica correto na mesma ordem (total).
3. Execução: todos os gerenciadores de réplica executam a requisição. Como eles são máquinas de estado, e como as requisições são distribuídas na mesma ordem total, todos os gerenciadores de réplica corretos processam a requisição de forma idêntica. A resposta contém o identificador de requisição exclusiva do cliente.
4. Acordo: nenhuma fase de acordo é necessária, devido à semântica da distribuição por multicast.
5. Resposta: cada gerenciador de réplica envia sua resposta para o front-end. O número de respostas reunidas pelo front-end depende das suposições de falha e do algoritmo de multicast. Se, por exemplo, o objetivo for tolerar apenas falhas por colapso e o multicast satisfizer o acordo uniforme e as propriedades de ordenação, o front- -end passará ao cliente a primeira resposta que chegar e descartará as restantes (ele pode distingui-las das respostas de outras requisições examinando o identificador presente na resposta).

A recuperação é feita através de uma:

• Atualização do estado;
• Execução das requisições perdidas.

Exige que as réplicas tenham comportamento determinístico: A requisição deve produzir o mesmo efeito em todas as réplicas. Caso contrário, pode ocorrer divergência de estados.

Exige atomicidade na comunicação: Uma certa requisição é recebida por todas as réplicas ou, então, não é recebida por nenhuma réplica.

Exige ordenação na comunicação: Todas as réplicas recebem as mensagens (requisições) na mesma ordem.

• Falhas são mascaradas quase que instantaneamente.
• Adequada para aplicações que exigem serviços ininterruptos e com sobrecarga mínima em situações de falha, como aplicações de tempo real.
• Cobre um amplo espectro de faltas: crash, omissão, temporização e valor.

• Tem alto custo na comunicação.
• Exige muitos recursos do sistema (memória, processador).

Os dados em grandes corporações estão cada vez mais volumosos. O principal entrave é que o tamanho da largura da banda, necessária para trafegar as informações, não acompanha o crescimento na mesma proporção que o armazenamento. As estratégias de replicação ativo-ativo são, portanto, as mais interessantes, mesmo requerendo mudanças de softwares para o funcionamento transparente em data centers. Esses são desafios que novas tecnologias de banco de dados, como o NoSQL e ferramentas de big data, são capazes de resolver de maneira nativa, sem que haja a necessidade de aquisição de softwares específicos para essa finalidade.

Existem, ainda, alternativas que permitem que a replicação seja feita em ambientes internos com um único datacenter. Um bom exemplo disso são os de Hadoop, que replicam as informações, por padrão, três vezes dentro de seu próprio espaço. Para empresas menores, onde não há a possibilidade de investimento em outros datacenters, é importante garantir a alta disponibilidade por meio de serviços com arquitetura nativa de replicação, como a NoSQL e as ferramentas de big data. Hoje a melhor forma de se armazenar, recuperar e analisar as informações em um único ambiente utilizando big data é por meio de sistemas preparados de forma nativa para conseguir obter resultados de alta disponibilidade com a replicação de dados.

Atualmente, as grandes corporações não podem se dar ao luxo de terem suas operações interrompidas, independentemente do motivo. A rápida recuperação de sistemas após desastres naturais, como enchentes, incêndios, panes elétricas, terremotos, furacões ou tempestades é uma das maiores preocupações nas companhias. Soluções que permitem a continuidade operacional, mesmo após um evento catastrófico, são cada vez mais bem vistas e utilizadas.

Nesse aspecto, a replicação de dados torna-se uma saída interessante para as empresas que buscam a rápida recuperação depois de uma fatalidade. Essas ferramentas são usadas, normalmente, por companhias que possuem mais de uma estrutura de data center. Assim, se ocorrer um problema em um deles, é possível continuar com as operações normalmente a partir de outro centro de processamento. Para a implementação, o custo pode ser considerado alto. Nesses casos, é importante que as empresas ponderem se o valor por ter a operação parada por dias ou semanas é menor do que o de implantação de replicação. Dependendo da conclusão, é fundamental que haja uma reavaliação das estratégias de recuperação, validando a necessidade de um novo datacenter. Esse, por sua vez, normalmente deve ser instalado em região geográfica distante do original.

Este artigo sobre informática é um esboço. Você pode ajudar a Wikipédia expandindo-o. v d e

• Cluster
• RAID