Discussion :

[laraki.fissel]

Bonjour

j'ai un problèle au niveau de la réplication MySQL, une requete delete bien optimisée augmente trop le lag mysql.
je pense que la requete attend un commit d'un autre worker.
processlist me donne le resultat suivant :

| 5 | system user | | NULL | Connect | 49410 | Waiting for master to send event | NULL |
| 6 | system user | | NULL | Connect | 19677 | Waiting for dependent transaction to commit | NULL
| 7 | system user | | NULL | Connect | 39262 | Executing event | delete from ..........
| 8 | system user | | NULL | Connect | 39222 | Waiting for an event from Coordinator | NULL |
| 9 | system user | | NULL | Connect | 39288 | Waiting for an event from Coordinator | NULL |
| 10 | system user | | NULL | Connect | 39891 | Waiting for an event from Coordinator | NULL

je signale que je dispose de la version mysql 5.7.17 sous centos,

log_slave_updates = ON
slave_parallel_workers = 8
slave_preserve_commit_order = ON
slave_parallel_type = LOGICAL_CLOCK

Merci pour votre aide.

[Artemus24]

Salut laraki.fissel.

Peut-être avez-vous un dead lock ?

@+

[laraki.fissel]

Bonjour Artemus24

Non aucun dead lock n'est detecté au niveau de la base.


Cdt

[Artemus24]

Salut laraki.fissel.

Non aucun dead lock n'est détecté au niveau de la base.

Ce n'est pas au niveau de la base que cela se détecte mais dans vos traitements, et surtout sur la façon dont vous gérez vos transactions.

je pense que la requete attend un commit d'un autre worker.

Si ce commit n'arrive jamais, votre transaction est bloquée. C'est ça le dead lock dont je vous parle.

Si l'on veut être puriste, le dead lock, ce n'est pas exactement votre cas. Vous avez deux ressources et deux utilisateurs.
Le premier utilisateur attend pour terminer la ressource N°1 de pourvoir débuter le ressource N°2.
Tandis que le second utilisateur attend pour terminer la ressource N°2 de pouvoir débuter la ressource N°1.

Ici, vous avez deux utilisateurs, dont l'un est bloqué et ne peut pas faire de commit.
L'autre se met à attendre que la ressource se libère et comme elle ne se libère pas, un time out termine brusquement le processus.

Vous devez vérifier que chaque intervention en mise à jour ou en suppression se fasse sous forme d'une transaction.
Pour expliquer simplement, vous devez être le seul à intervenir en écriture sur la ligne. On nomme cela une section critique.
Pour gérer les accès, vous devez les sérialiser. Pour ce faire, vous devez déclarer dans le fichier my.ini :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

transaction-isolation = SERIALIZABLE

Pour gérer vos transactions, je vous conseille de lire : https://dev.mysql.com/doc/refman/5.7/en/commit.html

@+

[SQLpro]

Si c'était un verrou mortel (parlons français) il serait détecté et une des sessions serait tuée... Si ce n'est pas le cas, c'est donc une attente sans cycle.

A +