replicação mestre-escravo-escravo: o mestre se tornará um gargalo para as gravações

Question

o banco de dados mysql tem cerca de 2TB de dados.

Eu tenho uma replicação mestre-escravo-escravo em execução. o aplicativo que usa o banco de dados lê (SELECT) consultas apenas em um dos dois escravos e escreve consultas (DELETE / INSERT / UPDATE) no mestre. o aplicativo faz muito mais leituras do que escreve.

se tivermos um problema com as consultas de leitura (SELECT), podemos simplesmente adicionar outro banco de dados escravo e informar ao aplicativo que existe outra solução. por isso, dimensiona bem ...

Atualmente, o mestre está rodando em torno de 40% do disco io devido às gravações.

Então, 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 lá?

talvez cluster de mysql? Em caso afirmativo, há alguma armadilha ou limitações em mudar o banco de dados para ndb?

muito obrigado antecipadamente ...:)

    

Answer 1

Não há uma resposta única para dimensionar o MySQL. Algumas dicas gerais:

• Escale "diagonalmente" o quanto puder, ou seja. manter as coisas em um único servidor MySQL, desde que você ainda seja capaz de rodar em hardware comum. Isso provavelmente significa 2 x CPUs quad-core, 64+ GB RAM, 8 discos RAID 10 - ou superior. O limite superior do que é "hardware comum" está ficando mais rápido a cada ano.

• Veja as apresentações de Brad Fitzpatrick sobre o dimensionamento do LiveJournal. Eles são praticamente clássicos no que diz respeito ao dimensionamento do LAMP. Em página 25 - 26 desta apresentação você vê o problema que eventualmente enfrentará com a replicação do MySQL: As gravações consumir toda a E / S de disco disponível.

• Leia " Alto desempenho do MySQL ". É um livro muito bom por autores que viram muitas instalações de alta carga do MySQL .

• Evite fragmentar (espalhando dados em vários servidores MySQL) pelo maior tempo possível. Ao iniciar o sharding, você abre mão da maioria dos benefícios dos bancos de dados relacionais e diminui o desenvolvimento. Se você tiver que fazer sharding, considere o uso de um datastore NoSQL com um modelo de multi-servidor embutido - fx Riak, Cassandra, HBase, MongoDB. Idealmente, faça o "particionamento funcional" entre MySQL e NoSQL, para que você continue usando o MySQL para obter dados menos importantes que caibam em um RDBMS, e você usa o mecanismo NoSQL para dados "quentes" que não precisa se juntar ao MySQL dados.

maybe mysql cluster? if so, are there any pitfalls or limitations in switching the database to ndb?

Em " Operações na Web " há um capítulo sobre MySQL por Baron Schwartz. Ele praticamente apenas diz "Não!" ao usar o MySQL Cluster / NDB em um ambiente de website. Citação: ".. não funciona bem para junções e consultas GROUP BY, e aplicações web precisam disso."

    

Answer 2

O armazenamento em cluster do MySQL aumentará a escalabilidade das gravações dividindo seu banco de dados em fragmentos distribuídos em várias máquinas. Mas isso reduzirá drasticamente as consultas complexas que extraem dados de vários fragmentos. Só você pode determinar o efeito disso no desempenho do aplicativo.

Você pode querer analisar os dados manualmente, em vez de permitir que o mecanismo de cluster faça isso para você. Vai demorar mais configuração, mas se você entender como seu aplicativo usa o banco de dados, você poderá criar um esquema de sharding que permita que a maioria das consultas acesse apenas um shard.

    

Answer 3

Lembre-se de que a replicação do MySQL é de encadeamento único, então provavelmente sua replicação não será limitada pela capacidade principal, mas pelos escravos, que não podem ficar atrás do mestre e ficarão fora de sincronia. A partir deste artigo :

The replication replay process executes in a single thread on the replicas, and thus has no hope of keeping up with even a moderately busy write load on the primary, where many updates are occurring concurrently.

    

Answer 4

Você pode pensar em agrupar as informações em si. Se for possível - separar as tabelas de consumo entre servidores diferentes.