MySQL Multi-Master Replication vs. MySQL Cluster

Question

Eu preciso de um banco de dados MySQL que seja rápido e suporte muitas conexões. A maioria das conexões só estará lendo, mas algumas estarão lendo / escrevendo. Todas as conexões precisarão ler e escrever pelo menos alguns dados.

Eu tenho 4 servidores de teste para dedicar à experimentação. Originalmente eu estava planejando fazer multi-master, mas depois li um pouco sobre o MySQL Cluster. Eu tenho algumas perguntas:

1. A RAM do MySQL Cluster é apenas? A brochura diz que as tabelas de disco são suportadas, mas até a sua própria documentação, por vezes, diz que não são. Eu quero ser capaz de sobreviver a uma queda de energia.

2. O MySQL Cluster me dá alguma confiabilidade melhor que a multi-master? Eu me preocupo com uma falta de energia, fazendo com que minha instalação multi-master fique irremediavelmente fora de sincronia. Ser capaz de se recuperar de uma queda de energia, ou outra falha, é minha principal razão para considerar algo diferente de multi-mestre.

3. Existe alguma maneira de usar tabelas temporárias? Meu aplicativo usa algumas tabelas temporárias, mas vejo que o MySQL Cluster não as suporta. Existe alguma alternativa além de usar tabelas permanentes como se fossem temporárias?

4. Posso adicionar e remover nós de dados a qualquer momento? Sem interrupção do serviço?

Answer 1

Para responder às suas perguntas (elas são respondidas no manual, também btw.)

1. O cluster do MySQL (ndb) mantém todos os índices na memória o tempo todo. Suas estruturas de dados e padrões de acesso são otimizados para esse caso. Eles podem (opcionalmente) ser gravados no disco também. Os dados não indexados podem ser armazenados em disco e serão lidos (e armazenados em cache), conforme necessário. Em geral, para um banco de dados, é bom ter memória suficiente para manter o conjunto de trabalho na memória, mas o cluster é um pouco mais rígido sobre isso.
2. O MySQL / Oracle anuncia o MySQL Cluster como 99,999% de confiabilidade. Lembre-se de que grande parte da confiabilidade não está no software, mas no ambiente. Se o seu comutador ou energia morrer, o cluster completo pode ficar inativo. O MySQL Cluster tem rotinas bastante boas para ficar funcional e sincronizar se um nó desce e retorna. fazer isso corretamente no MMR é um pouco mais trabalhoso, mas pode ser feito também.
3. Por 1. O MySQL Cluster funciona bem com dados na RAM, então provavelmente você poderia usar o ndb para eles também. Como alternativa, dependendo dos dados atuais e do caso de uso, você provavelmente poderá manter as tabelas temporárias independentemente nos diferentes servidores MySQL. Note que existem benchmarks (enquanto benchmarks sempre mentem) mostrando que ndb é fatser que Memory tables.
4. Sim, a versão recente do cluster MySQL permite alterações on-line na configuração do nó e até alterações on-line nas estruturas da tabela. Ambos são mais complicados com o MMR.

Tendo dito tudo isso de bom sobre o cluster MySQL eu ainda quero notar que: O MySQL Cluster tem algumas limitações, por exemplo, fazer operações JOIN em um cluster MySQL é atualmente muito lento. A próxima versão vai consertar isso (procure por "push down joins"), então você deve ter cuidado ao configurar as coisas e fazer alguns testes antes de ir ao cluster para ver se ele atende às suas necessidades.