Início / dba / Perguntas / 131241
Accepted
amatusko
Asked: 2016-03-04 15:49:26 +0800 CST

Replicação híbrida síncrona/assíncrona?

  • 772

Temos uma situação em que gostaríamos de ter replicação síncrona em nosso data center principal, mas replicar de forma assíncrona em outra região. Nosso segundo data center fica a 3.000 milhas de distância (Site B) e o usamos como um backup quente caso precisemos fazer failover de nosso data center principal (Site A) devido a uma falha no data center.

Não estamos armazenando nenhum dado financeiro ou transacionalmente sensível. Nossos dados são importantes, é claro, mas não são críticos nesse grau, pois consistem principalmente em atualizações de conteúdo do site de editores de conteúdo.

Estamos interessados ​​em usar Percona XtraDB ou Galera Cluster no Site A combinado com algo como MySQL, MariaDB ou Percona Server para o Site B, mas não sabemos se isso é possível ou como podemos implementar tal solução. Podemos ter um esquema de replicação síncrona no Site A com um backup assíncrono para os servidores do Site B? Seria possível manter uma implementação multimestre no Site A com réplicas no Site B?

Se for possível, suponho que exigiria várias tecnologias. Quais tecnologias ou configurações são soluções viáveis?

mysql replication

1 respostas

  1. Best Answer

    É mais simples que você pode esperar.

    Use um dos nós no cluster Galera/PXC como mestre para a réplica assíncrona.

    O nó que atua como mestre para o escravo precisa dos seguintes parâmetros de configuração adicionais para que isso funcione:

    log_bin
log_slave_updates
binlog_format = ROW

    Conecte um escravo MySQL/Percona/MariaDB assíncrono a ele usando uma configuração de replicação mestre/escravo assíncrona normal.

    Isso deve ser sobre isso. Idealmente, o escravo terá o mesmo tipo e série de lançamentos dos nós do cluster, seja MariaDB ou Percona em ambas as extremidades, embora um escravo MariaDB seja quase sempre uma aposta segura, independentemente do mestre. Em nenhum caso o slave deve rodar uma versão mais antiga, então quando você fizer upgrades, sempre atualize o slave primeiro. Você também pode subtenir escravos adicionais do primeiro ou conectar um segundo escravo a um nó de cluster diferente como seu mestre.

    Bônus: habilitar slave_compressed_protocolno escravo para que os dados transmitidos do mestre sejam compactados no fio.

    • 3

relate perguntas