MySQL Replication Slave est suspendu après la rencontre définie @@ session.gtid_next = 'anonyme';
J'ai récemment installé deux installations identiques par défaut de MySQL 5.7 sous Ubuntu Server 16.04 et les configurées pour effectuer une réplication de journal binaire. Jusqu'à présent, cela fonctionne bien, mais soudainement, la réplication cesse de continuer et que le fil de requête esclave fonctionne à 100% de la CPU sans faire de travail.
Après une recherche, j'ai constaté que le statut esclave indique que c'est bien derrière le maître. Utilisation de MySQLBinlog sur le fichier Binlog indiqué par relais_master_log_file et position EXEC_MASTER_LOG_POS, j'ai découvert que la déclaration exécutée à ce poste est la suivante:
SET @@SESSION.GTID_NEXT= 'ANONYMOUS';
En quelque sorte, l'esclave se bloque lorsque vous essayez d'exécuter cette déclaration, envoyant la charge de la CPU à 100% (ce que j'ai découvert la situation en premier lieu).
Sauf en ayant l'esclave sauter cette affirmation utilisant SET GLOBAL sql_slave_skip_counter=1 Il n'est pas clair pour moi quelle est la cause réelle de ce problème et comment je devrais résoudre ce problème.
Toute aide sera grandement appréciée!
Je suis actuellement dans le même problème. Rhel6, Percona 5.7.15-9. C'est un problème récurrent, pas une chose ponctuelle, alors sauter la déclaration est juste un correctif temporaire. Ça va être brisé bientôt dans mon cas.
J'ai fait un peu plus de creuser:
ps -eLo %cpu,pid,spid,cmd | grep <mysqld pid>
Cela m'a eu le PID (vraiment, ID de fil) de tous les fils MySQL, avec l'utilisation de la CPU de chacun. Sur mon système, un seul d'entre eux était relativement élevé (le fil esclave SQL, je présume).
À partir de ce:
strace -s 128 -p <thread-pid>
Cela m'a eu une boucle continue de lecture, Pays, des appels Lsek. Chacun a un descripteur de fichier comme premier argument ... toujours le même. Donc:
ls -l /proc/<thread-pid>/fd/<id-number-from-strace>
C'est un lien symbolique du fichier en cours de lecture. Dans mon cas, c'était un fichier de myisam aléatoire dans une base de données. Le contenu de cette table correspond à la sortie des cordes de la strace, bien que je ne puissiez pas le dire tout de suite (lu sur).
J'étais incapable de faire quoi que ce soit avec cette table - "en attente de verrouillage de niveau de table". J'ai sauté la déclaration pour récupérer la réplication à jour et que comme par magie la table était à nouveau utilisable. J'ai fait une réparation, optimiser et analyser la table sur elle. Aucun d'entre eux n'a rien signalé, mais j'espère que cela aidera peut-être quand même.
Sinon, je vais le convertir en InnoDB.