Comment débuter les timeouts d'attente de locking avec MySQL / Amazon RDS?

Nous avons une application Web hébergée sur les services Web Amazon. Notre database est un server multi-az RDS MySQL exécutant 5.1.57 et 3-4 servers d'applications en parler.

Aujourd'hui, nous avons commencé à voir beaucoup d'erreurs dans le sens du timeout d'attente de locking dépassé; essayez de redémarrer la transaction – presque 1% des requests POST le voient.

Il n'y a eu aucune modification du code en cours d'exécution sur le site. Il n'y a eu aucun changement de schéma. Nous n'avons pas eu un gros essor dans la circulation. J'ai examiné les process en cours d'exécution, et aucun semble hors de contrôle.

J'ai essayé de mettre à l'échelle notre instance RDS d'un petit à un grand, sans effet.

Il y a deux jours, Amazon avait des pannes. Dans le cadre de la reprise, notre server RDS et nos servers d'applications ont fini dans différentes zones de disponibilité, mais dans la même région. Mais hier, tout va bien, donc je ne suis pas convaincu que cela soit lié.

Les timeouts de locking sont dans différents types de requêtes et se produisent dans différentes tables InnoDB.

J'ai remarqué que le nombre de connections ouvertes a sauté lorsque nous avons commencé à voir des problèmes, mais ils peuvent être un symptôme et non une cause.

Quelles sont mes prochaines étapes pour le debugging?

Graphique de connexion

Ce qui s'est probablement produit était une perte d'IO sur un ou plusieurs des volumes EBS prenant en charge l'instance RDS. La quantité d'IO réduite due à un remixage EBS est assez significative dans son effet sur les bases de données.

Si vous payez pour le support Premium, cette équipe peut se pencher sur les détails délicats comme ça pour vous ou vous pouvez essayer de poser des questions sur les forums AWS. Les ingénieurs RDS pourraient probablement confirmer les problèmes EBS sous-jacents ou quelle était la cause.