Dans cette étape, nous allons simuler une erreur de réplication courante et montrer comment la résoudre. Cela vous aidera à comprendre comment résoudre les problèmes de réplication dans un scénario réel.
-
Simuler une erreur :
Une erreur de réplication courante se produit lorsque le serveur esclave rencontre une incohérence de données. Nous allons simuler cela en insérant manuellement une ligne dans la table test_replication.test_table sur le serveur esclave, ce qui causera un conflit lorsque le maître tentera de répliquer la même ligne.
Sur le serveur esclave, connectez-vous au serveur MySQL en tant qu'utilisateur root :
sudo mysql -u root
Insérez une ligne dans la table test_replication.test_table :
USE test_replication;
INSERT INTO test_table (data) VALUES ('This is an intentionally conflicting record on the slave');
exit
-
Déclencher la réplication :
Maintenant, insérez une autre ligne dans la table test_replication.test_table sur le serveur maître :
sudo mysql -u root
USE test_replication;
INSERT INTO test_table (data) VALUES ('This is a new record from master');
exit
Cette insertion sur le maître déclenchera la réplication vers l'esclave. Cependant, comme nous avons inséré manuellement une ligne conflictuelle sur l'esclave, le processus de réplication rencontrera probablement une erreur.
-
Vérifier l'état de l'esclave :
Sur le serveur esclave, connectez-vous au serveur MySQL en tant qu'utilisateur root :
sudo mysql -u root
Vérifiez l'état de l'esclave :
SHOW SLAVE STATUS\G
Examinez la sortie. Vous devriez voir que Slave_SQL_Running est probablement défini sur No, et le champ Last_SQL_Error contiendra un message d'erreur indiquant une clé en double ou un conflit similaire.
Exemple de sortie d'erreur :
...
Slave_IO_State: Waiting for master to send event
Master_Host: master_host
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 154
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 311
Relay_Master_Log_File: mysql-bin.000002
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: Duplicate entry '1' for key 'PRIMARY'
Skip_Counter: 0
Exec_Master_Log_Pos: 154
Relay_Log_Space: 472
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
...
-
Corriger l'erreur de réplication :
Pour corriger cette erreur, nous allons sauter l'événement problématique sur le serveur esclave. Cela indique à l'esclave d'ignorer l'événement qui a causé l'erreur et de continuer la réplication à partir de l'événement suivant.
Tout d'abord, arrêtez le thread SQL de l'esclave :
STOP SLAVE SQL_THREAD;
Ensuite, sautez l'événement d'erreur :
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
Cette commande indique à l'esclave de sauter l'événement suivant dans le journal de relais.
Enfin, démarrez le thread SQL de l'esclave :
START SLAVE SQL_THREAD;
-
Vérifier que la réplication fonctionne à nouveau :
Vérifiez à nouveau l'état de l'esclave :
SHOW SLAVE STATUS\G
Vous devriez maintenant voir que Slave_SQL_Running est défini sur Yes, et Last_SQL_Error est vide. La réplication devrait fonctionner normalement à nouveau.
-
Vérifier la cohérence des données :
Sur le serveur esclave, vérifiez le contenu de la table test_replication.test_table :
USE test_replication;
SELECT * FROM test_table;
exit
Vous devriez voir à la fois l'enregistrement conflictuel intentionnel et le nouvel enregistrement du maître. L'enregistrement conflictuel était déjà présent, et le nouvel enregistrement a été répliqué avec succès après avoir sauté l'erreur.
+----+-----------------------------------------------------+
| id | data |
+----+-----------------------------------------------------+
| 1 | This is a test record from master |
| 2 | This is an intentionally conflicting record on the slave |
| 3 | This is a new record from master |
+----+-----------------------------------------------------+
3 rows in set (0.00 sec)
Vous avez maintenant simulé avec succès une erreur de réplication et la corrigé en sautant l'événement problématique. Il s'agit d'une technique courante pour résoudre les problèmes de réplication causés par des incohérences de données. N'oubliez pas que le saut d'événements doit être effectué avec prudence, car cela peut entraîner une divergence des données si cela n'est pas géré correctement. Il est crucial de comprendre la cause de l'erreur avant de sauter des événements.
