Primeiro vamos fazer uma introdução sobre os dados distribuídos.

Quando queremos garantir escalabilidade e confiabilidade do nosso sistema, é inevitável

que em algum momento, nossos dados estejam distribuídos em mais de um lugar. Caso

contrário, basta uma falha de acesso ao servidor de banco de dados e a aplicação para de

funcionar. Se isso for inaceitável para seu negócio, aceite o fato de que algum nivel de

computação distribuída vai existir.

Em uma arquitetura web típica, é comum ter um cluster de servidores web respondendo

à requisições e um proxy reverso que as distribui aos nós do cluster. Essa arquitetura é

fácil de implementar por que os nós do cluster não compartilham nada entre si (Shared

Nothing Architecture). Como servidores web também não armazenam estado (chamados

stateless web servers), caso um nó do cluster falhe, basta tirá-lo do cluster, enviar as

requisições para os nós que ainda funcionam e adicionar um nó novo. Ter escalabilidade

horizontal assim não é dificil.

Em um cluster de banco de dados, ainda é possível usar essa Shared-Nothing
Architecture, ou seja, não compartilhamos nenhum recurso computacional. Porém, vai
ser inevitável compartilhar uma coisa nos nós do cluster de banco de dados: os dados.
Podemos distribuir os dados em vários servidores de um cluster de duas formas, sendo
uma delas a replicação, que é da qual vamos tratar.

Replicação de dados, o que é

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.

Funcionamento
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.

Aplicabilidade
 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.
Arquitetura de uma replicação
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.

Estratégias de replicação de dados

Toda vez que algum dado é escrito no banco, é necessário ter uma cópia desses dados
nas outras réplicas do banco. Um cliente que envia uma requisição de escrita (ex:
INSERT, UPDATE ou DELETE) para algum nó no cluster, o cluster deve seguir
alguma estratégia para replicar esse dado escrito nos outros nós. As estratégias mais
comuns de replicação são: Replicação com líder único, Replicação com múltiplos
líderes e replicação sem líder.

Replicação de líder único

A estratégia mais comum para se garantir disponibilidade em caso de falha. Nessa

estratégia, o cluster sempre elege um líder que será o único responsável por aceitar
requisições de escrita. Requisições de leitura são aceitas por qualquer nó, líder ou
réplica.

Em uma operação de escrita, o nó líder commita a escrita e envia uma resposta ao

cliente. Em seguida, de maneira assíncrona, é enviado aos nós replicas a mesma
operação para que o mesmo dado seja escrito nos outros nós e manter todas as réplicas
consistentes.

A escrita nas réplicas também pode ser feita de maneira síncrona, com o cliente
recebendo a resposta da requisição somente depois da escrita ter sido replicada em todos
os nós. Isso evita alguns problemas que veremos depois, mas a performance é bem ruim
e pode causar um enorme gargalo caso escritas sejam muito frequentes e principalmente
se algum dos nós falhar. É mais comum que se a replicação for síncrona, que apenas um
dos nós seja replicado sincronamente e os outros de forma assíncrona.
O líder é eleito pelo cluster usando algum tipo de algoritmo de consenso como Paxos ou
Raft.

Replicação com múltiplos líderes

Essa é uma estratégia mais comum em ambientes multi-datacenter. Por exemplo, caso
exista versões da aplicação rodando em mais de um datacenter diferente, para acesso
mais rápido em diferentes regiões (Latam e América do Norte por exemplo). É possível
ter um cluster em multiplas regiões e ter um líder por região. Os líderes que commitou o
dado replica a operação de escrita com os líderes das outras regiões, que por sua vez,
enviam os dados para seus respectivos nós replicas.

Replicação sem líder

Nesse caso o cliente envia a requisição para varios nós. Como não há um líder
coordenando que garante a escrita dos dados e a replicação dos dados escritos no banco,
é necessário utilizar uma técnica chamada Quorum, que consiste basicamente em ter
confirmação de uma maioria dos nós no cluster. Uma operação em um cluster com N
nós, para ser considerada bem sucedida, deve ser confirmada por no mínimo K nós. O
número K é o que chamamos de Quorum. Esse número K pode ser diferente para
operações de leitura e escrita, ou ser igual para ambas operações, desde que esse número
satisfaça a seguinte condição:

Voce pode definir o valor de K como sendo (N + 1) / 2, arredondado para cima. Então
caso haja 4 nós no cluster, as operações teriam que ser confirmadas por um Quorum de
ao menos 3 nós.

Esse tipo de replicação sem lider é conhecido como Dynamo-Style Replication. Não
confundir com o Amazon DynamoDB que usa replicação com líder único
 Desafios

Os maiores problemas que costumam aparecer quando há mais de uma réplica dos dados

são relacionados a consistência dos dados e, no caso de estratégias com líder, uma falha e

recuperação do líder.

Recuperação de falha de um líder se dá da seguinte forma:

1. Detectar uma falha do líder:

2. Escolha de um novo líder:

3. Reconfigurar o sistema e passar a usar o novo líder:

Outro problema com dados distribuídos é na consistência dos dados. Como a replicação

dos dados não é imediata, e os clientes lêem os dados de réplicas que podem ainda não

ter os dados mais atuais que foram escritos pelo líder, pode ser bem comum haver o que

chamamos de atraso de replicação, ou Replication Lag.

Ambientes de replicação sem líder são otimizados para aplicações com uma tolerância

maior à consistência eventual, pois a probabilidade de valores desatualizados é maior

(pois não há um líder como uma fonte de consistência). Garantia de consistência

geralmente requer transações distribuídas ou algoritmos de consenso distribuído, que são

operações com custo alto de performance.

Em casos de falha de algum nó, após ele voltar a funcionar ele deve receber os dados que

foram perdidos enquanto ele estava fora do ar. Isso pode acontecer de duas maneiras:
Read repair: o cliente, quando faz uma requisição de leitura pra varios nós, caso receba

um valor desatualizado de um nó, envia uma requisição de atualização para o nó que

enviou o dado desatualizado.

Processo anti-entropia: um processo que fica continuamente monitorando dados

inconsistentes e realiza as atualizações necessárias copiando dados de uma réplica pra

outra.

Outro problema que pode ocorrer também é quando, em cenários multi-líder ou sem

líder, há escritas concorrentes e é necessário detectar e corrigir dados conflitantes.

CONCLUSAO
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.