Eu tenho 3 servidores MySQL, digamos A,B,C .
O que eu quero fazer é tornar todos eles mestres e escravos. Se houver atualização em qualquer um dos servidores MySQL, ela deve ser replicada para todos os servidores.
Estudei sobre a replicação circular e descobri que ela pode ser implementada com ela.
Alguém pode me dar todas as etapas para realizar a replicação conforme indicado entre três servidores.
Mais um ponto, também quero ignorar algumas das tabelas de um banco de dados.
Além disso, quais são as ressalvas desse tipo de replicação?
Rolando disse como fazer e sua resposta é excelente. A verdade é que a replicação circular é uma ideia horrível, terrível, terrível. Não faça isso. Sempre. "Absolutos nunca são verdadeiros", mas, neste caso, é bem próximo.
Em vez de ter um único ponto de falha, agora você tem três.
E se um dos servidores cair? Agora a replicação está quebrada em todos os lugares.
Como você o substitui facilmente e alinha as posições do log binário? Você não pode fazer isso sem fazer uma análise de log binário muito complicada e propensa a erros.
Portanto, agora você precisa restaurar todos os três servidores de um backup. Espere, esse backup foi feito no mesmo momento? Não, porque não há como fazer um backup transacional em vários servidores. Então, você fica com a replicação quebrada e tentando consertá-la com pt-table-checksum e pt-table-sync... ou reconstruir todo o cluster do zero.
Só porque você pode fazer algo, não significa que você deva. Não faça isso, sério. Eu não estou brincando.
Para este exemplo, vamos supor o seguinte
replicator@'10.1.1.%'r3plic4t0RPasso 01) Adicione essas opções em [mysqld] em /etc/my.cnf no ServerA
Passo 02) Adicione essas opções em [mysqld] em /etc/my.cnf no ServerB
Passo 03) Adicione essas opções em [mysqld] em /etc/my.cnf no ServerC
Passo 05)
service mysql restartno ServidorA, ServidorB, ServidorCEtapa 06) Criar GRANT para usuário de replicação no ServidorA, ServidorB, ServidorC
Passo 07) Executar
SHOW MASTER STATUS;no ServidorCPasso 08) Execute este
CHANGE MASTER TOcomando no ServerAPasso 09) Executar
SHOW MASTER STATUS;no ServidorAEtapa 10) Execute este
CHANGE MASTER TOcomando no ServerBEtapa 11) Executar
SHOW MASTER STATUS;no ServidorBEtapa 12) Execute este
CHANGE MASTER TOcomando no ServerCEtapa 13)
START SLAVE;no ServidorAEtapa 14) Aguarde 5 segundos e, em seguida,
SHOW SLAVE STATUS\Gno ServerASe Slave_IO_Running=Yes e Slave_SQL_Running=Yes, a replicação está funcionando
Etapa 15)
START SLAVE;no ServidorBEtapa 16) Aguarde 5 segundos e, em seguida,
SHOW SLAVE STATUS\Gno ServerBSe Slave_IO_Running=Yes e Slave_SQL_Running=Yes, a replicação está funcionando
Etapa 17)
START SLAVE;no ServidorCEtapa 18) Aguarde 5 segundos e, em seguida,
SHOW SLAVE STATUS\Gno ServerCSe Slave_IO_Running=Yes e Slave_SQL_Running=Yes, a replicação está funcionando
ATUALIZAÇÃO 2012-05-07 12:22 EDT
A única razão para usar auto_increment_offset / auto_increment_increment nesta configuração seria fazer gravações em todos os mestres e leituras de qualquer mestre.
Há apenas um cenário com esta configuração em que você não é obrigado a usar auto_increment_offset / auto_increment_increment :
Para qualquer banco de dados mydb - Se você gravar em mydb apenas no ServidorA, leia de mydb no ServidorA - Se você gravar em mydb apenas no ServidorB, leia de mydb no ServidorB - Se você gravar em mydb apenas no ServidorC, leia de mydb no ServidorC