Requisito de RAM do cluster MySQL

No MySQL 5.1, os dados não precisam mais ficar na memória.

Eu li que as colunas indexadas (acho que toda a estrutura do índice) ainda devem estar na memória ( MySQL High Availability, 2010, pág. 533 , "O MySQL Cluster mantém todas as colunas indexadas na memória principal" ).

À luz disso, o que acontece se NÃO houver memória suficiente (ou seja, um banco de dados enorme (> 100 GB ou 1 TB), executando em servidores com pouca memória (2 nós de dados, cada um com 1 GB de RAM, por exemplo)?

O MySQL Cluster suporta o armazenamento de colunas não indexadas em disco apenas com um cache LRU de dados acessados ​​recentemente. No entanto, as colunas indexadas são sempre mantidas na memória.

O MySQL Cluster pré-aloca toda a memória, de acordo com os parâmetros DataMemory e IndexMemory. Não solicitará ao SO subjacente mais memória dinamicamente.

Isso significa que você precisa ter configurado memória suficiente no cluster para armazenar todas as colunas indexadas na memória. Se o seu conjunto de dados for grande o suficiente para que as colunas indexadas sejam maiores que a memória disponível do cluster, você não poderá carregar esse conjunto de dados no cluster. Em algum momento, você ficará sem espaço e suas transações de inserção serão abortadas.

Ao configurar o DataMemory e o IndexMemory, é melhor limitar-se a um pouco menos do que a memória física em cada sistema. Alguma memória física deve ser reservada para o sistema operacional e outros processos.

Teoricamente, o MySQL Cluster pode ser configurado para que ele use memória virtual através de um dispositivo de troca (por exemplo, mais que memória física), mas, como as outras respostas afirmam, este não é um caso de uso projetado. Trocar estruturas na memória trocadas para o disco normalmente não é ideal, pois os padrões de acesso aleatório na memória resultam em acesso aleatório ao disco, resultando em troca de trocas e lentidão no sistema. Com o MySQL Cluster, o resultado mais provável é a falha de pulsação e falha de cluster devido a um nó de troca de dados que não responde aos sinais com rapidez suficiente.

Para suportar eficientemente índices com memória maior que a agregada, o MySQL Cluster precisaria suportar formatos de índice em disco (talvez uma árvore B etc.) com padrões de cache e acesso alinhados às propriedades de acesso ao disco.

O cluster MySQL é construído em torno de uma estrutura de índice otimizada para ajuste de memória; uma T-árvore . Isso é diferente de seus mecanismos de armazenamento regulares no MySQL, que usam uma estrutura em árvore B ou B + , que podem sobreviver bastante sem ajuste de memória, desde que você tenha alguns pontos de acesso / acesso não uniforme (isso normalmente é uma suposição segura). )

Se você deseja criar algum tipo de prova de conceito, não há nada que o impeça de usar uma grande quantidade de swap para compensar sua falta de RAM. Lembre-se de que isso não terá um bom desempenho e você está usando um produto para um caso de uso para o qual não foi projetado.

À luz disso, o que acontece se NÃO houver memória suficiente

Provavelmente o que você esperaria se não houvesse memória suficiente. Os arquivos serão criados em suas unidades e você estará executando o mais rápido possível.

Certifique-se de limitar o MySQL corretamente para que ele não consuma toda a memória necessária para outros processos do sistema.

Basicamente, uma cadeia é tão forte quanto seu elo mais fraco.

Quando servidores virtuais privados são configurados (usando o VMWare para configurar os ESX Clusters), todos os servidores bare-metal no Cluster devem ter a mesma quantidade de RAM.

O MySQL Cluster deve ser tratado com o mesmo tipo de luvas de pelica. Se algum servidor (mesmo que apenas 1) tenha menos memória que outros em um cluster, isso seria um fator limitante. Não me surpreenderia se um servidor com 2 GB de RAM fizesse com que outros servidores no MySQL Cluster (mesmo que esses outros servidores tivessem 8 GB de RAM) se comportassem como se tivessem no máximo 2 GB.

No mínimo, você deve

• atualize sua RAM nos nós de dados para corresponder aos nós SQL
• Use o maior número possível de tabelas baseadas em disco
• Remova todos os índices supérfluos (índices não sendo usados)
• Para maiores informações
  • MySQL Sharding vs MySQL Cluster
  • http://messagepassing.blogspot.com/2011/03/data-distribution-in-mysql-cluster.html

Como uma observação lateral, lembre-se de que o MySQL Cluster também tem a capacidade de armazenar dados em disco para cada servidor em execução como um nó de armazenamento.