HAProxy mysql write failover

2

Eu tenho um servidor HAProxy com balanceamento de carga de dois servidores mysql que estão no modo master-master / active-passive. Posso ver que dimensionei com êxito todos os READS para meus dois nós de banco de dados, mas como alternaria facilmente os masters para operações de gravação se o atual mestre de gravação ficar inativo?

Neste momento, tenho um arquivo de configuração em cada servidor App para um DB_HOST_W para gravações e DB_HOST_R para leituras. DB_HOST_R aponta para o servidor HAProxy. DB_HOST_W aponta para um dos nós principais.

O HAProxy cuida do failover automaticamente para operações READ, mas seria extremamente demorado ter que atualizar o arquivo de configuração e alterar o valor DB_HOST_W para 4+ servidores de aplicativos em caso de falha.

Existe uma maneira melhor? O que estou perdendo aqui?

Quero salientar que tenho a seguinte configuração:

server primary 10.152.142.184:3306 check
server secondary 10.152.142.185:3306 check backup

Mas eu não gosto porque, apesar de enviar todas as operações WRITE para o primário, ele também envia TODAS as operações READ para o primário, e remove a escalabilidade.

    
por Freddie 24.02.2014 / 17:14

2 respostas

1

Sem falar da conveniência de sua solução, a maneira de alcançar seu objetivo é definir dois frontends ouvindo duas portas diferentes, por exemplo, 3306 e 3307 e dois backends, um com sua configuração somente leitura e um com sua configuração de gravação. Em seguida, altere seu aplicativo para que DB_HOST_R e DB_HOST_W possam incluir um número de porta.

Outra solução é atribuir outro endereço IP ao servidor e ter dois frontends vinculados a IPs específicos, em vez de bind *:3306 e dois backends como acima.

    
por 24.02.2014 / 19:42
0

Idealmente ... isso seria implementado no lado do aplicativo.

Para uma implementação no lado do servidor, empregamos o Cluster do MySQL . Eu sempre achei as configurações mestre-mestre do MySQL mais úteis do que valem a pena.

O maior problema que você enfrentará com essa configuração é o keepalive behavior. Se o seu aplicativo espera conversar com o mesmo banco de dados e ele falhar (ou apenas balancear a carga para outro), você pode ver erros interessantes dependendo da sua implementação.

Curto & & Long

O MySQL Cluster foi projetado para esse tipo de coisa, mas existem dicas que você precisará revisar com suas equipes de desenvolvimento / sistemas.

    
por 24.02.2014 / 18:34