Replicação MySQL fora de sincronia

Question

Eu tenho um sistema de replicação master-master. No entanto, devido a um problema de incremento automático, recebi um erro na replicação ... e ele parou de ser replicado.

Alguém me disse para fazer:

stop slave; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;  start slave;

Não funcionou. Então eles me disseram para fazer:

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2;  

Não funcionou. Então, para testar, eu fiz:

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 99999; 

Começa, mas não está atualizando. Eu criei uma tabela no DB1 ... e ela não está aparecendo no DB2 ...

Abaixo está o SHOW STATUS para meu DB1 e DB2 (eu os bato juntos):

mysql> show master status\G
*************************** 1. row ***************************
            File: mysql-bin.000605
        Position: 2019727
    Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

mysql> show slave status\G;
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host:
                Master_User: 
                Master_Port: 
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000605
        Read_Master_Log_Pos: 2008810
             Relay_Log_File: mysqld-relay-bin.001731
              Relay_Log_Pos: 10176595
      Relay_Master_Log_File: mysql-bin.000470
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 4255373725
        Exec_Master_Log_Pos: 10176458
            Relay_Log_Space: 135062517347
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 1376343
1 row in set (0.00 sec)

Como corrijo para que eles sincronizem novamente? Obrigado.

    

Answer 1

Você não parece realmente saber o que está fazendo. Primeiro você deve obter um despejo de dados para proteger contra qualquer tipo de corrupção.

Então você está usando uma replicação Master-Master, certo?

Isso soa estranho, já que você só fornece um status SLAVE e um status MASTER, mas precisamos das saídas de status MASTER e SLAVE. Além disso, não há instruções replicate_ignore_ *, isso não se parece com uma replicação Master-Master. Além disso, não há instruções de erro no SLAVE STATUS. Eles teriam mostrado quaisquer erros de replicação.

Como corrigir isso: Obtenha um dump limpo de cada mestre e insira-o no outro mestre. É descrito no manual do mysql, aqui está a versão curta:

mysql> FLUSH TABLES WITH READ LOCK;
$> mysqldump -uroot -p<pass> --opt --all-databases | gzip --fast > dump_master1.sql.gz
mysql> UNLOCK TABLES;

Lembre-se: não basta executar um comando que alguém lhe contou! Procure no manual primeiro e verifique o que ele faz. Configurar seu SKIP_SLAVE_COUNTER para algo como 9999 é a razão pela qual sua nova tabela não está aparecendo em seu escravo, porque ela ignora 9999 declarações SQL, o que provavelmente ainda não aconteceu! Normalmente você não ajusta SKIP_SLAVE_COUNTER para mais 1, depois executa START SLAVE e vê com SHOW SLAVE STATUS se houver algum novo erro.

    

Answer 2

Se você precisar redefinir os escravos e tiver um bom dump que tenha as informações de dados mestres (mysqldump com a opção --master-data), você poderá usar o último dump para ressincronizar:

Conecte-se ao escravo e problema do MySQL:

STOP SLAVE;
RESET SLAVE;
CHANGE MASTER to MASTER_USER='master user', MASTER_PASSWORD='master user password';

No escravo, recarregue o banco de dados escravo do último dump mestre que você tem:

gzip -dc masterdump.sql.gz |mysql --user=username --password=password

Reinicie o escravo:

START SLAVE

Se tudo correr bem, o escravo começará a replicar a partir do local do último despejo que você carregou. Isso pode levar algum tempo, por isso, verifique os SEGUNDOS ATRÁS DO MESTRE para esperar que ele os acompanhe.

    

Answer 3

Seconds_Behind_Master: 1376343

Por isso, você não está vendo o banco de dados que criou, porque o escravo ainda está mexendo no registro binário do mestre. Quando está 0 segundo atrás do mestre, você começará a ver as alterações que você faz replicar para o escravo.

    

Answer 4

Se tudo mais falhar, remova o mestre "ruim" do serviço, faça o dump e restaure uma nova cópia limpa do banco de dados para ele. Siga os passos habituais para "adicionar outro mestre" para o fazer.

    

Answer 5

Tente verificar se não é um problema de firewall. Tente parar e reiniciar o escravo. isto :    Slave_IO_Running: Sim           Slave_SQL_Running: Sim significa que tudo parece estar bem ... você poderia passar as configurações de replicação?

    

Answer 6

Note que pulando 99,999 eventos de log, seu mestre e escravo provavelmente não conterão os mesmos dados. Você pode usar o script mk-table-checksum para verificar o conteúdo mestre e escravo.

Eu nunca pulo mais de um evento por vez e sempre tento entender a causa de quaisquer erros de replicação. Se eu obter vários / muitos erros de replicação em uma linha, geralmente é um sintoma de outros problemas (tabela / disco corrompido, por exemplo).