Eu recomendo prontamente Master / Master sobre Master / Slave por várias razões
- Você tem dois servidores de banco de dados configurados para serem mestres com os logs binários mais recentes
- Failover manual para o Passive Master é apenas um 'add add ip' de distância.
- Você pode configurar um IP para um mestre ativo (usando ucarp )
- Você pode isolar as gravações de banco de dados em uma máquina (o que tiver o DBVIP)
- O Passive Master (que não possui o DBVIP) pode estar disponível para leituras, mysqldumps, XtraBackups, tar / gzips
- Reconfigurar um Escravo para ser um Novo Mestre e o Velho Mestre para um Novo Escravo não é nem rápido, nem trivial, nem parece, especialmente quando você precisa recuperar rapidamente um Servidor de BD.
Existem apenas dois (2) inconvenientes na utilização do Master / Master
- Você não pode executar nenhum failover se o Passive Master for > 0 segundos atrás. O failover muito cedo apresenta um aplicativo com dados que estão desatualizados em segundos e a possibilidade de chaves duplicadas pode fazer com que ele pareça feio tentando gravar novos dados com lacunas nos dados. Para ambientes com pouca gravação, você pode conviver com esse cenário, pois a replicação pode ser alcançada rapidamente antes do failover.
- Os caches (MyISAM Key Cache e InnoDB Buffer Pool) para ambos os Masters não são os mesmos. O failover para o Passive Master pode causar um pico de carga inicial do servidor com leituras e gravações para obter caches de banco de dados com os dados corretos. Você pode superar isso com mk-slave-prefetch , em breve ser renomeado pt-slave-prefetch (à la Percona Toolkit)
O que parece estar em uma área cinza é executar gravações de banco de dados em ambos os Masters. Embora as opções auto_increment_increment e auto_increment_offset foram inventados para mitigar valores de auto_increment em dois servidores diferentes para a mesma tabela, um uso verdadeiramente seguro de Master / Master permitindo DB Writes em ambos os servidores se enquadra em dois cenários:
- Todas as tabelas que usam PRIMARY KEYS não se baseiam no incremento automático
- Escrevendo para bancos de dados mutuamente exclusivos nos diferentes mestres. Em outras palavras, se você restringir as gravações do banco de dados ao esquema1 em um mestre e nunca executar gravações do banco de dados no esquema1 no outro mestre.
ATUALIZAÇÃO 2012-10-04 11:42 EDT
O cluster Percona XtraDB (PXC) surgiu como um bom Banco de Dados MultiMaster Síncrono. Isso é ótimo para bancos de dados multilocatários.
Você terá que lembrar o seguinte sobre o PXC
- Dimensionando requisitos de memória e configuração de disco para InnoDB
- lembrando que o DDL / DML no MyISAM não é replicado nas Bibliotecas do Replicador do Conjunto de Gravações do Galera. Como os comandos GRANT são neutros para o mecanismo de armazenamento, a tabela MyISAM no esquema mysql é tratada sem problemas. Qualquer DML contra o mysql.user não é replicada.
- O nó mais fraco torna todo o Cluster lento, especialmente no horário do COMMIT. Portanto, certifique-se de que todos os nós tenham configurações idênticas de hardware / software / OS / VM / RAM / Rede.
- Você pode executar gravações moderadas com balanceamento de carga em todos os nós. Quanto mais nó no cluster. quanto mais lento o COMMITs.
- O PXC é diferente do cluster do MySQL, pois todos os nós contêm os mesmos dados
Quando se trata de failover, qualquer nó pode ser um mestre. Você espalha leituras no cluster. Para bancos de dados de multilocatários, você pode distribuir gravações (INSERTs, UPDATEs, DELETEs) sem preocupações de deadlocking. Os deadlocks ainda são possíveis quando as gravações no mesmo banco de dados são distribuídas pelo Cluster. Due diligence na codificação do seu aplicativo para evitar deadlocking.