Arquitetura de banco de dados mestre-mestre vs mestre-escravo?

117

Já ouvi falar de dois tipos de arquiteturas de banco de dados.

  • mestre-mestre

  • senhor de escravos

O master-master não é mais adequado para a web de hoje porque é como o Git, cada unidade tem todo o conjunto de dados e se um cair, não importa.

Mestre-escravo me lembra SVN (que eu não gosto) onde você tem uma unidade central que controla as coisas.

Questões:

  1. Quais são os prós e os contras de cada um?

  2. Se você deseja ter um banco de dados local em seu celular, como o iPhone, qual é o mais adequado?

  3. A escolha de um desses é um fator crítico a ser considerado cuidadosamente?

database never_had_a_name
fonte
1
Teorema CAP -> Tolerância de partição de disponibilidade de consistência afirma que você não pode ter todos os três juntos. Dependendo do aplicativo, você pode escolher qualquer um.
Pritam Banerjee

Respostas:

87

Estamos trocando disponibilidade, consistência e complexidade. Para abordar a última pergunta primeiro: isso importa? Sim, muito! As escolhas sobre como seus dados devem ser gerenciados são absolutamente fundamentais, e não há "melhores práticas" evitando as decisões. Você precisa entender seus requisitos específicos.

Existe uma tensão fundamental:

Uma cópia: a consistência é fácil, mas se acontecer de cair, todo mundo estará fora da água e, se as pessoas estiverem remotas, poderão pagar terríveis custos de comunicação. Traga dispositivos portáteis, que podem precisar operar desconectados, para a imagem e uma cópia não vai cortá-lo.

Master Slave: a consistência não é muito difícil porque cada dado possui exatamente um master proprietário. Mas então o que você faz se não consegue ver aquele mestre, algum tipo de trabalho adiado é necessário.

Mestre-Mestre: bem, se você pode fazer funcionar, parece que oferece tudo, nenhum ponto único de falha, todos podem trabalhar o tempo todo. O problema com isso é que é muito difícil preservar a consistência absoluta. Veja o artigo da wikipedia para mais informações.

A Wikipedia parece ter um bom resumo das vantagens e desvantagens

Vantagens

  • Se um mestre falhar, outros mestres continuarão a atualizar o banco de dados.

  • Os mestres podem estar localizados em vários sites físicos, ou seja, distribuídos pela rede.

Desvantagens

  • A maioria dos sistemas de replicação multimestre são apenas vagamente consistentes, ou seja, preguiçosos e assíncronos, violando as propriedades ACID.

  • Os sistemas de replicação mais ágeis são complexos e apresentam alguma latência de comunicação.

  • Problemas como resolução de conflitos podem se tornar intratáveis ​​conforme o número de nós envolvidos aumenta e a latência necessária diminui.

djna
fonte
CouchDB usa MVCC. Esse tipo de tratamento lida com o problema de consistência enfrentado em vários mestres porque, quando um deles é colocado online novamente, o sistema de controle de versão lida com a consistência e esse mestre obterá os dados atualizados corretos.
never_had_a_name de
8
Mas o que acontece quando dois usuários fazem algo contraditório - como dois usuários tentam comprar o último item em estoque? Imagine um cenário em que temos dois mestres e cada usuário está acessando um mestre diferente, então temos algum tipo de falha de comunicação - no final, haverá um comprometimento da integridade ou disponibilidade reduzida - um usuário recebe a mensagem "desculpe, amigo, Eu realmente não sei o que está acontecendo até falar com o outro mestre ", ou temos um conflito feio quando as comunicações são restauradas - e isso pode ficar muito complicado.
Djna de
2
O que o comércio financeiro ou os mercados de ações usam? Eles estariam enfrentando esse problema o tempo todo?
CMCDragonkai
3
Onde você precisa de uma "verdade" única e atualizada (como em sistemas financeiros), você precisa de Mestre / Escravo ou, na verdade, apenas de Mestre. Onde você pode consertar a verdade mais tarde (pense em conflitos de mesclagem em um sistema de controle de revisão como o Git), então você pode usar Master / Master.
djna de
djna faz uma observação muito saliente. O banco de dados agora deve ter algum tipo de lógica de "desempatador". O que é mais importante? Os dados mais "recentes"? Isso faz sentido se você estiver reescrevendo um campo, mas não faz sentido se você estiver fazendo um "contador" e precisar que todos os processos sejam incrementados (ou decrementados) antes de retornar um resultado. Principalmente para não vender itens em falta. Se você tivesse uma partição de rede, o que acontece quando ela volta a funcionar? Tudo isso é coisa do teórico CAP. É aqui também que você pode ter algoritmos como Paxos, para desenvolver consenso entre diferentes máquinas.
Peter Corless
95

Enquanto pesquisava as várias arquiteturas de banco de dados também. Compilei um bom bocado de informação que pode ser relevante para outra pessoa pesquisar no futuro. Me deparei com

  1. Replicação Master-Slave
  2. Replicação Mestre-Mestre
  3. Cluster MySQL

Decidi usar o cluster MySQL para meu caso de uso. No entanto, consulte abaixo os vários prós e contras que compilei

1. Replicação mestre-escravo

Prós

  • Os aplicativos analíticos podem ler do (s) escravo (s) sem impactar o mestre
  • Backups de todo o banco de dados de relativamente nenhum impacto no mestre
  • Os escravos podem ser colocados offline e sincronizados com o mestre sem qualquer tempo de inatividade

Contras

  • No caso de falha, um escravo deve ser promovido a mestre para assumir o seu lugar. Sem failover automático
  • Tempo de inatividade e possível perda de dados quando um mestre falha
  • Todas as gravações também devem ser feitas no mestre em um design mestre-escravo
  • Cada escravo adicional adiciona alguma carga ao mestre, uma vez que o log binário deve ser lido e os dados copiados para cada escravo
  • O aplicativo pode ter que ser reiniciado

2. Replicação Mestre-Mestre

Prós

  • Os aplicativos podem ler de ambos os mestres
  • Distribui a carga de gravação em ambos os nós mestres
  • Failover simples, automático e rápido

Contras

  • Vagamente consistente
  • Não tão simples quanto mestre-escravo para configurar e implantar

3. Cluster MySQL

O novo garoto na cidade com base no design de cluster MySQL. O cluster MySQL foi desenvolvido com alta disponibilidade e escalabilidade em mente e é a solução ideal para ser usado em ambientes que não requerem tempo de inatividade, alta disponibilidade e escalabilidade horizontal.

Consulte MySQL Cluster 101 para obter mais informações

Prós

  • (Alta avalabilidade) Nenhum ponto único de falha
  • Rendimento muito alto
  • 99,99% de tempo de atividade
  • Auto-Sharding
  • Capacidade de Resposta em Tempo Real
  • Operações on-line (mudanças de esquema, etc.)
  • Gravações distribuídas

Contras

Você pode visitar o meu blog para análise completa, incluindo diagramas de arquitetura que dão mais detalhes sobre as 3 arquiteturas mencionadas.

Skillachie
fonte
2
Você também pode escrever algo sobre Galera? Cluster Percona XtraDB?
Ivanov
"O aplicativo pode ter que ser reiniciado" como parte dos contras. O que isso significa?
Lily
1
Se você tiver que alterar o IP do servidor de banco de dados, ele precisará ser configurado no aplicativo também para ler o novo mestre eleito. Como resultado, pode ser necessário reiniciar seu aplicativo para obter as novas definições de configuração. Tudo depende da sua configuração atual. Você também pode usar um IP flutuante para contornar isso. Só para se ter uma ideia geral
Skillachie