Pourquoi mon instance de base de données Amazon RDS for MySQL est-elle bloquée à l'état « Redémarrage » ?

Brève description

Avant d'effectuer un redémarrage, veillez à arrêter toutes les transactions entrantes ou en cours dans votre instance de base de données. Les transactions en cours seront arrêtées et toutes les transactions non validées seront annulées.

Remarque : l'annulation de transactions non validées peut être une opération coûteuse. Les transactions non validées peuvent également prendre beaucoup de temps avant que votre instance Amazon RDS for MySQL ne soit de nouveau disponible.

Une fois le redémarrage commencé, le processus ne peut pas être annulé ; le redémarrage se poursuivra jusqu'à ce qu'il soit terminé. Si votre redémarrage prend plus de temps que prévu, examinez-en la cause racine et envisagez les approches de dépannage suivantes :

• Vérifiez les requêtes en cours.
• Vérifiez s'il y a des transactions non purgées.
• Consultez le fichier journal des erreurs MySQL.

Résolution

Vérifier les requêtes en cours

Utilisez la commande SHOW FULL PROCESSLIST pour vérifier si des requêtes sont actives sur votre instance Amazon RDS for MySQL :

mysql> SHOW FULL PROCESSLIST;

Voici un exemple de sortie qui indique qu'une requête UPDATE est toujours en cours :

+-----+---------------+---------------------+------+---------+------+----------+-----------------------+
| Id  | User          | Host                | db   | Command | Time | State    | Info                  |
+-----+---------------+---------------------+------+---------+------+----------+-----------------------+
|   2 | rdsadmin      | localhost:30662     | NULL | Sleep   |    4 |          | NULL                  |
| 101 | admin         | 172.31.28.252:58288 | NULL | Query   |  111 | updating |UPDATE tutorials SET tu|
+-----+---------------+---------------------+------+---------+------+----------+-----------------------+

La sortie fournit des informations sur vos threads MySQL exécutés sur votre base de données. Si des requêtes sont toujours en cours d'exécution, autorisez-les à se terminer avant d'effectuer un redémarrage.

Remarque : exécutez la requête SHOW FULL PROCESSLIST en tant qu'utilisateur principal. Si vous n'êtes pas l'utilisateur principal, vous devez disposer des privilèges d'administration du serveur MySQL pour afficher tous les threads actifs sur l'instance MySQL. Sinon, la sortie affiche uniquement les ID de threads actifs dans le compte MySQL de l'utilisateur. Pour plus d'informations, consultez Instruction SHOW PROCESSLIST et Administration du serveur MySQL sur le site web MySQL.

Vérifier s'il y a des transactions non purgées

Le moteur MySQL InnoDB utilise le contrôle de simultanéité multiversion (MVCC), qui maintient une liste des anciennes versions des lignes modifiées au cours d'une transaction. Si une transaction doit être annulée, InnoDB peut effectuer toutes les opérations d'annulation au cours de ce processus. Les anciennes versions des lignes sont capturées dans l'espace d'annulation. Ces anciennes versions sont purgées lorsqu'elles ne sont plus appelées au cours d'une transaction. Si les modifications capturées ne sont pas purgées parce qu'une transaction y fait toujours référence, la longueur de la liste d'historique peut augmenter. Pour plus d'informations, consultez la section Gestion de plusieurs versions InnoDB sur le site web MySQL.

Les transactions non purgées sont représentées par la valeur de longueur de la liste de l'historique. Cette valeur se trouve sous « TRANSACTIONS » dans la sortie de la commande SHOW ENGINE INNODB STATUS. Notez que la longueur de la liste d'historique est généralement de faible, bien qu'une application gourmande en écriture ou des transactions de longue durée puissent entraîner une augmentation de cette valeur. Pour plus d'informations sur la valeur de longueur de la liste d'historique, voir Configuration de la purge sur le site web MySQL.

Pour vérifier la présence de transactions non purgées dans la longueur de la liste d'historique, utilisez la commande SHOW ENGINE INNODB STATUS. La sortie de cette commande vous permet également de visualiser la taille de la longueur de la liste d'historique et la taille de toutes les transactions en cours répertoriées dans la section « TRANSACTIONS ». Pour plus d'informations sur l'examen des transactions répertoriées, consultez Sortie du moniteur standard et du moniteur de verrouillage InnoDB sur le site web MySQL.

Par exemple :

------------
TRANSACTIONS
------------
Trx id counter 105746959
Purge done for trx's n:o < 105746958 undo n:o < 0 state: running but idle
History list length 32
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 328605240396520, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 328605240395600, not started
0 lock struct(s), heap size 1136, 0 row lock(s)

Remarque : si la longueur de la liste d'historique est élevée et qu'il y a des transactions actives, il n'est pas recommandé de procéder au redémarrage.

Pour plus d'informations, consultez SHOW ENGINE INNODB STATUS sur le site web MySQL.

Consulter le fichier journal des erreurs MySQL

Dans Amazon RDS, le fichier journal des erreurs MySQL est activé par défaut. Si vous pensez que votre instance RDS prend trop de temps pour être à nouveau disponible, consultez le contenu de votre fichier journal des erreurs MySQL. MySQL écrit dans le fichier journal des erreurs lorsque le service démarre, s'arrête ou rencontre des erreurs.

Par exemple, InnoDB peut devoir annuler toutes les transactions non validées dans le cadre du processus de récupération après incident d'InnoDB. Si des transactions non validées sont annulées, le journal des erreurs MySQL documente cet événement. Pour plus d'informations, consultez Récupération après incident d'InnoDB sur le site web de MySQL.

Dépannage supplémentaire

Remarque : si vous choisissez d'effectuer une restauration à un instant dans le passé (PITR) ou d'effectuer une restauration à partir d'un instantané, votre nouvelle instance Amazon RDS peut ne pas être immédiatement disponible. Pour plus d'informations, consultez les articles suivants :

• Pourquoi la restauration à un instant dans le passé de mon instance Amazon RDS for MySQL prend-elle beaucoup de temps ?
• Pourquoi la restauration d'un instantané de mon instance de base de données Amazon RDS for MySQL prend-elle autant de temps ?

Si votre instance de base de données Amazon RDS for MySQL redémarre pendant un certain temps, essayez ces conseils de dépannage supplémentaires :

• Si les sauvegardes automatisées sont activées sur votre instance de base de données, effectuez une PITR pour effectuer la restauration vers une nouvelle instance Amazon RDS à partir d'une heure spécifiée. Vous pouvez effectuer une restauration à n'importe quel instant de votre période de rétention des sauvegardes.
  Remarque : par défaut, les instances de bases de données restaurées sont associées au paramètre de base de données par défaut et aux groupes d'options. Toutefois, vous pouvez utiliser un groupe de paramètres et un groupe d'options personnalisés en les spécifiant au cours d'une restauration.
• Restaurez votre instance de base de données à partir de l'instantané de base de données le plus récent en créant une nouvelle instance de base de données. Vous pouvez utiliser l'instance de base de données restaurée dès que son état est disponible.
• Si votre instance de bases de données possède un réplica en lecture, promouvez le réplica en lecture pour qu'il devienne une instance de base de données autonome. Lorsque vous promouvez un réplica en lecture, l'instance de base de données est automatiquement redémarrée avant de devenir disponible.

Il est également recommandé de surveiller régulièrement l'activité de votre base de données. Vous pouvez surveiller votre instance de base de données Amazon RDS for MySQL à l'aide des outils ci-dessous.

• Amazon CloudWatch : avec Amazon CloudWatch, vous pouvez surveiller toute application de base de données en cours. Si vous observez des valeurs élevées dans les connexions de base de données, l'utilisation du processeur ou les IOPS en lecture/écriture, il se peut qu'il y ait une activité en cours dans votre instance de base de données.
• Surveillance améliorée : la surveillance améliorée nécessite l'autorisation d'envoyer des métriques du système d'exploitation à CloudWatch Logs. Vous pouvez accorder des autorisations de surveillance améliorée à l'aide d'un rôle AWS Identity and Access Management (IAM). Avant d'activer la surveillance améliorée, vous devez d'abord créer un rôle IAM.
• Performance Insights : Performance Schema est un outil de performances facultatif utilisé par Amazon RDS for MySQL (ou MariaDB). Si vous activez ou désactivez Performance Insights, vous n'avez pas besoin de redémarrer votre instance de base de données. Vous ne subissez pas non plus de basculement ni de temps d'arrêt.

---