MySQL em topologia em estrela

Question

Eu tenho um banco de dados central com todos os dados no MySQL 5.1-lastest-stable. Eu quero ligar vários clientes em um relacionamento mestre-mestre.

Pergunta
Como configuro uma topologia em estrela com 1 servidor central no meio com vários bancos de dados de clientes para que as alterações em um cliente sejam propagadas primeiro para o servidor central e daí para todos os outros bancos de dados de clientes?

Informações do banco de dados
Estou usando o inno-db para todas as tabelas e habilitei o log binário.
Além disso, aprendi a fazer master-master entre os bancos de dados.
Todas as tabelas têm o incremento automático de números primários das chaves primárias. Onde o deslocamento e início de autoincrements são ajustados para diferentes bancos de dados do cliente, nunca há conflitos de chave primária.

Por que eu quero isso
Eu tenho software cliente (não um site ou php) que se conecta a um banco de dados MySQL local no laptop, isso precisa ser sincronizado com um banco de dados central, para que todas as pessoas usando o programa em seu laptop vejam todas as outras alterações que outras pessoas fazem

Eu não quero conectar-se diretamente ao banco de dados central porque se a conexão com a internet cair entre o laptop e o banco de dados central, meu aplicativo morre. Nesta configuração, o aplicativo continua, o laptop simplesmente não recebe atualizações de outras pessoas até que a conexão com o banco de dados central seja restabelecida.

    

Answer 1

Existe uma razão específica pela qual o que você propôs é impossível de alcançar com o MyISAM e o InnoDB.

Uma topologia em estrela garante que um mestre seja o centro do universo, não o escravo. A Replicação do MySQL não foi projetada para ter um escravo lido de múltiplos mestres simultaneamente. Só pode ler de um mestre de cada vez. O comando CHANGE MASTER TO conecta um escravo a um, e apenas um , mestre.

De acordo com o livro Noções básicas sobre o MySQL Internals , página 219 parágrafo 2 sob o título subtítulo "Multi-mestre" diz o seguinte:

MySQL Replication was not originally written with multi-master support in mind. A slave is natively capable of replicating only one master. A fairly simple patch can be created to allow one slave to collect updates from multiple masters without conflict resolution. This was done at one time, but for a number of reasons did not make it into the main branch of the source tree. A more complex patch to allow some conflict resolution was planned at one point, but for a number of reasons did not make it to development. It stll may be implemented in the future.

O livro Alto desempenho MySQL: otimização, backups, replicação e muito mais uma caixa na parte superior da página 368 (Capítulo 8: Topologias de Replicação) cujo título é "O MySQL não Suporta Replicação Multimaster" . A caixa tem os seguintes parágrafos:

We use the term multimaster replication very specifically to describe a slave with more than one master. Regardless of what you may have been told, MySQL (unlike some other database servers) does not support the configuration illustrated in Figure 8-6 at present. However, we show you some ways to emulate multimaster replication later in this chapter.

Unfortunately, many people use this term casually to describe any setup where there is more than one master in the entire topology, such as the "tree" topology we show later in this chapter.Other people use it to describe what we call master-master replication, where the servers are mutually master and slave.

These terminology problems cause a lot of confusion and even arguments, so we think it's best to be careful with names. Just imagine how hard it will be to communicate if MySQL adds support for a slave with two masters! What term will you use to describe that if you haven't reserved "multimaster replication" fro the purpose?

Embora as técnicas de emulação listadas nas páginas 373-375 do subtítulo "Emulando a replicação multimestre" sejam teoricamente possíveis (usando o mecanismo de armazenamento BLACKHOLE) e tenham sido implementadas com sucesso por outras pessoas para emular apenas dois mestres, ainda assim nunca é possível suportar topologia proposta em particular.

Eu havia abordado esta questão antes . Na verdade, a resposta que dei foi feita com sucesso o tempo todo. É por isso que os vendedores de seguros podem levar um laptop para a casa de uma pessoa e coletar dados de seguro de uma pessoa que solicita um seguro. O vendedor acabaria se conectando a um computador central para baixar o aplicativo de um novo cliente. Por sua vez, o computador central pode baixar as últimas informações do atuário, de modo a avaliar o que uma política custaria ao candidato. Funciona na mesma premissa para conectar um laptop a um computador central, um laptop por vez.

    

Answer 2

Não é possível, o Mysql suporta apenas replicação circular multi-master-master.

Este artigo descreve essa replicação muito bem.

    

Answer 3

ATUALIZAÇÃO IMPORTANTE Eu sou corrigido. Embora em teoria tudo o que eu disse aqui seja sólido e válido, o MySQL não suporta a replicação multi-master, por razões que eu não conheço. No entanto, outros servidores de banco de dados suportam esse tipo de topologia, portanto, se for necessária uma topologia de estrela mestre-mestre verdadeira, a mudança para um servidor diferente também será necessária.

Eu não concordo com @lg, acho que é possível. (Desculpe antecipadamente que esta "resposta" não tem detalhes, eu não tenho um banco de dados MySQL na minha frente e nunca fiz isso antes, mas há mais aqui do que caberia em um comentário.)

Na replicação mestre-mestre do MySQL, ambos os servidores assumem o papel de mestre e escravo; Da mesma forma, na repetição circular de mestre-mestre-etc, todos os servidores são novamente mestre e escravo.

De outro ângulo, o MySQL é totalmente capaz de ter um servidor mestre replicado para múltiplos escravos - nós tivemos isto (master para 3 escravos) configurados no meu trabalho anterior.

Desde que sabemos que um mestre também pode ser um escravo, e sabemos que um mestre pode ter múltiplos escravos, e sabemos (a partir da maneira como funciona a replicação circular) que instruções replicadas podem ser colocadas no log binário (para o próximo escravo para pegar) e que um servidor pode identificar suas próprias instruções em um log binário em seu próprio mestre (é isso que mantém o "primeiro" servidor em um cenário de replicação circular replicando suas próprias instruções novamente e mantendo eles vão em um loop infinito), parece bastante razoável que você possa configurar um único master servindo múltiplos slaves, o qual é escravo de múltiplos masters (o que, sei, é possível, porque o MySQL suporta multi-master replication para o propósito de um único backup em tempo real para vários servidores).

Agora, admito que não posso oferecer detalhes de como configurar isso, e admitirei prontamente que não é provável que você obtenha muito (se algum) apoio a essa configuração pouco ortodoxa. , mas aqui estão algumas dicas para você começar:

1. Todos os servidores devem ser configurados para registrar instruções replicadas (conforme a replicação circular usual, como o artigo @lg vinculado a).
2. Os servidores "spoke" (por falta de um termo melhor) devem ser configurados em um relacionamento mestre-mestre com o servidor central "hub".

Isto deve ser fácil de testar - você diz que já tem 2 ajustes em um relacionamento mestre-mestre, então agora configure um terceiro em um relacionamento mestre-mestre com o que você quer ser o centro " hub ", em seguida, veja se a replicação funciona como você quer (embora lembre-se da etapa 1 - típico mestre-mestre, acredito que não coloque instruções replicadas no log binário).