Balanceamento de carga do MySQL

Question

Estou procurando formas de equilibrar a carga em nossa infraestrutura MySQL e não consigo encontrar uma resposta que funcione para mim ...:)

Então, eu tenho um servidor grande e gordo, que lida com tudo. Muitos bancos de dados, muitas leituras, muitas gravações, etc. Ele lida muito bem, mas é um ponto único de falha.

Nós configuramos um par de escravos para redirecionar as leituras para eles, mas enfrentamos dois problemas: é preciso muito esforço para reconstruir todos os programas para dividir leituras e gravações; e às vezes os escravos ficam para trás, o que leva a artefatos muito interessantes no aplicativo.

Problemas com o slaves ficando para trás: porque muitos bancos de dados são misturados - há consultas pesadas de 10 a 20 minutos no lado da mineração de dados, assim como consultas atômicas que não levam tempo. Mas o Slave executa uma consulta por vez, portanto, todas as consultas atômicas têm que esperar até que uma conclusão pesada seja concluída.

Para resolver esses dois problemas, eu estava pensando em algo como um proxy, que consideraria isso:

• dividir leitura / gravação automaticamente
• servir como um único ponto de entrada e, em seguida, redirecionar pedido para apropriado servidor que precisa de banco de dados (por exemplo, separar db1 e db2 no back-end, mas é transparente para o aplicação)
• esteja ciente do atraso do escravo, e enviar leituras para o mestre, quando o atraso do escravo ocorre (seria ideal se isso pode ser feito, digamos, por banco de dados; mas todo o servidor seria bastante impressionante também)
• balanceamento de carga lê entre todos os escravos elegíveis (seja por simples round robin, ou por monitorando LA)

Um problema que ainda permanece, mas que eu quero considerar - é o failover. Se o mestre falhar - seria bom se o escravo assumisse as responsabilidades de um mestre e, quando o mestre estivesse de volta - se tornasse um escravo.

Qualquer apontador para RTFM ou estudos de caso sobre este assunto seria bem-vindo =)

EDIT: Pesquisou mais algumas, e além da empresa Tungsten - encontrou dbShards e Schooner. Enquanto olha mais fundo nisso - alguém tem experiência com essas soluções? Algum feedback?

    

Answer 1

Confira Enterprise da Tungsten

O MySQL-MMM não é uma solução recomendada. Veja: link Mesmo um dos autores originais concordou nos comentários .

Felicidades

Editar: oops, o segundo link foi o mesmo que o primeiro. Corrigido

    

Answer 2

Como dois servidores atuam como seus bancos de dados de aplicativos e outro servidor (ou dois?) atuando como sua camada de mineração de dados. Seus dois bancos de dados de 'aplicativos' não devem ficar (muito longe) porque não estão lidando com nenhuma das consultas pesadas. Você também pode configurar o mysql-mmm para lidar com os failovers. Então você pode apontar sua aplicação para o Mysql VIP que você configurou no seu balanceador de carga. Este VIP tem dois IPs MMM nele. Mas o MMM pode dizer: "Ei, a caixa 2 está muito atrasada, vou mover o IP para a caixa 1 para que ele consiga alcançá-lo".

Em seguida, você terá dois níveis de bancos de dados manipulando seus dois tipos de consulta diferentes. Os caches nessas máquinas serão otimizados para seus tipos de consulta (em teoria).

Veja também um cartão Fusion-IO ou o Virident TachIOn. Isso pode resolver os problemas sem adicionar um monte de hardware.

    

Answer 3

Para resolver o atraso de replicação, implementamos os SSDs como armazenamento primário no escravo. Os tempos de gravação mais rápidos ajudam o banco de dados escravo a manter-se, apesar da replicação no escravo ser uma única operação de encadeamento.