¿Qué causa el error 1062 de MySQL - entrada duplicada al iniciar esclavo?

• Versión maestra de MySQL: 5.5.16-1
• Versión esclava de MySQL: 5.5.18-1

La instantánea del maestro es creada por:

mysql> FLUSH TABLES WITH READ LOCK;
shell> mysqldump --all-databases --master-data > dbname_`date +%F`.sql

Este archivo de volcado se importa en el esclavo (que se inicia con la --skip-slave-startopción) sin error:

shell> pv dbname_`date +%F`.sql | mysql -u root -p

Pero recibí el siguiente error al ejecutar el mysql> start slave;:

    Last_SQL_Errno: 1062
    Last_SQL_Error: Error 'Duplicate entry '115846' for key
'PRIMARY'' on query. Default database: 'db'. Query: 'INSERT INTO
request_posted (id, user_id, channel, message, link, picture, name, ...

Solo hay un registro con ID 115846 en el maestro:

mysql> select count(*) from request_posted where id=115846;
Current database: db

+----------+
| count(*) |
+----------+
|        1 |
+----------+
1 row in set (0.01 sec)

Intenta saltear algunas consultas con:

mysql> STOP SLAVE; 
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; 
mysql> START SLAVE;

no ayudó No quiero omitir esos errores agregando:

slave-skip-errors = 1062

al my.cnfarchivo porque puede traer inconsistente esclavo.

¿Cuál puede ser la razón de este error?

ACTUALIZAR

No es así como suelo configurar la replicación mySQL

¿Qué pasos crees que no sigo el documento?

Me pregunto si encontrarás el mismo problema si configuraras toda la configuración en lugar de pasar el comando mysqldump.

No, funciona normalmente si también cambio el maestro a las coordenadas correspondientes.

Intentaría soltar la base de datos en el esclavo, asegurarme de que los binlogs estén limpios y comenzar de nuevo. Compruebe también la tabla en cuestión en el maestro para asegurarse de que los índices no tengan errores.

¿Es suficiente eliminar (mover) todos los datos? Lo hice y obtuve el mismo resultado.

Responder a @Dmytro Leonenko

'mostrar el estado del esclavo \ G' en el esclavo para asegurarse de que esté configurado correctamente, MASTER_LOG_POS es 0

Solo 'mostrar esclavo statug \ G' después de la importación pero antes de 'iniciar esclavo'; nos puede dar la respuesta

Realicé una copia de seguridad del datadir, eliminé todo y ejecuté, importé mysql_install_dbel archivo de volcado, ejecuté change master toy aquí están los resultados:

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: x.x.x.x
                  Master_User: xx
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: 
          Read_Master_Log_Pos: 4
               Relay_Log_File: mysqld-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: 
             Slave_IO_Running: No
            Slave_SQL_Running: No
              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: 0
              Relay_Log_Space: 106
              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: NULL
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)

Me pregunto por qué Master_Log_Pos es 4?

Qué tratar de solucionar su problema:

2. Debe eliminar master.info en esclavo primero y reiniciar mysql
3. emitir CHANGE MASTER TO MASTER_HOST = 'XX.XX.XX.XX', MASTER_USER = 'repl', MASTER_PASSWORD = 'slavepass';
4. do mysqldump con la opción '--flush-logs' en master
5. 'mysql -u user -p <dump.sql' en esclavo
6. 'mostrar el estado del esclavo \ G' en el esclavo para asegurarse de que esté configurado correctamente, MASTER_LOG_POS es 0
7. 'iniciar esclavo' en esclavo

Qué verificar también:

• Formato Binlog: MIXTO
• server_ids son diferentes en maestro y esclavo

El problema se debe a la configuración del maestro en un servidor de producción en ejecución ANTES de realizar el volcado (por lo que puedo decir). Entonces, hay consultas escritas en el master_log que ya se han ejecutado en los datos que residen en el esclavo. En realidad, nunca vi una solución en el sitio web o la lista de correo de mysql. Entonces, se me ocurrió la siguiente solución que resolvió mi problema.

en esclavo:

mysql> STOP SLAVE;
mysql> FLUSH PRIVILEGES;  # dump likly included users too

en maestro:

mysql> RESET MASTER;

en esclavo:

mysql> RESET SLAVE;
mysql> START SLAVE;

por cierto, ejecuté mi volcado con lo siguiente en el esclavo:

mysqldump -uROOTUSER -pROOTPASSWORD -hMYSQLMASTER.EXAMPLE.COM --all-databases --delete-master-logs | mysql -uROOTUSER -pROOTPASSWORD

Espero que esto ayude a alguien más.

http://dev.mysql.com/doc/refman/5.0/en/reset-master.html

http://dev.mysql.com/doc/refman/5.0/en/reset-slave.html

Si no desea REDO el procedimiento completo, una buena solución sería utilizar

STOP SLAVE;    
SET GLOBAL sql_slave_skip_counter=1;
START SLAVE;

Si hay demasiados errores, una buena idea sería automatizarlo usando un script bash.

Ref: Corregir error de entrada duplicada

Tuve el problema exacto y el enlace de Ut xd me ayudó. pero el comando en ese enlace tenía un error de sintaxis y aquí está la versión que funcionó para mí:

while [ 1 ]; do if [ `mysql -uroot -ppassword -e"show slave status \G;" | grep "Duplicate entry" | wc -l` -eq 2 ] ; then mysql -uroot -ppassword -e"stop slave; set global sql_slave_skip_counter=1; start slave;"; fi; sleep 1; mysql -uroot -ppassword -e"show slave status\G"; done

Básicamente verifica si hay un error de entrada duplicada y omite este evento del maestro. y hazlo en un bucle.

En mi caso, el problema se resuelve con los siguientes comandos

por los siguientes pasos

STOP SLAVE;
RESET SLAVE;
START SLAVE;