o banco de dados mysql possui cerca de 2 TB de dados.
eu tenho uma replicação mestre-escravo-escravo em execução. a aplicação que utiliza o banco de dados lê (SELECT) consultas apenas em um dos 2 escravos e grava consultas (DELETE/INSERT/UPDATE) no mestre. o aplicativo faz muito mais leituras do que gravações.
se tivermos um problema com as consultas de leitura (SELECT), podemos simplesmente adicionar outro banco de dados escravo e informar ao aplicativo que há outro salvamento. então ele escala bem...
Atualmente, o mestre está rodando em torno de 40% do disco io devido às gravações.
Estou pensando em como dimensionar o banco de dados no futuro. Porque um dia o mestre ficará sobrecarregado.
O que poderia ser uma solução aí?
talvez cluster mysql? em caso afirmativo, há alguma armadilha ou limitação na mudança do banco de dados para ndb?
muito obrigado desde já... :)
Responder1
Não existe uma resposta única para dimensionar o MySQL.Algumas dicas gerais:
Dimensione "diagonalmente" o máximo que puder, ou seja. mantenha tudo em um único servidor MySQL, desde que você ainda consiga rodar em hardware comum. Isso provavelmente significa 2 CPUs quad-core, mais de 64 GB de RAM, 8 discos RAID 10 – ou superior. O limite superior do que é “hardware commodity” está ficando mais rápido a cada ano.
Dê uma olhada nas apresentações de Brad Fitzpatrick sobre como dimensionar o LiveJournal. Eles são praticamente clássicos no que diz respeito ao dimensionamento do LAMP. Sobrepáginas 25 - 26 desta apresentaçãovocê verá o problema que eventualmente enfrentará com a replicação do MySQL: as gravações consomem toda a E/S de disco disponível.
Ler "MySQL de alto desempenho". É um livro muito bom deautores que viram muitas instalações MySQL de alta carga.
Evite fragmentar (distribuir dados por muitos servidores MySQL) pelo maior tempo possível.Ao iniciar a fragmentação, você abre mão da maioria dos benefícios dos bancos de dados relacionais e retarda o desenvolvimento. Se você precisar fazer fragmentação, considere usar um armazenamento de dados NoSQL com um modelo de vários servidores integrado - fx Riak, Cassandra, HBase, MongoDB. Idealmente, faça "particionamento funcional" entre MySQL e NoSQL, para que você continue usando o MySQL para dados menos importantes que se encaixem bem em um RDBMS, e use o mecanismo NoSQL para dados "quentes" que você não precisa juntar ao MySQL dados.
talvez cluster mysql? em caso afirmativo, há alguma armadilha ou limitação na mudança do banco de dados para ndb?
Em "Operações Web"há um capítulo sobre MySQL do Baron Schwartz. Ele praticamente apenas diz "Não!" ao uso do MySQL Cluster/NDB em um ambiente de site. Citação: ".. ele não funciona bem para junções e consultas GROUP BY, e aplicativos da web precisam disso.".
Responder2
O clustering MySQL proporcionará escalabilidade de gravações, dividindo seu banco de dados em fragmentos que são espalhados por várias máquinas. Mas isso desacelerará drasticamente consultas complexas que extraem dados de vários fragmentos. Somente você pode determinar o efeito disso no desempenho do seu aplicativo.
Você pode querer analisar a fragmentação dos dados manualmente, em vez de deixar o mecanismo de cluster fazer isso por você. Será necessária mais configuração, mas se você entender como seu aplicativo usa o banco de dados, poderá criar um esquema de fragmentação que permita que a maioria das consultas acesse apenas um fragmento.
Responder3
Lembre-se de que a replicação do MySQL é de thread único, então provavelmente sua replicação não será limitada pela capacidade do mestre, mas pelos escravos, que não podem ficar atrás do mestre e ficarão fora de sincronia.Deste artigo:
O processo de reprodução de replicação é executado em um único thread nas réplicas e, portanto, não tem esperança de acompanhar até mesmo uma carga de gravação moderadamente ocupada no primário, onde muitas atualizações estão ocorrendo simultaneamente.
Responder4
Você pode pensar em agrupar as informações em cluster. Se for possível - separar tabelas de consumo de gravação entre diferentes servidores.