Se você tiver seguido as instruções e suia configuração de replicação não está funcionando, primeiro verifique o seguinte:
Verifique as mensagens no log de erros. Muitos usuários perderam tempo por não fazer isto cedo o suficiente.
            O master está logando ao log binário? Verifique com
            SHOW MASTER STATUS. Se estiver,
            Position será diferente de zero. Se
            não, verifique que deu a opção log-bin
            do master e definiu o server-id.
          
            O slave está executando? Faça SHOW SLAVE
            STATUS e verifique se os valores
            Slave_IO_Running e
            Slave_SQL_Running são ambos
            Yes. Se não, verifique a opção do
            slave.
          
            Se o slave estiver rodando, ele estabeleceu uma conexão com
            o master? Faça SHOW PROCESSLIST,
            encontre as threads de E/S e SQL (see
            Secção 4.11.3, “Detalhes de Implementação da Replicação” para
            ver como é exibido), e verifique a sua coluna
            State. Se ela disser Connecting
            to master, verifique os privilégios do usuário
            de replicação no master, nome de máquina do master, sua
            configuração de DNS, se o master está atualmente em
            execução e se ele está a alcance do slave.
          
Se o slave estava em execução antes mas agora parou, a razão é que normalmente algumas consultas que obtem sucesso no master falham no slave. Into nunca deve acontecer se você tiver tirado a cópia apropriada do master e nunca modificou os dados no slave fora da thread slave. Se isto ocorrer, você encontrou um erro; leia abaixo como relatá-lo.
Se uma consulta bem sucedida no master se recusou a executar no slave, e não parece prático fazer um nova sincronização completa do banco de dados (p.ex.: deletar o banco de dados slave e fazer uma nova cópia do master), tente o seguinte:
                Primeiro veja se a tabela do slave estava diferente da
                do master. Entenda como isto aconteceu (pode ser um
                erro: leia o registro de alterações no manual online
                do MySQL como http://www.mysql.com/documentation para
                verificar se este é um erro conhecido e se ele já
                está corrigido). Então faça a tabela do slave
                idêntica a do master e execute START
                SLAVE.
              
Se o acima não funcionar ou não se aplica, tente entender se ele estaria seguro para fazer uma atualização manualmente (se necessário) e então ignorar a próxima consulta do master.
Se você decidiu que você pode saltar a próxima consulta, execute as seguintes instruções:
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n;mysql>START SLAVE;
                O valor de n deve ser 1 se a consulta
                não usa AUTO_INCREMENT ou
                LAST_INSERT_ID(). Senão, o valor de
                ser 2. A razão para usarem um valor de 2 para consultas
                que usam AUTO_INCREMENT ou
                LAST_INSERT_ID() é que elas gastam
                dois eventos no log binário do master.
              
Tenha certeza de que você não está tendo problemas com um erro antigo atualizando para a versão mais recente.
Se você tem certeza que o slave iniciou perfeitamente em sincronia com o master, e que as tabelas envolvidas não foram atualizadas fora da thread slave, relate o erro.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.

