GTID-Replikation fehlgeschlagen Fehler 1062

Question

Ich habe Probleme beim Einrichten einer Slave-Replikation. Beide verwenden mysql 5.6 und haben GTID aktiviert. Der Master befindet sich in den Cloud-Datenbanken des Rackspace. HA-Instanz

Der Dump, den ich verwende, enthält eine GTID und den Master.

Ich aktiviert GTID am Slave durch Hinzufügen der folgenden zum Slave (ich hatte es nicht auf). Ich habe dann alle Datenbanken gelöscht, also war es frisch.

gtid_mode=ON 
enforce_gtid_consistency=true 
log_bin=/Library/Application Support/appsolute/MAMP PRO/db/mysql56/log 
log_slave_updates=true 
binlog_format=mixed 

Befehle Ich lief:

mysqldump --tz-utc=false -u root -pPASSWORD --host=HOST --all-databases > dump.sql 

mysql>CHANGE MASTER TO MASTER_HOST = 'MASTER_HOST', MASTER_PORT = 3306, MASTER_USER = 'repl_user', MASTER_PASSWORD = 'PASSWORD', MASTER_AUTO_POSITION = 1; 
mysql>reset master; 
mysql>source dump.sql; 
mysql>start slave; 


mysql> show slave status \G 
*************************** 1. row *************************** 
       Slave_IO_State: Waiting for master to send event 
        Master_Host: IP 
        Master_User: repl_user 
        Master_Port: 3307 
       Connect_Retry: 60 
       Master_Log_File: replica-2053073453-bin.000026 
      Read_Master_Log_Pos: 1022001275 
       Relay_Log_File: mysql-relay-bin.000002 
       Relay_Log_Pos: 7600 
     Relay_Master_Log_File: replica-2053073453-bin.000026 
      Slave_IO_Running: Yes 
      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: 1062 
        Last_Error: Error 'Duplicate entry '0db833be2a27f7fac7fa3ee1165256a398b7065f' for key 'PRIMARY'' on query. Default database: 'phppoint_demo2'. Query: 'INSERT INTO `phppos_sessions` (`id`, `ip_address`, `timestamp`, `data`) VALUES ('0db833be2a27f7fac7fa3ee1165256a398b7065f', 'IP', 1487705858, '')' 
       Skip_Counter: 0 
      Exec_Master_Log_Pos: 1018575999 
       Relay_Log_Space: 3433080 
       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: 1062 
       Last_SQL_Error: Error 'Duplicate entry '0db833be2a27f7fac7fa3ee1165256a398b7065f' for key 'PRIMARY'' on query. Default database: 'phppoint_demo2'. Query: 'INSERT INTO `phppos_sessions` (`id`, `ip_address`, `timestamp`, `data`) VALUES ('0db833be2a27f7fac7fa3ee1165256a398b7065f', 'IP', 1487705858, '')' 
    Replicate_Ignore_Server_Ids: 
      Master_Server_Id: 2053073453 
        Master_UUID: 979f153e-2d80-11e6-bb91-00185119e861 
      Master_Info_File: /Library/Application Support/appsolute/MAMP PRO/db/mysql56/master.info 
        SQL_Delay: 0 
      SQL_Remaining_Delay: NULL 
     Slave_SQL_Running_State: 
      Master_Retry_Count: 86400 
        Master_Bind: 
     Last_IO_Error_Timestamp: 
    Last_SQL_Error_Timestamp: 170221 14:55:55 
       Master_SSL_Crl: 
      Master_SSL_Crlpath: 
      Retrieved_Gtid_Set: d2ce9c03-2d7f-11e6-bb8c-001851fe939d:10115103-10119980 
      Executed_Gtid_Set: 979f153e-2d80-11e6-bb91-00185119e861:1-17, 
d2ce9c03-2d7f-11e6-bb8c-001851fe939d:1-10115113 
       Auto_Position: 1 

Ich folgte Schritte auf: (Wie ein Sklave in einem guten und langsamen Weg zur Wiederherstellung)

https://www.percona.com/blog/2013/02/08/how-to-createrestore-a-slave-using-gtid-replication-in-mysql-5-6/

Answer 1

Normalerweise bedeutet dies, dass die Datensatz auf Master und Slave ist anders. Normalerweise erstellen wir eine binäre Sicherung mit xtrabackup, übertragen diese an einen Slave und starten dann die Replikation mit MASTER_AUTO_POSITION=1. In Ihrem speziellen Beispiel zuerst müssen Sie den Speicherauszug laden und dann führen Sie den CHANGE MASTER Befehl.

In der Tat, nach einem Gespräch mit dem OP er herausgefunden, dass das Problem in der Erstellung eines partiellen mysqldump, anstatt alle Informationen zu kippen.