Recuperar um servidor mestre MySQL com falha do escravo

Question

estamos construindo uma configuração simples de MySQL / mestre / escravo usando replicação assíncrona, com o MySQL enterprise 5.5.17 em ambos os servidores e tabelas baseadas em innoDB. Em caso de falha do servidor mestre, gostaríamos de oferecer aos nossos usuários a possibilidade de recuperar o mestre usando o conteúdo do banco de dados mais atualizado do escravo. No servidor mestre, o banco de dados e os logs binários são armazenados em diferentes dispositivos de disco, para melhor confiabilidade.

Qual seria a melhor maneira de fazer isso? Eu estava tentando descrever um procedimento para isso, mas não tenho certeza se isso está correto:

1. Certifique-se de que todas as instruções contidas no registro de retransmissão do escravo sejam executadas. Idealmente, eu poderia executar um STOP SLAVE IO_THREAD, mesmo que não fosse necessário, já que o mestre supostamente caiu e nenhuma outra instrução está chegando ao escravo, e espere que os eventos remanescentes do relé sejam concluídos.
2. Encerre o banco de dados no escravo e copie os arquivos para os arquivos do banco de dados no mestre.
3. Do relay-log.info e do master.info no escravo, eu deveria ser capaz de descobrir qual é o último log binário no mestre a partir do qual o escravo estava lendo e em qual posição.
4. Eu poderia repetir os logs binários no master da última declaração executada pelo slave antes que o master colidisse com a última declaração disponível nos logs.
5. Eu deveria redefinir o SLAVE e reiniciar a replicação a partir da última declaração executada pelo escravo antes que o master tenha sido danificado.

Está tudo bem?

    

Answer 1

Na ordenação para simplificar a promoção do Escravo para um Mestre, tenho uma sugestão para manter o Escravo mais próximo do Mestre.

Você deve usar a ferramenta mk-slave-prefetch .

Aqui está a beleza dessa ferramenta: Em um escravo, ele lerá os logs de retransmissão, procurará todas as consultas que tenham uma cláusula WHERE, convertê-lo em SELECT e executá-lo. Dessa forma, os caches para InnoDB e MyISAM são essencialmente os mesmos no Escravo e no Mestre. As diferenças devem ser menores.

Aqui está outra coisa que você precisará: Ter a configuração Mestre e Escravo usando a Replicação Circular. Dessa forma, tanto o mestre quanto o escravo têm o log binário ativado.

Como isso ajuda? Quando o Master falha e você faz o failover para o Slave, o arquivo master.info no Master conterá o último local em que o Slave executou seu SQL. Aqui está como você descobre:

Para este exemplo, teremos a Replicação Circular entre M1 e M2

Execute este comando no M2 (seu mestre atual): SHOW SLAVE STATUS\G

Você deve ver algo assim:

mysql> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 10.64.100.253
                Master_User: replicant
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000834
        Read_Master_Log_Pos: 823413571
             Relay_Log_File: relay-bin.002505
              Relay_Log_Pos: 823391419
      Relay_Master_Log_File: mysql-bin.000834
           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: 0
        Exec_Master_Log_Pos: 823391282
            Relay_Log_Space: 823413708
            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: 1
1 row in set (0.00 sec)

Por favor, tome nota de dois campos:

• Relay_Master_Log_File
• Exec_Master_Log_Pos

Esses dois campos representam o último arquivo de log e a posição de registro de um mestre que foi executado com sucesso no escravo.

Suponha que o M1 falhou, você fez failover para o M2 e exibiu o M1. Seu objetivo é restabelecer a Replicação Circular. Com uma falha, existe a possibilidade de a replicação perder o seu lugar. Aqui está o que fazer:

Step01) Execute SHOW SLAVE STATUS\G no M1

Step02) Obtenha Relay_Master_Log_File e Exec_Master_Log_Pos do Step01. Para este exemplo, deixe Relay_Master_Log_File ser mysql-bin.000834 e Exec_Master_Log_Pos seja 823391282.

Step03) Execute estes comandos

STOP SLAVE;
CHANGE MASTER TO master_log_file='mysql-bin.000834',master_log_pos=823391282;
START SLAVE;
SELECT SLEEP(5);
SHOW SLAVE STATUS\G

Aqui está o que procurar:

• Se Seconds_Behind_Master for numérico, a replicação está em execução. Apenas espere até chegar a zero.
• Se Seconds_Behind_Master for NULL, a Replicação está Quebrada
  • Se Slave_IO_Running = Yes e Slave_SQL_Running = No, um erro de SQL quebrou a replicação. Prossiga para corrigir o erro
  • Se Slave_IO_Running = No e Slave_SQL_Running = Yes, então o arquivo de log ou posição de log não existe.

Você pode corrigir isso com

STOP SLAVE;
CHANGE MASTER TO master_log_file='mysql-bin.000835',master_log_pos=<new pos>;
START SLAVE;
SELECT SLEEP(5);
SHOW SLAVE STATUS\G

O que é o newpos?

• Para o MySQL 5.5, o newpos é 107
• Para o MySQL 5.1, newpos é 106
• Para o MySQL 5.0, o newpos é 98

Se você implementar a Replicação Circular e roteirizar adequadamente essas coisas usando esses princípios, você obterá a recuperação do Mestre e do Escravo.