web-dev-qa-db-fra.com

Quelle est la cause des erreurs en attente de verrouillage au niveau de la table?

Nous avons déjà suspendu la base de données deux fois et essayons de trouver une cause.

show processlist
Waiting for global read lock | INSERT INTO {myisam_table} ...

Ici, l'espace disque était plein, donc nous pensions que le problème était résolu après en avoir donné un peu plus, mais le lendemain à midi, il a de nouveau pendu:

show processlist
Waiting for table level lock | UPDATE {myisam_table} ... 

Qu'est-ce qui pourrait en être la cause?

Moteur par défaut de Mysql: InnoDB.

La base de données a un mélange de tables avec les moteurs MyISAM et InnoDB.

Journal affiché ici:

http://arturito.net/2013/08/28/mysql-waiting-for-table-level-lock-errors/

8
Artur Kędzior

OBSERVATIONS INITIALES

  • L'ID de processus 42686 indique qu'il se prépare à exécuter une requête SELECT
  • Il y a des connexions de sommeil
  • Tous les autres processus ne peuvent pas acquérir un verrou de table
  • Je m'attendais à ce qu'une MISE À JOUR, SUPPRIMER ou INSÉRER fasse le verrouillage. Il n'y a aucune revendication de propriété de la table en question.
  • Impossible de voir la requête complète dans l'ID de processus 42686, mais je pense que cela implique un JOIN, GROUP BY, ou ORDER BY

THÉORIE DE TRAVAIL

Si vous n'avez plus d'espace disque avec la liste de processus que vous m'avez donnée, nous pouvons blâmer le moteur de stockage MyISAM. Pourquoi?

Dans votre cas particulier, ce n'est pas une de vos tables. Si un JOIN, GROUP BY, ou ORDER BY était en cours d'exécution et une table temporaire était en cours d'écriture sur le disque (sur les tables temporaires du disque, utilisez le moteur de stockage MyISAM), MySQL se bloque simplement lorsqu'il manque d'espace. Comment le sais-je?

Selon ( Guide d'étude de certification MySQL 5.0

enter image description here Page 408 409 La section 29.2 Bulletpoint 11 dit:

Si vous manquez d'espace disque lors de l'ajout de lignes à une table MyISAM, aucune erreur ne se produit. Le serveur suspend l'opération jusqu'à ce que de l'espace soit disponible, puis termine l'opération.

J'ai déjà discuté de cette situation

Quelque chose me dit que vous avez l'une de ces deux situations

  • tables temporaires basées sur disque pour vos SELECT et en concurrence pour l'espace avec vos données régulières
  • Si la table temporaire atterrit dans /tmp dans la partition racine, c'est à court d'espace

SUGGESTIONS

Suggestion # 1: mapper tmpdir vers un autre disque

[mysqld]
tmpdir = /another/disk/besides/root/partition

Suggestion n ° 2: créer un disque RAM

Exécutez ce code pour installer un disque RAM qui sera disponible au redémarrage de Linux.

RAMDISK_SIZE=32g
service mysql stop
mkdir /var/tmpfs
echo "none   /var/tmpfs  tmpfs  defaults,size=${RAMDISK_SIZE} 1 2" >> /etc/fstab
mount -t tmpfs -o size=${RAMDISK_SIZE} none /var/tmpfs
cp -R /var/lib/mysql/* /var/tmpfs
mv /var/lib/mysql /var/lib/mysql_old
ln -s /var/tmpfs /var/lib/mysql
chown -R mysql:mysql /var/tmpfs
chown -R mysql:mysql /var/lib/mysql
service mysql start

Ensuite, mappez tmpdir à /var/tmpfs

ESSAIE !!!

8
RolandoMySQLDBA