Estou usando o MySQL-5.1.50 com uma configuração de replicação mestre-escravo.

Na maioria das vezes, o escravo fica para trás do mestre.

Quando executo show processlist;, não há nenhuma consulta demorando muito tempo. Eu ativei slow_logtambém. No entanto, ele não encontra nenhuma consulta de execução lenta.

O escravo está continuamente dando alertas de que a replicação está segundos atrás do mestre. Às vezes, o tempo de latência aumenta.

Como diagnosticar a causa do problema?

Preciso de ajuda urgente, pois esse problema persistiu nos últimos 20 dias.

O Seconds_Behind_Master é realmente como ver o passado através da viagem no tempo.

Pense nisso desta maneira:

• O Sol está a 93.000.000 de milhas da Terra
• A velocidade da luz é de 186.000 milhas / s
• A divisão simples mostra que são necessários aproximadamente 500 segundos (8 min 20 segundos) para que a luz do Sol alcance a Terra
• Quando você olha para o sol, na verdade não vê o sol. Você vê onde ficava 8 minutos e 20 segundos atrás.

Da mesma maneira, parece que o Mestre está processando muitas consultas ao mesmo tempo.

Você olha para o Escravo, corre SHOW SLAVE STATUS\Ge ele diz 200 para Seconds_Behind_Master. Como é calculado esse número? Hora do relógio do escravo (UNIX_TIMESTAMP (NOW ()) - TIMESTAMP da consulta quando ela foi concluída e registrada no log binário do mestre.

Há outra métrica a considerar além disso Seconds_Behind_Master. Essa métrica é chamada Relay_Log_Space. Isso representa a soma de todos os bytes para todos os arquivos de retransmissão no escravo. Por padrão, o maior log de retransmissão única é limitado a 1 GB. Se Relay_Log_Spacefor menor que 1 GB, isso indica que muitas consultas de longa execução são executadas no Master em paralelo. Infelizmente, devido ao encadeamento SQL da Replicação de natureza de thread único, as consultas são executadas uma atrás da outra.

Por exemplo, suponha que você tenha o seguinte cenário no mestre:

• O log de consulta lenta está ativado
• 20 consultas executadas em paralelo no mestre
• Cada consulta levou 3 segundos
• Cada consulta é registrada no registro binário mestre com o mesmo registro de data e hora

Quando o Escravo lê essas consultas em seu log de retransmissão e as processa uma a uma

• o relógio do escravo estará se movendo
• o TIMESTAMP para cada uma das 20 consultas será idêntico
• a diferença vai aumentar 3 segundos ser concluída a consulta
• isso resulta em 60 segundos para Seconds_Behind_Master

Em relação ao Log lento, o padrão para long_query_time é 10 segundos. Se todas as suas consultas nos logs de retransmissão forem inferiores a 10 segundos, você nunca detectará nada no Log de consultas lentas.

Tenho as seguintes recomendações para os servidores Mestre e Escravo

• RECOMENDAÇÃO # 1 : Atualize para o MySQL 5.5 . No MySQL 5.5 e no Percona Server 5.1.38+, você pode ajustar o InnoDB para acessar várias CPUs. Escrevi postagens anteriores sobre isso
  • Apr 26, 2012: O desempenho da CPU é relevante para um servidor de banco de dados?
  • Sep 20, 2011: Multi cores e desempenho do MySQL
  • Sep 12, 2011: Possível fazer o MySQL usar mais de um núcleo?
  • May 26, 2011: Sobre o desempenho de bancos de dados de thread único versus multithread
• RECOMENDAÇÃO # 2 : Use o InnoDB para todas as tabelas . O InnoDB armazena em cache dados e índices na RAM, o MyISAM apenas armazena em cache os índices.
• RECOMENDAÇÃO Nº 3 : Aumente a RAM . Você deve armazenar em cache mais dados e índices no escravo e no mestre
• RECOMENDAÇÃO Nº 4 : ajuste todas as consultas. Reduzir milissegundos de consultas executadas centenas de vezes ajuda bastante a reduzir Seconds_Behind_Master.

RESOLUÇÃO DE PROBLEMAS

Se você deseja ver as consultas que causam o atraso da replicação, faça o seguinte:

• SHOW SLAVE STATUS\G
• Obtenha o nome do log de retransmissão de Relay_Log_File
• STOP SLAVE;
• START SLAVE;
• No sistema operacional, cd /var/lib/mysqlou onde quer que os logs de retransmissão sejam gravados
• Despejar o log de retransmissão em um arquivo de texto

Por exemplo, vamos fazer SHOW SLAVE STATUS\G

               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.51.149
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 1024035856
               Relay_Log_File: relay-bin.000030
                Relay_Log_Pos: 794732078
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: search_cache
           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: 1024035856
              Relay_Log_Space: 794732271
              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:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 106451149

Se eu executar STOP SLAVE; START SLAVE;, o log de retransmissão será fechado e um novo será aberto. No entanto, você quer relay-bin.000030.

Despejar o conteúdo da seguinte maneira:

cd /var/lib/mysql
mysqlbinlog relay-bin.000030 > /root/RelayLogQueries.txt
less /root/RelayLogQueries.txt

Agora você pode ver as consultas que o escravo está tentando processar no momento. Você pode usar essas consultas como ponto de partida para o ajuste.

Qual formato de log binário você está usando? Você está usando ROW ou STATEMENT?
" SHOW GLOBAL VARIABLES LIKE 'binlog_format';"

Se você estiver usando ROW como um formato de log de bin, verifique se todas as suas tabelas possuem Chave Primária ou Única:
SELECT t.table_schema,t.table_name,engine FROM information_schema.tables t INNER JOIN information_schema .columns c on t.table_schema=c.table_schema and t.table_name=c.table_name and t.table_schema not in ('performance_schema','information_schema','mysql') GROUP BY t.table_schema,t.table_name HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;

Se você executar, por exemplo, uma instrução de exclusão no mestre para excluir 1 milhão de registros em uma tabela sem PK ou chave exclusiva, apenas uma verificação completa da tabela ocorrerá no lado do mestre, o que não é o caso do escravo.
Quando o ROW binlog_format está sendo usado, o MySQL grava as alterações das linhas nos logs binários (não como uma declaração como STATEMENT binlog_format) e essa alteração será aplicada no lado do escravo linha por linha, o que significa que uma verificação de tabela completa de 1 milhão ocorrerá no escravo para refletir apenas uma instrução de exclusão no mestre e isso está causando um problema de atraso no escravo.

O valor seconds_behind_master em SHOW SLAVE STATUS é a diferença entre a hora do sistema no mestre, que foi armazenada quando o evento foi originalmente executado e registrado no log binário ... e a hora do sistema no escravo quando o evento é executado lá.

Segundos atrás do mestre fornecerão valores incorretos se os relógios dos dois sistemas não estiverem sincronizados.