L'esclave MySQL bloqué la plupart du temps sur le «verrouillage du système», utilisation élevée du processeur

Question

Permettez-moi de décrire à quoi nous sommes confrontés actuellement:

Nous avons une configuration MySQL Master-Slave, réplication basée sur les lignes et pour le moment, l'esclave est bloqué avec un System Lock. Le maître est un serveur actif avec de nombreux updates et deletes en cours d'exécution, mais l'esclave ne répliquera tout simplement rien. Il n'y a aucune erreur dans le journal et l'esclave lit très bien les journaux binaires du maître, mais il ne fait rien sur l'esclave. Le Seconds_Behind_Master la valeur continue d'augmenter. C'est quoi show processlist sur les émissions d'esclaves:

mysql> show processlist ; +----+-------------+-----------+------+---------+-------+----------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-------------+-----------+------+---------+-------+----------------------------------+------------------+ | 10 | system user | | NULL | Connect | 4985 | Waiting for master to send event | NULL | | 11 | system user | | NULL | Connect | 53715 | System lock | NULL | | 14 | root | localhost | NULL | Sleep | 2958 | | NULL | | 16 | root | localhost | NULL | Query | 0 | init | show processlist | +----+-------------+-----------+------+---------+-------+----------------------------------+------------------+ 4 rows in set (0.00 sec)

Et show slave status montre:

SQL_Remaining_Delay: NULL Slave_SQL_Running_State: System lock

Le seul signe de vie est que Relay_Log_Pos du statut esclave change des valeurs mais très lentement. Cela signifie-t-il qu'il exécute les requêtes à partir du journal binaire, mais simplement qu'il est trop lent?

Coller des informations de show engine innodb status:

LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 0, not started MySQL thread id 14, OS thread handle 0x7f7824698700, query id 216193 localhost root init show engine innodb status ---TRANSACTION 230426904, not started mysql tables in use 1638, locked 1638 MySQL thread id 11, OS thread handle 0x7f7824920700, query id 216192 System lock -------- FILE I/O -------- I/O thread 0 state: waiting for completed aio requests (insert buffer thread) I/O thread 1 state: waiting for completed aio requests (log thread) I/O thread 2 state: waiting for completed aio requests (read thread) I/O thread 3 state: waiting for completed aio requests (read thread) I/O thread 4 state: waiting for completed aio requests (read thread)

A également remarqué que le processus mysqld pour cette instance mysql particulière a une utilisation élevée du processeur. Quelle pourrait être la cause du Slave_SQL_Running_State: System lock et empêcher l'esclave d'exécuter les requêtes? Il n'y a pas de problème de disque avec la machine et une autre instance MySQL en cours d'exécution est esclave d'une autre instance MySQL (myisam) sur le même maître et fonctionne correctement.

Version MySQL: 5.6.20. OS: RHEL 6.5 Nous avons des tables qui sont partitionnées (si cela importe).

Edit: Je viens de remarquer que Slave_SQL_Running_State est parfois remplacé par "Lecture de l'événement à partir du journal de relais". Il semble donc que la réplication soit trop lente.

Ankit Kapoor · Answer

nous devons d'abord comprendre, il n'y a pas de solution spécifique pour cela.

Donc, selon les informations fournies dans Question, à quoi bon:

Vous avez mentionné que la position du journal de relais est en constante évolution, ce qui signifie que le "thread SQL" fonctionne.
Vous avez mentionné que Slave_SQL_Running_State reçoit également des modifications, ce qui signifie que le thread d'E/S fonctionne également.

Ce qui est mauvais, c'est que "l'espace journal des relais augmente", ce qui signifie que les données arrivent mais prennent du temps à s'exécuter.

Permet de s'attarder davantage ici:

Observez-vous également la lenteur dans le Maître? Toute requête lente dans le maître? Si la réponse est non, continuez vers 2
La configuration des deux serveurs est-elle la même? En cela, vous devez vérifier la configuration du pool de tampons mysql et la méthode d'isolement. J'ai personnellement expérimenté que le niveau d'isolement peut également être coupable (lecture répétable qui est par défaut dans MySQL).
Avez-vous vérifié quelle requête est en cours d'exécution au moment où vous avez observé une lenteur. Faites juste, pager grep Query suivi de show processlist;

Cela vous donnera une idée de ce qui se coince. Permet d'aller plus à l'intérieur, de vérifier la position du journal de relais et de vérifier dans le journal de relais quelle est la requête et d'essayer de l'optimiser. Mais avant cela, assurez-vous qu'il fonctionne vraiment lentement.

Vous pouvez utiliser la base de données du schéma de performances et dans cette base de données, il suffit d'activer l'instrument pour SQL, IO, la réplication et de prendre l'aide de ce lien: https://dev.mysql.com/doc/refman/5.7/en/performance -schema-replication-tables.html

En dehors de cela, vous pouvez également utiliser le schéma SYS pour diagnostiquer ce qui ne va pas.

Ce que Rolando a dit en est une des causes et il a raison. Le chargement du fichier peut généralement provoquer ce problème.

Faites-moi savoir si j'ai du sens :)

RolandoMySQLDBA · Answer

J'avais répondu à une question en janvier 2013 concernant l'état du thread "System Lock": Que signifie 'system lock' dans le profilage mysql d'une instruction LOAD DATA INFILE?

Voici ce qui pourrait arriver, veuillez suivre

Dans mon ancien poste , j'ai évoqué ce qui suit

Le thread va demander ou attend un verrou système interne ou externe pour la table. Si cet état est provoqué par des demandes de verrous externes et que vous n'utilisez pas plusieurs serveurs mysqld qui accèdent aux mêmes tables MyISAM, vous pouvez désactiver les verrous système externes avec l'option --skip-external-verrouillage. Cependant, le verrouillage externe est désactivé par défaut, il est donc probable que cette option n'aura aucun effet. Pour SHOW PROFILE, cet état signifie que le thread demande le verrouillage (sans l'attendre).

Étant donné que cela se produit sur le thread SQL, cela signifie qu'il existe une requête qui doit verrouiller une table ou une ligne dans une table. Le verrou n'étant pas encore acquis, la requête ne serait pas visible dans le champ INFO du thread SQL dans SHOW PROCESSLIST;. La prochaine question logique serait: "Comment pouvez-vous voir la requête ou au moins le verrou?"

Lorsque vous avez exécuté SHOW ENGINE INNODB STATUS\G, vous avez vu la serrure. Cependant, vous n'avez pas vu la table qu'elle bloquait. Basé sur mon ancien poste , je soupçonnerais un LOAD DATA INFILE ayant été exécuté sur le maître puis répliqué sur l'esclave. Pourquoi aurait-il besoin de verrouiller la table sur l'esclave?

Cela a beaucoup à voir avec la façon dont MySQL réplique un LOAD DATA INFILE. Non seulement la commande est répliquée via les journaux binaires, mais également l'ensemble du fichier de données. J'ai un vieux post où j'ai décrit exactement comment MySQL le fait.

Depuis un LOAD DATA INFILE est en train de descendre, je peux imaginer une demande pour verrouiller une table, matérialiser un fichier CSV à partir des journaux de relais et exécuter LOAD DATA INFILE. Pendant tout le cycle, rien sous le spectacle Sun n'essaie d'accéder à la table cible. Ainsi, le System Lock doit arriver.

À la lumière de cela, il est logique que le journal ne contienne aucune erreur, l'esclave lit les journaux binaires du maître, ne fait rien sur l'esclave et le Seconds_Behind_Master la valeur ne cesse d'augmenter.

MISE À JOUR 2014-10-24 12:55 EST

Vous avez mentionné les tables partitionnées. Vous devez vérifier le nombre de descripteurs de fichiers ouverts. Vérifiez les variables d'état globales open_files et Innodb_num_open_files . Si ceux-ci augmentent pendant le verrouillage du système, la table doit alors subir un verrouillage. Les descripteurs de fichiers sur toutes les partitions doivent être ouverts, verrouillés et éventuellement mis en cache.