Erreur d'échec de réplication GTID 1062

Question

Je rencontre des problèmes lors de la configuration d'une réplication esclave. Les deux utilisent mysql 5.6 et ont GTID sur. Le maître se trouve dans les bases de données cloud de l'espace de stockage. Instance HA

Le vidage que j'ai inclus possède un GTID et le maître.

J'ai activé GTID sur l'esclave en ajoutant ce qui suit à l'esclave (je ne l'ai pas allumé). J'ai ensuite supprimé toutes les bases de données, donc c'était frais.

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 

Commandes j'ai couru:

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 

J'ai suivi les étapes à: (Comment restaurer un esclave dans une bonne et lente)

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

Answer 1

En général, il signifie que la l'ensemble de données sur le maître et l'esclave est différent. Ce que nous faisons normalement est de créer une sauvegarde binaire avec xtrabackup, de le transférer à un esclave, puis de démarrer la réplication avec MASTER_AUTO_POSITION=1. Dans votre exemple particulier d'abord besoin de charger le cliché et puis exécuter la commande CHANGE MASTER. En fait, après une conversation avec l'OP, il a compris que le problème était de créer une mysqldump partielle, plutôt que de jeter toutes les informations.