Existem algumas razões para isso.
- A partição que contém o arquivo MySQL está cheia.
df -H
mostrará se uma partição está cheia. -
Se você estiver usando innodb: veja o
innodb_data_file_path
em seumy.cnf
. Você pode estar excedendo o valor "máximo". Exemplo disso:innodb_data_file_path = ibdata1: 10M: extensão automática: max: 512M
Você pode subir o 512 ou remover o
:max:512m
totalmente para que ele seja "ilimitado". - Você está adicionando um INDEX a uma tabela MEMORY (obviamente não é o caso, mas vale a pena mencionar).
Em relação ao NDB Cluster:
-
Um mecanismo do NDB contém todos dados na RAM . Do link:
No MySQL 5.0, o Cluster é apenas na memória. Isso significa que todos os dados da tabela (incluindo índices) são armazenados na RAM. Portanto, se seus dados ocuparem 1 GB de espaço e você quiser replicá-lo uma vez no cluster, precisará de 2 GB de memória para isso (1 GB por réplica). Isso é adicionado à memória exigida pelo sistema operacional e qualquer aplicativo em execução nos computadores do cluster
Se esta é a causa, você pode fazer este mas será um golpe de desempenho.
-
Verifique os valores de
MaxNoOfConcurrentOperations
eMaxNoOfConcurrentTransactions
. Configure-os para um valor maior que a maior tabela no cluster. -
Verifique no arquivo de log por mensagens relacionadas (
ndb_2_trace.log
?). Se mostrar coisas como "Nó 2: uso de dados aumentado para 100%", você está ficando sem memória.- A memória de índice armazena SOMENTE os índices de chave primária.
- A memória de dados armazena todos os dados + outros índices.
- A memória que você precisa por tabela é algo assim: ((tamanho de uma tabela) + (tamanho do índice)) * (o número de registros)
-
IndexMemory
eDataMemory
são as configurações correspondentes. Se você exceder esses, receberá este erro.
-
O número máximo de atributos (colunas e índices) por tabela é limitado a 128.