Existe uma abordagem mais estável que você pode tentar

Aqui está algo para lembrar

Sempre que você executar CHANGE MASTER TO, ele apagará todos os logs de retransmissão que você tiver. Você não deseja manter logs de retransmissão de comandos nos quais ainda não executou nenhum SQL

A seguir, um trecho retirado de uma postagem que fiz em 03 de fevereiro de 2012: Como resolver o desligamento/indisponibilidade do servidor mestre no mysql com replicação mestre-escravo :

Observe que há dois conjuntos de coordenadas de replicação do Mestre

• (Master_Log_File,Read_Master_Log_Pos)
• (Relay_Master_Log_File,Exec_Master_Log_Pos)

Existe uma grande diferença entre eles

• (Master_Log_File,Read_Master_Log_Pos)informa a última declaração binlog do arquivo de log do mestre e a posição de log que o escravo leu do mestre e colocou em seus registros de retransmissão.
• (Relay_Master_Log_File,Exec_Master_Log_Pos)informa a última declaração binlog do arquivo de log do Master e a posição do log que o Slave leu do Master e colocou em seus Relay Logs QUE É O PRÓXIMO A SER EXECUTADO NO SLAVE .

O que você quer são duas coisas:

1. Apague todos os logs binários que você possui
2. Comece a coletar entradas de log binário do último SQL executado com êxito.

No seu caso, você deve usar o segundo conjunto de Coordenadas de Replicação

• Relay_Master_Log_File
• Exec_Master_Log_Pos

É fácil desconfiar de um log de retransmissão corrompido, conforme mostrado na mensagem de erro. O que mais dói é um Master Log corrompido. Você terá que pular obstáculos, se for esse o caso. Por outro lado, se uma das outras situações foi o motivo do log de retransmissão corrompido, a abordagem mais simples e concisa é a que afirmei.

Para ter certeza, o que quer que seja relatado para Relay_Master_Log_File, se esse log binário específico ainda existir no mestre, execute um mysqlbinlog nele. Se ele despejar totalmente sem caracteres corrompidos, vá em frente e use o segundo conjunto de coordenadas de replicação.

Do meu mesmo post anterior

mysql> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 10.48.20.253
                Master_User: replicant
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000254
        Read_Master_Log_Pos: 858190247
             Relay_Log_File: relay-bin.066069
              Relay_Log_Pos: 873918
      Relay_Master_Log_File: mysql-bin.000254
           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: 858190247
            Relay_Log_Space: 873772
            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
1 row in set (0.00 sec)

observe que as Coordenadas de replicação do SHOW SLAVE STATUS\Gque foi executado pela última vez são (mysql-bin.000254,858190247). O CHANGE MASTER TOcomando neste caso seria:

CHANGE MASTER TO master_log_file='mysql-bin.000254',master_log_pos=858190247;

De uma chance !!!

ATUALIZAÇÃO 2012-09-14 16:38 EDT

Se você está preocupado com os logs de retransmissão de armazenamento, apenas limite os logs de retransmissão. Em SHOW SLAVE STATUS\G, existe um campo chamado Relay_Log_Space. Isso fornece a soma de todos os tamanhos de relé em bytes. Você sabia que poderia colocar um limite nesse número?

A opção é chamada relay_log_space_limit .

Por exemplo, se você deseja limitar o número total de bytes para 10G, faça o seguinte

PASSO 01) Adicione isto ao /etc/my.cnf no Slave

[mysqld]
relay_log_space_limit = 10G

PASSO 02) Executar service mysql restartno Escravo

e é isso !!!

Quando o relé mais antigo tiver todas as suas entradas processadas, ele é deletado e um novo log de relé é criado. Isso é preenchido até que todos os logs de retransmissão somem 10G. Essa é a única maneira de controlar problemas de espaço de log de retransmissão descontrolada.

ATUALIZAÇÃO 2012-09-14 18:10 EDT

SUGESTÃO: Se você fizer backups mysqldump dos dados no Escravo a cada meia-noite, poderá configurar o seguinte para restringir ter 1 TB de logs binários:

PASSO 01) Adicione isto ao /etc/my.cnf no Master

[mysqld]
expire_logs_days = 14

PASSO 02) Execute esta consulta no Mestre

mysql> PURGE BINARY LOGS BEFORE DATE(NOW()) - INTERVAL 14 DAY;

PASSO 03) service mysql restartno Mestre

PASSO 04) Adicione um script de backup mysqldump a um crontab no Slave

Isso tornará o Slave mais útil e controlará o excesso de logs binários para se preocupar

Para resolver o problema de pouco espaço em disco para logs binários no mestre, movi os logs binários para outra montagem de disco e, em seguida, criei links simbólicos para eles, para que o mestre soubesse onde encontrá-los. Links simbólicos podem ser criados com "ln -s" ou "cp -s".
Exemplo:

cd /disk1/mysql/binlogs/
ls /disk2/binlogs | xargs -l1 -i cp -s /disk2/binlogs/{} ./

No slave, para evitar desperdício de recursos de rede, usei a configuração que Rolando sugeriu - relay_log_space_limit. Isso foi útil porque os logs de retransmissão foram corrompidos várias vezes antes que o escravo finalmente alcançasse várias transações no mestre.

Usei um método diferente para resolver o problema do que inicialmente explorei. As soluções que eu estava explorando parecem complicadas e há risco de perda de dados com elas. Embora, mais tarde, descobri que algumas das etapas que estava tentando alcançar são suportadas usando o comando CHANGE MASTER para ler o relé do próprio servidor ou os logs binários. Mas isso é apenas uma peça do quebra-cabeça. Com o MySQL 5.5 tendo somas de verificação de replicação e outros recursos, talvez eu não precise descobrir isso se atualizar para 5.5.

Os manuais do MySQL em http://dev.mysql.com/doc/refman/5.0/en/change-master-to.html dizem:

O próximo exemplo mostra uma operação menos utilizada. É usado quando o escravo possui arquivos de log de retransmissão que você deseja que ele execute novamente por algum motivo. Para fazer isso, o mestre não precisa estar acessível. Você só precisa usar CHANGE MASTER TO e iniciar o thread SQL (START SLAVE SQL_THREAD):

MUDAR MESTRE PARA RELAY_LOG_FILE='slave-relay-bin.006',
RELAY_LOG_POS=4025;

Você pode até usar a segunda operação em uma configuração sem replicação com um servidor independente e não escravo para recuperação após uma falha. Suponha que seu servidor travou e você o restaurou a partir de um backup. Você deseja reproduzir os próprios arquivos de log binários do servidor (não arquivos de log de retransmissão, mas arquivos de log binários regulares), denominados (por exemplo) myhost-bin.*. Primeiro, faça uma cópia de backup desses arquivos de log binário em algum lugar seguro, caso você não siga exatamente o procedimento abaixo e acidentalmente faça com que o servidor limpe o log binário. Use SET GLOBAL relay_log_purge=0 para segurança adicional. Em seguida, inicie o servidor sem a opção --log-bin. Em vez disso, use --replicate-same-server-id, --relay-log=myhost-bin (para fazer o servidor acreditar que esses arquivos de log binários regulares são relé arquivos de log) e opções --skip-slave-start.

MUDAR MESTRE PARA RELAY_LOG_FILE='myhost-bin.153',
RELAY_LOG_POS=410, MASTER_HOST='some_dummy_string'; START ESCRAVO SQL_THREAD;

O servidor lê e executa seus próprios arquivos de log binários, obtendo assim a recuperação de falhas. Terminada a recuperação, execute STOP SLAVE, desligue o servidor, exclua os arquivos master.info e relay-log.info e reinicie o servidor com suas opções originais.

Especificar a opção MASTER_HOST (mesmo com um valor fictício) é necessário para fazer o servidor pensar que é um escravo.

O método a seguir deve funcionar em teoria, o principal problema é descobrir corretamente de qual posição parar o processamento do(s) log(s) de retransmissão recém-criado(s) e em que posição iniciar o processamento dos logs de retransmissão salvos. Outro problema é identificar qual log/posição usar do mestre se houver mais logs de retransmissão corrompidos.

1. Pare a replicação no escravo.
2. Registro Master_Log_File / Read_Master_Log_Pos.
3. Encerre a instância escrava.
4. Mova os logs de retransmissão para um local seguro.
5. Inicie a instância escrava.
6. Execute o comando change master e reprocesse os logs binários da posição com falha.
7. Aguarde até que o próximo ou alguns logs de retransmissão sejam criados.
8. Pare a replicação no escravo.
9. Use o comando CHANGE MASTER para processar os logs de retransmissão que estão no local seguro. Identifique em qual arquivo e posição começar.
10. Defina o escravo para replicar a partir do mestre no arquivo/posição de log do mestre de leitura registrado na etapa 2.