Arquitetura do Cassandra – Replicação

Olá pessoal.  Vamos começar uma série de artigos sobre Cassandra discutindo um pouco de sua arquitetura até chegarmos no deploy automatizado, como prometido no DBA Brasil 3.

Dois pontos de destaque da sua arquitetura são:  não há um ponto único de falhas (multi master de verdade) e sua escalabilidade horizontal é linear.

Vamos entender o que é não haver um ponto único de falha comparando com outros sistemas mais conhecidos.

No caso do Oracle, há um banco de dados principal (primary) que replica para um banco de dados secundário (standby).  O standby normalmente fica em um estado fechado não disponível para escrita/leitura, mas pode estar disponível apenas para leitura (read-only ou read-only com apply se tiver Active Dataguard).  Assim, o primary é o ponto de falha.  E isto não quer dizer que não é possível se recuperar em caso de crash, apenas quer dizer que isso vai levar um tempo.

No caso da replicação no MySQL a estrutura é semelhante, com um banco principal (master) replicando para os secundários (slaves).  A diferença é que o slave fica aberto para consultas/escritas nativamente. É possível e recomendado forçar o slave para que fique disponível para leituras.

A estrutura de replicação no MongoDB chama-se ReplicaSet e também tem um serviço principal (primary) e os slaves (secondary).  E também é possível disponibilizar o secondary para leituras. O MongoDB usa shardings para escalar horizontalmente, mas cada sharding precisa de sua réplica.

O que muda em relação ao Cassandra?  A principal diferença é que todos os nodes são masters, podendo receber escrita e leitura.  E caso um deles falhe, os outros continuam recebendo as escritas.  Qual é a mágica?

Cada node é responsável por um range de dados.  Para simplificar, imagine que tenhamos 5 nodes (A, B, …, E) em um cluster e um algoritmo de Hash que gere 1000 valores distintos.  Isto faz com que cada node fique responsável por 200 valores distintos (A – 1 ~200, B – 201 ~ 400, …, E – 801 ~ 1000).

Até aqui, ok?  Vamos supor também que estamos falando de uma Keyspace que tenha um Replication Factor (RF) de 3.

Continuando o exemplo, imagine que chega uma requisição de escrita nesta Keyspace e nosso algoritmo gerou um Hash com valor de 231.  O node responsável por este dado é o B, ele então insere este dado e solicita ao node C e D que também o armazenem para satisfazer o RF.

Um ponto interessante é que o node E pode ter recebido esta solicitação de escrita e em caso de indisponibilidade do B, ele guardaria esta informação no que chamamos de hinted handoff, que falaremos em um outro artigo.

Perceba que não temos nenhum node atuando apenas como standby/slave, desta forma, qualquer node adicionado ao cluster aumenta sua capacidade de receber escritas e a falha de qualquer um deles é suportada pelos demais.

É claro que há vários outros pontos importantes e que não foram citados, mas espero conseguir falar um pouco de cada um.

Alguma crítica, dúvida ou sugestão?  Deixe sua opinião nos comentários ou nos escreva.

Abraços,

Adriano Bonacin