Cluster de MySQL

Question

Eu corro um servidor mysql que hospeda cerca de 50Gb de dados (principalmente para cerca de 250 sites), e estou querendo saber quais são as minhas opções para a criação de um cluster redundante do MySQL ? O objetivo principal seria que eu pudesse desativar um servidor para manutenção ou reinicialização, sem afetar a disponibilidade do banco de dados - e, secundariamente, haveria algum tipo de hot failover em caso de problemas com o servidor ativo. / p>

Meu entendimento é que o mysql-cluster requer que os bancos de dados estejam inteiramente contidos na memória, e com tantos dados, que não é uma opção prática.

    

Answer 1

O que você precisa é de replicação. Enquanto muitas pessoas usam a replicação do MySQL, já lidei bastante com isso (dezenas de instâncias MySQL de produção de alta capacidade) para saber que não é uma opção vencedora. É muito frágil e falhará em momentos inconvenientes. Agora, estou inclinado a usar uma solução de replicação de bloco, como o DRBD, para tornar os armazenamentos do MySQL consistentes.

No que diz respeito ao failover, novamente a replicação do MySQL não lida com isso particularmente bem. Embora o failover do mestre para o escravo seja uma operação bastante automatizável, lidar com as conseqüências (fazer a replicação rodar novamente) é sempre um processo manual, exigindo cutucando e cutucando para garantir que tudo funcione corretamente. Qualquer que seja o método de replicação escolhido, eu uso o heartbeat para detectar se tudo está funcionando bem e quando o servidor atualmente ativo cai, certificando-se de que uma aquisição ordenada de recursos ocorra.

    

Answer 2

Confira mmm para o failover automatizado. Certifique-se de configurar os dois servidores como mestres, para que você tenha replicação bidirecional. Além disso, se você estiver usando o incremento automático, certifique-se de configurá-lo para que não haja conflitos de entradas (consulte este artigo para detalhes).

Por fim, use o Maatkit para garantir que não haja inconsistências entre os servidores.

    

Answer 3

Temos usado DRBD / Heartbeat por enquanto, e é muito bom, mas não é ideal para uma situação de servidor virtual (o que temos), porque deve ter várias conexões entre os servidores e, em um ambiente virtual, todas as conexões (serial, ethernet, etc.) são essencialmente transportadas pelo mesmo fio - assim, quando uma delas atinge o tempo limite, elas esgotam o tempo limite. (Eu percebi que eu poderia colocar um cabo serial real lá, mas então eu não seria mais capaz de migrar minhas VMs entre hosts - uma habilidade que eu não quero desistir)

Nesta situação eu ocasionalmente recebo um caso em que nenhum servidor pode ver o outro, e ambos se tornam "Primários" ao mesmo tempo (uma situação chamada split-brain, que é uma dor de cabeça para se recuperar)

Mas é definitivamente uma solução melhor do que replicação de binlog que estávamos usando antes disso - e dos comentários até agora parece uma solução mais robusta do que mysql-cluster também.

    

Answer 4

A partir do mysql 5.1, os dados do cluster mysql (embora não seus índices) podem ser armazenados no disco: O que há de novo no MySQL 5.1

No entanto, eu concordaria com o womble que, considerando muitas das limitações do mysql-cluster / ndb e a fragilidade da replicação, hesitaria em considerar uma solução de propósito geral. Para um único banco de dados com um modelo de uso bem compreendido e um DBA real que funciona com os desenvolvedores? possivelmente. Mas não para um cluster de servidor de banco de dados de uso geral que suporte muitos aplicativos diferentes.

Em vez disso, eu gostaria de usar a abordagem DRBD ou simplesmente jogar dinheiro no problema e usar uma SAN. Nenhuma solução que conheço é perfeita.