Ajudaria se você postasse seu my.cnf e se você estivesse usando tabelas InnoDB ou MyISAM e se você é uma carga de trabalho pesada para leitura ou pesada. Caso contrário, estamos apenas fazendo suposições. Aqui está o meu:
Primeiro, gostaria de verificar se suas consultas estão indexadas corretamente. A alta E / S em bancos de dados MySQL é causada pela concorrência extremamente alta, por um servidor mal-ajustado ou por consultas com desempenho insatisfatório que precisam executar varreduras completas de tabela ou índice. Algumas dicas sobre como encontrar as consultas com baixo desempenho podem ser encontradas em my postar no blog técnico da Ideeli .
Verifique seu my.cnf. Se você estiver usando o InnoDB, certifique-se de que innodb_buffer_pool_size e innodb_log_file_size sejam suficientemente grandes. Como o EBS tem essa latência variável, o máximo de innodb_log_file_size pode ter benefícios substanciais de desempenho. Se você estiver usando o MyISAM (e você não deveria), certifique-se de que o tamanho do seu key_buffer seja grande o suficiente.
Se você tiver certeza de que suas consultas estão bem otimizadas e seu servidor está bem ajustado, podemos passar para o próximo item. O ext3 é menos que ideal para bancos de dados. Uma das principais razões para isso é que o ext3 permite apenas que um único thread atualize um inode de cada vez (tentando encontrar documentação para isso). Se você não estiver executando com innodb-file-per-table, isso significa que há uma tonelada de contenção do sistema de arquivos no arquivo ibdata. O xfs não tem essa limitação e mostrou ter um desempenho muito melhor (precisa de origem) para cargas de trabalho de banco de dados.
Se você não puder mudar para o xfs, certifique-se de estar usando innodb-file-per-table e, no mínimo, certifique-se de ter noatime, nodiratime na montagem.
Em seguida, vá para o tamanho da sua instância. Um c1.medium não é um tamanho de instância ideal para a maioria dos bancos de dados, a menos que o conjunto de dados seja pequeno. O MySQL normalmente se beneficiará da memória sobre o poder computacional. c1.medium só tem 1.7GB de RAM! Qual é o tamanho do seu conjunto de dados? Em geral, um m1.large (com 7,5 GB de RAM) superará o desempenho médio, exceto em casos muito raros. Também é duas vezes mais caro, a US $ 0,34 / h.
Agora, para o RAID dos volumes do EBS. Sim, o RAID aumentará muito sua IOPS. (Como vai aumentar o tamanho da sua instância). Não RAID0 ... Se você se preocupa com seus dados, pelo menos. Expliquei isso em muitos lugares, inclusive no meu blog , como palestrante em Percona Live NYC em 2011 e aqui em serverfault . A versão curta é que os volumes do EBS falham de maneiras atípicas e a possibilidade de remover um volume do conjunto provou ser valiosa em ocasiões especiais, principalmente durante a grande interrupção do EBS de 2011, onde alguns sites ficaram offline por vários dias ... Ficamos offline por 45 minutos às 4 da manhã, apesar de ter dezenas de casos afetados pela questão do EBS.
Aqui estão alguns benchmarks para o RAIDed Volumes do EBS usando o MySQL.
Por fim, o Percona Server possui um grande número de otimizações de escalabilidade. Aqui está um white paper sobre a experiência da minha empresa quando mudando do MySQL para o Percona Server. Estávamos experimentando barracas de banco de dados e interrupções todos os dias. Simplesmente mudar para o Percona Server do MySQL resolveu esse problema literalmente durante a noite devido a uma série de melhorias de escalabilidade.
Então, em resumo ...
- Ajustar suas consultas
- Ajustar seu servidor
- Obtenha melhor "hardware"
- Use xfs, não ext3
- RAID10, não RAID0
- Mude do MySQL para o Percona Server
Quanto ao MySQL Cluster, ele é um animal completamente diferente do MySQL e geralmente não é adequado para a maioria dos aplicativos OLTP. Galera / Cluster de Percona XtraDB são novos e interessantes produtos de clustering também. Você tem muito de opções antes de chegar a nada disso, no entanto. Nós servimos 24k qps no pico de um único m2.4xlarge com RAID10 no EC2.
Boa sorte!