Alta disponibilidade do Mysql

Question

Eu tenho um aplicativo que recebe dados de aproximadamente 1000 fontes diferentes a cada dois minutos. Estes dados precisam ser salvos em um banco de dados OSS (provavelmente o MySQL - mas dependendo das respostas eu consideraria trocar se apropriado).

Os 1000 servidores externos que estão enviando as informações geralmente solicitam dados a cada 2 minutos do aplicativo.

O aplicativo é de dados críticos, pois não pode se dar ao luxo de ficar para baixo. Eu tenho a parte do aplicativo classificada para HA (alta disponibilidade), mas estou após sugestões para HA de banco de dados. O Oracle não é uma opção.

Um amigo sugeriu que o SQLlite fosse sincronizado entre os servidores de aplicativos, mas isso soa perigoso para mim. Eu olhei em uma configuração do banco de dados MySQL MASTER-MASTER, mas parece problemático e de comentários de usuários potencialmente instável.

Alguma sugestão?

Tem que rodar no linux, tem que ser de código aberto.

    

Answer 1

Estamos usando a replicação principal do MySQL por mais de dois anos na produção de bancos de dados críticos, sem nenhum problema. Em nossa configuração, os bancos de dados são replicados por meio de um link não dedicado instável. A configuração é fácil e a recuperação de desastres é sem dificuldades. Eu recomendo.

Anteriormente, estivemos usando uma replicação de escravo master- > do MySQL através de um link dedicado com heartbeat para failover, que é uma opção viável - mas ambas as máquinas têm que estar por trás do mesmo roteador.

    

Answer 2

Cluster do MySQL talvez?

Enfim, sim, esqueça o SQLite. É a solução errada para o seu problema.

    

Answer 3

O Mysql Cluster parece ser uma boa solução para você, no entanto depende do tamanho do banco de dados, porque por enquanto todos os dados devem caber na memória ao usar o Mysql Cluster

    

Answer 4

O MySQL Cluster parece ser a escolha óbvia, pois pode suportar 5 9s HA, mas não é adequado para aplicativos da Web.

Checkout Localizando sua solução de alta disponibilidade do MySQL - As perguntas:

link

Considerando seus requisitos (de gravação), acho que eu procuraria o Heartbeat / SAN se eu fosse você.

Felicidades

    

Answer 5

Master < - > replicação master pode ser um problema se houver alguma discrepância de dados entre as duas instâncias. No nosso caso, temos usado master-master para uma série de aplicações web usando servidores siloados (dois conjuntos de servidores, com MySQL, Apache e Squid, cada um), e no nosso caso temos sessões tabela que obtém tráfego pesado de gravação que pode resultar em colisões de gravação (dois conjuntos de dados sendo inseridos na mesma tabela com o mesmo ID).

Em casos como este, você precisa de alguma lógica pesada em sua camada de aplicativo para garantir que as gravações sejam divididas corretamente para que você nunca tenha uma colisão de gravação. Não é horrível, mas um erro de replicação não pode ser facilmente recuperado sem a intervenção do administrador do sistema. Nesse caso, o Master < - > Master pode, na verdade, resultar em menor disponibilidade.

Não desencorajá-lo, pois ele certamente funciona bem, uma vez que você tenha resolvido o problema, no entanto, existem algumas armadilhas irritantes.