Início / dba / Perguntas / 9328
Accepted
kfmfe04
Asked: 2011-12-18 08:01:03 +0800 CST

Topologias de replicação mestre-mestre Mysql em > 2 máquinas

  • 772

Tenho 3 servidores Mysql que gostaria de replicar: dois (incluindo o servidor principal) são locais e um é remoto. Vamos chamar meu servidor principal de A, o servidor secundário de B e um servidor de desenvolvimento remoto de C.

Como configuração possível, comecei a ler sobre uma configuração de anel . Alguns comentários parecem desprezar esse tipo de topologia.

Minha pergunta é, dado o estado atual do Mysql 5.1, quais tipos de topologias mestre-mestre são aconselháveis ​​e conhecidas por serem tolerantes a falhas?

Um anel é realmente uma má ideia, em geral?

No meu caso, A e B estão em uma intranet que não deve ter nenhuma falha de rede, então B pode teoricamente ser usado como um failover para A. Na maioria das vezes, estou trabalhando em C, uma máquina remota, que às vezes obtém soluços de rede ao alcançar A e B. Nenhum dos dados é crítico no momento (ou seja, contanto que eventualmente sejam espelhados, tudo bem), mas espero que A e B sejam espelhados firmemente - dentro de um prazo de 5 segundos em cargas leves (Acho que esse deve ser um requisito fácil, dados meus testes preliminares).

Atualmente, tenho B como escravo de A, mas estou ansioso para me tornar mestre-mestre em A, B e C.

mysql replication

1 respostas

  1. Best Answer

    Um anel pode ser uma ideia muito boa sob certas condições

    Para servidores A, B, C

    Servidor A

    • Mestre de B
    • escravo de C

    Servidor B

    • Mestre em C
    • escravo de A

    Servidor C

    • Mestre de A
    • escravo de B

    Todos os três servidores têm 3 bancos de dados (db1, db2 e db3)

    Aqui está a única configuração que protege os três bancos de dados

    • restringir todas as leituras e gravações em db1 no Servidor A
    • restringir todas as leituras e gravações no db2 no Servidor B
    • restringir todas as leituras e gravações no db3 no Servidor C

    A replicação faria o seguinte em resposta

    • banco de dados de backup db1 replicando para db2 e db3
    • banco de dados de backup db2 replicando para db3 e db1
    • banco de dados de backup db3 replicando para db1 e db2

    IMHO realizando gravações (INSERTs,UPDATEs,DELETEs) para db1 para o servidor A,B,C torna todos os valores de auto_increment separados e distintos. Isso tornaria difícil restaurar dados para outras caixas.

    Mais por vir...

    ATUALIZAR

    Eu tenho outra ideia maluca

    Você já ouviu falar em topologia em estrela? Eu postei coisas anteriormente sobre este assunto

    Criar um mestre com dois escravos

    Para servidores A, B, C

    Servidor A

    • Mestre de B e C
    • Todas as tabelas usam o mecanismo de armazenamento BLACKHOLE

    Servidor B

    • escravo de A
    • Todas as tabelas de usuário usam o mecanismo de armazenamento InnoDB

    Servidor C

    • escravo de A
    • Todas as tabelas de usuário usam o mecanismo de armazenamento InnoDB

    Benefícios

    • Publique todas as gravações (INSERTs, UPDATEs, DELETEs) para servir A
    • As gravações devem ser rápidas porque as tabelas BLACKHOLE são mapeadas para /dev/null
    • A replicação atual envia dados reais para os escravos (servidor B e servidor C)
    • nenhum dado real residirá no servidor A, apenas logs binários
    • Todos os SELECTs podem ir entre o servidor B e o servidor C por meio de um balanceador de carga
    • Os escravos seriam virtualmente idênticos em termos de conteúdo

    Desvantagens

    • Depois de configurar isso, você não pode usar livremente as instruções ALTER TABLE
    • Se a replicação for interrompida no Servidor A, ela para de atualizar os Escravos
    • 5

relate perguntas