Co powoduje błąd MySQL 1062 - zduplikowany wpis podczas uruchamiania slave?

• Wersja MySQL Master: 5.5.16-1
• Wersja MySQL Slave: 5.5.18-1

Migawka mistrza jest tworzona przez:

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

Ten plik zrzutu jest importowany do urządzenia podrzędnego (który jest uruchamiany z --skip-slave-startopcją) bez błędu:

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

Ale wystąpił następujący błąd podczas wykonywania 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, ...

Jest tylko jeden rekord o ID 115846 na urządzeniu głównym:

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

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

Spróbuj pominąć niektóre zapytania za pomocą:

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

nie pomogło Nie chcę pomijać tych błędów, dodając:

slave-skip-errors = 1062

do my.cnfpliku, ponieważ może to doprowadzić niewolnikami niespójne.

Co może być przyczyną tego błędu?

AKTUALIZACJA

Nie tak zazwyczaj konfiguruję replikację mySQL

Jakie kroki według ciebie nie postępuję zgodnie z dokumentem?

Zastanawiam się, czy napotkasz ten sam problem, jeśli skonfigurujesz całą konfigurację zamiast przekazać komendę mysqldump.

Nie, to działa normalnie, jeśli zmienię również master na odpowiednie współrzędne.

Spróbowałbym upuścić bazę danych na slave, upewnić się, że binlogs są czyste i zacząć od nowa. Sprawdź również tabelę na wzorcu, aby upewnić się, że indeksy nie zawierają błędów.

Czy usunięcie (przeniesienie) wszystkich danych jest wystarczające? Zrobiłem to i uzyskałem ten sam wynik.

Odpowiedz na @Dmytro Leonenko

'show status slave \ G' na slave, aby upewnić się, że jest poprawnie skonfigurowany, MASTER_LOG_POS ma wartość 0

Tylko „show slave statug \ G” po imporcie, ale przed „start slave;” może dać nam odpowiedź

Utworzyłem kopię zapasową datadiru, usunę wszystko i uruchomię mysql_install_db, zaimportuję plik zrzutu, uruchom change master toi oto wyniki:

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)

Zastanawiam się, dlaczego Master_Log_Pos ma 4 lata?

Co spróbować rozwiązać problem:

2. Najpierw usuń master.info na slave i zrestartuj mysql
3. wydaj CHANGE MASTER TO MASTER_HOST = 'XX.XX.XX.XX', MASTER_USER = 'repl', MASTER_PASSWORD = 'slavepass';
4. wykonaj mysqldump z opcją '--flush-logs' na master
5. 'mysql -u user -p <dump.sql' na slave
6. 'show status slave \ G' na slave, aby upewnić się, że jest poprawnie skonfigurowany, MASTER_LOG_POS ma wartość 0
7. „start slave;” na niewolniku.

Co również sprawdzić:

• Format binlog: MIESZANY
• id_serwera jest inny dla master i slave

Problem jest spowodowany ustawieniem wzorca na działającym serwerze produkcyjnym PRZED wykonaniem zrzutu (o ile wiem). Istnieją więc zapytania zapisane w dzienniku głównym, które zostały już wykonane na danych znajdujących się na urządzeniu podrzędnym. Nigdy nie widziałem rozwiązania na stronie mysql lub liście mailingowej. Więc wymyśliłem następujące rozwiązanie, które rozwiązało mój problem.

na niewolniku:

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

na mistrzu:

mysql> RESET MASTER;

na niewolniku:

mysql> RESET SLAVE;
mysql> START SLAVE;

tak na marginesie, uruchomiłem mój zrzut z następującymi na niewolniku:

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

Mam nadzieję, że to pomaga komuś innemu.

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

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

Jeśli nie chcesz REDO pełnej procedury, dobrym rozwiązaniem byłoby skorzystanie z niej

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

Jeśli takich błędów jest zbyt wiele, dobrym pomysłem byłoby zautomatyzowanie ich za pomocą skryptu bash.

Ref: Naprawianie błędu podwójnego wpisu

Miałem dokładny problem i pomógł mi link Ut xd. ale polecenie w tym łączu zawierało błąd składniowy, a oto wersja, która działała dla mnie:

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

Zasadniczo sprawdza, czy występuje błąd podwójnego wpisu i pomija to zdarzenie od mastera. i zrób to w pętli.

W moim przypadku problem rozwiązują następujące polecenia

wykonując następujące kroki

STOP SLAVE;
RESET SLAVE;
START SLAVE;