Início / dba / Perguntas / 6882
Accepted
Phanindra
Asked: 2011-10-18 04:08:44 +0800 CST

A porta mestre está desativada do IP público, o log do MySQL não está sendo atualizado

  • 772

Minha configuração de replicação do MySQL é pela Internet. Mestre está em IP público.

Se eu parar o serviço mysql no mestre, imediatamente uma mensagem de erro é lançada no escravo. E quando inicio o serviço, o escravo está se conectando imediatamente ao mestre e a replicação está acontecendo bem.

Mas se a porta estiver desativada no IP público, nenhum erro será lançado no log do escravo e mostrado como sucesso da conexão, mas os dados não serão replicados do mestre para o escravo. E se a porta estiver habilitada para IP público, ela será exibida como sucesso na conexão e os dados não serão replicados do mestre para o escravo.

Até que eu reinicie o escravo, os dados não serão replicados do mestre para o escravo. Depois de reiniciar o escravo, tudo corre bem.

Posso saber qual é o motivo de não ser replicado.

E existe alguma maneira de saber o status do mestre do escravo, quando esse tipo de comportamento ocorre.

Também existe alguma opção para parar o escravo quando a porta mestre está desativada.

Por favor me ajude nisso.

Estou usando o MySQL versão 5.0.24.

mysql replication

1 respostas

  1. Best Answer

    O problema básico decorre do IO Thread do Slave. Às vezes, ele tem o péssimo hábito de se fazer de bobo e não checar ou fazer ping no master.

    A replicação semi-síncrona do MySQL 5.5 permite que o próprio master expire e retorne à replicação assíncrona . Escravos executando replicação semissíncrona devem ter um IO Thread mais sensível agora.

    Em relação à sua situação particular, você está usando o MySQL 5.0.24 ??? Essa é uma versão muito antiga. Existem dois relatórios de bug ( Bug1 e Bug2 ) discutindo isso.

    Apenas me dei conta de que você fez essa pergunta antes e o DTest respondeu . Dando crédito onde o crédito é devido, os relatórios de bug vieram de sua resposta.

    Seria bom ser informado quando o IP Público estiver sendo desabilitado do acesso Escravo. Dessa forma, você pode executar STOP SLAVE;o escravo com antecedência.

    Você também perguntou se existe uma maneira de saber o status do mestre do escravo, quando esse tipo de comportamento ocorre.

    Aqui está um típicoSHOW SLAVE STATUS\G

    mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.80.136
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000019 <<------
          Read_Master_Log_Pos: 277892198 <<------
               Relay_Log_File: relay-bin.000058
                Relay_Log_Pos: 37535484
        Relay_Master_Log_File: mysql-bin.000019 <<------
             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: 277892198 <<------
              Relay_Log_Space: 277892637 <<------
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
1 row in set (0.00 sec)

    Por favor observe o seguinte:

    • Master_Log_File : Arquivo de log do mestre cujo último SQL foi copiado pela última vez para retransmitir logs
    • Read_Master_Log_Pos : Posição do log em Master_Log_Filecujo último SQL foi copiado pela última vez para retransmitir logs
    • Relay_Master_Log_File : Arquivo de log do mestre cujo SQL foi executado pela última vez a partir dos logs de retransmissão
    • Exec_Master_Log_Pos : Posição do log em Relay_Master_Log_Filecujo SQL foi executado pela última vez a partir dos logs de retransmissão

    Se nenhum desses valores estiver se movendo, isso pode significar que todo o SQL foi processado ou que o escravo está processando uma instrução SQL no thread SQL que veio da posição Exec_Master_Log_Posdo Master Log Relay_Master_Log_File.

    Agora, olhe para Relay_Log_Space. Esse número representa a soma total de todos os tamanhos de arquivo para todos os logs de retransmissão. Se Slave_IO_Runningfor Sim e Relay_Log_Spacenão estiver mudando, verifique o mestre executando SHOW MASTER STATUS;. Deve gostar de algo assim:

    mysql> show master status;
+------------------+-----------+--------------+------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.000019 | 682563021 |              |                  |
+------------------+-----------+--------------+------------------+
1 row in set (0.00 sec)

    Se o Master (File,Position) SHOW MASTER STATUS;estiver além do Slave (Master_Log_File,Read_Master_Log_Pos) de SHOW SLAVE STATUS\G, então o IO Thread no Slave está morto para intenções e propósitos, mesmo se Slave_IO_Running for Yes.

    • 1

relate perguntas