Estou procurando criar um cluster MySQL com balanceamento de carga, mas sem o balanceador de carga real, para não adicionar outro ponto de falha ou complexidade.
O que eu estava pensando era ter o seguinte:
Tenha uma configuração master-master para MySQL
Em cada cliente, coloque um proxy round-robin simples que gire as solicitações entre os servidores.
Isso é possível? Ou existem melhores maneiras de conseguir isso?
Respostas:
Por favor, leia minha outra resposta a esta pergunta antes de realmente usar um proxy MySQL de qualquer tipo. Se você tiver 2 servidores master-master nos quais um CMS está gravando e 10 httpd que apenas leem dele, você ficará bem, mas (conforme indicado na outra resposta) nem sempre é esse o caso. Voce foi avisado.
O MySQL Proxy é um programa simples que fica entre o cliente e os servidores MySQL que podem monitorar, analisar ou transformar a comunicação deles. Sua flexibilidade permite usos ilimitados; os mais comuns incluem: balanceamento de carga; failover; análise de consultas; filtragem e modificação de consultas; e muitos mais.
.
O HAProxy é uma solução gratuita, muito rápida e confiável, que oferece alta disponibilidade, balanceamento de carga e proxy para aplicativos baseados em TCP e HTTP
Se você o executasse no modo TCP, poderia ser ainda melhor que o Wackamole. Se eu tivesse que escolher entre eles, usaria o HAProxy. Além disso, o HAProxy pode ter muitos back-ends, o Waclamole pode ter apenas 2. Observe que o HAProxy é "burro", conecta soquetes sem olhar o que está dentro do fluxo - o MySQL Proxy dedicado pode ter uma opção para apontar várias solicitações para servidores especificados .
Provavelmente vale a pena mencionar, o Galera Replication for MySQL para uma verdadeira configuração multi-master do MySQL. O Galera é um protocolo de replicação síncrona, para que os aplicativos possam ler e gravar em qualquer um dos servidores MySQL. Aqui está um tutorial rápido: http://www.severalnines.com/clustercontrol-mysql-galera-tutorial
Quanto aos balanceadores de carga na frente dos servidores MySQL, use um conector MySQL que suporte essa funcionalidade (por exemplo, Connector / J para Java ou Mysqlnd para php)
Se você não possui um conector que possa fazer isso, use algo como um Proxy HA. Este script configura automaticamente o HA Proxy e mantém a lista de bons servidores MySQL: https://github.com/severalnines/haproxy
Cumprimentos,
Vinay
www.severalnines.com
A replicação mestre-mestre não é tão boa quanto você imagina, o mesmo vale para o proxy round-robin e soluções similares 'fáceis'. Se você confirmar a coleta de dados para separar servidores com rapidez suficiente (mais rápido que o atraso entre os servidores, que nos servidores de produção pode levar até um segundo inteiro *), ambos aceitarão os dados. Se você possui um servidor de leilão, acaba de vender o mesmo carro duas vezes . Quem comprou? Depende de qual banco de dados você irá perguntar!
O aplicativo deve estar ciente de que existem 2 bancos de dados e precisa conhecer os dois endereços IP. Se você quer "vender", você deve
DB_number = `auction_number` % `number_of_databases`( %é para modulo)
... e confirme no banco de dados DB_number. Se você receber um erro de conexão, talvez o faça com o outro (mas, no caso de um servidor de leilão, eu exibiria apenas um erro).
Além disso, os endereços IP devem ser wackamole -d entre os dois servidores. Em um cenário de desastre, em que um servidor de banco de dados fica inativo por algumas horas no horário de pico, você descobrirá que o aplicativo tentará se conectar ao servidor ausente e travará até TIMEOUT, por exemplo, 3s. De repente, metade das Suas consultas é executada 3s a mais (e todas elas acabam no mesmo banco de dados - o que não o torna mais rápido do que antes do desastre). Isso não faz o seu httpd feliz, pois provavelmente possui um conjunto de conexões limitado de threads de manipulador de solicitações simultâneos ...
* o atraso de replicação nos servidores de produção pode levar até um segundo inteiro - eu testei isso em uma colocação remota e em nosso datacenter e, em 99% das vezes, é 0, mas às vezes o mysql mostra 1s. No tráfego maciço, tive muitas colisões devido ao aplicativo cliente fazer duas solicitações, resultando em duas consultas, inserir e selecionar. Em alguns casos, a linha ainda não estava lá , então usamos o hash do userID e corrigimos o problema
Espero que você aprenda com meus erros ;-)
Um cluster de banco de dados MySQL com balanceamento de carga (ou algum outro) é bastante inútil. Se você estiver gravando em mais de um servidor, terá problemas ou usará a replicação síncrona (que o MySQL não suporta de qualquer maneira) e isso prejudica muito o desempenho, pois é necessário sincronizar os bloqueios.
Eu recomendo que você divida as cargas de leitura / gravação e equilibre a carga entre os escravos do mysql e tenha um único mestre para gravações ou use um par de failover ativo / passivo para o seu mestre.
Essencialmente, você não pode escalar gravações colocando mais servidores em um banco de dados como escravos, pois cada um ainda precisa gravar toda a carga de gravação do seu aplicativo.
Para escalar gravações, você precisa dividir seus dados logicamente entre vários servidores, particionando ou "dividindo" etc. Isso geralmente exige alterações não triviais (acho muito difícil de testar) para seu aplicativo, para que você não queira fazer isso, a menos que REALMENTE preciso disso.
É claro que você pode usar o cluster do MySQL, se realmente quiser, mas é um mecanismo completamente diferente, com seus próprios recursos e desvantagens - é um pouco complicado de configurar, mas realmente fornece um banco de dados com alta carga de HA em hardware comum. Ele ainda sofre com as penalidades de desempenho de gravação ao usar a replicação síncrona, mas permite que você dimensione as gravações conforme foi incorporado no particionamento entre servidores.
Outro ótimo guia sobre esse assunto que eu encontrei ...
http://www.dancryer.com/2010/01/mysql-circular-replication
Esta é a parte 1 de uma série de três postagens:
Guia de cluster com balanceamento de carga do MySQL - Parte 1 - configurando os próprios servidores e configurando a replicação do MySQL.
Guia de Cluster com Balanceamento de Carga do MySQL - Parte 2 - configure um script para monitorar o status dos nós do cluster do MySQL, que usaremos no próximo guia para configurar nosso proxy.
Guia de cluster com balanceamento de carga do MySQL - Parte 3 - configurando o balanceador de carga com HAProxy, usando os scripts de monitoramento
Pessoalmente, a melhor maneira seria usar um balanceador de carga!
Sim, ele adiciona outro ponto de falha, mas qualquer rotina que você colocar em prática ou instalar em TODOS os clientes adiciona muito mais complexidade do que um balanceador de carga padrão ...
O Connector / J tem a capacidade de equilibrar as consultas em vários servidores. Isso se destina principalmente ao MySQL NDB Cluster, onde todos os nós SQL terão uma visão consistente dos dados, mas se você puder garantir que o banco de dados de dois mestres seja razoavelmente consistente entre esses dois mestres, pode ser seguro para o seu aplicativo.
A cadeia de conexão se pareceria com:
jdbc: mysql: loadbalance: // host-1, host-2, ... host-n / dbname? loadBalanceStrategy = "aleatório" & loadBalanceBlacklistTimeout = 5000
A divisão de gravações não diminui a carga dos servidores porque as gravações ainda precisam ser replicadas.
Se você estiver usando apenas 2 servidores, use pulsação com drbd e deixe o drbd manipular a replicação. Se o primeiro servidor falhar, o segundo servidor assumirá o controle. Se você deseja colocar o segundo servidor em uso, pode usar o gfs sobre drbd e, em seguida, executar o segundo servidor como somente leitura e usá-lo como um servidor de leitura. Quando ocorrer o failover, altere o servidor para leitura / gravação.
re: wackamole - o wackamole não está limitado a 2 servidores
Estou trabalhando em uma série de tutoriais sobre isso, mas é realmente simples de configurar.
Para dar uma resposta mais recente a esta pergunta, com a versão 5.6 do MySQL, ele introduziu o GTID (Global Transaction Identifieres) que visa tornar a replicação assíncrona mais robusta e colocar o MySQL na disputa pelo HA (Alta Disponibilidade) novamente.
Esta seção explica a replicação baseada em transações usando GTIDs (identificadores de transações globais). Ao usar GTIDs, cada transação pode ser identificada e rastreada conforme comprometida no servidor de origem e aplicada por quaisquer escravos; isso significa que não é necessário, ao usar GTIDs, fazer referência a arquivos ou posições de log nesses arquivos ao iniciar um novo escravo ou efetuar o failover para um novo mestre, o que simplifica bastante essas tarefas. Como a replicação baseada em GTID é completamente baseada em transações, é simples determinar se mestres e escravos são consistentes; desde que todas as transações confirmadas em um mestre também sejam confirmadas em um escravo, a consistência entre as duas é garantida. Você pode usar a replicação baseada em instrução ou em linha com GTIDs (consulte a Seção 16.2.1, “Formatos de replicação”); no entanto, para obter melhores resultados,
Referência: 16.1.3 Replicação com identificadores de transação global (documentação do MySQL)
Eu pensei que o uso do HAProxy para consultas de balanceamento de carga está introduzindo um SPOF (ponto único de falha) e adicionar batimentos cardíacos tornam essa solução complicada.
Uma solução mais simples é conectar-se através do conector Java JConnector, que visa carregar consultas de equilíbrio por meio de uma URL jdbc com todos os nós do MySQL. Ele pode lidar com configurações mestre / escravo ou mestre / mestre .
Isso torna possível configurar uma solução de cluster de HA pronta para uso com o MySQL.