Dépannage de la mise à niveau sur place d’Aurora MySQL - Amazon Aurora

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Dépannage de la mise à niveau sur place d’Aurora MySQL

Suivez les conseils suivants pour résoudre les problèmes liés aux mises à niveau sur place d’Aurora MySQL. Ces conseils ne s’appliquent pas aux clusters de bases de données Aurora Serverless.

Pourquoi la mise à niveau sur place s’est arrêtée ou est lente Effet Solution permettant à la mise à niveau sur place de se terminer dans la fenêtre de maintenance
Le réplica entre régions d’Aurora associé n’a pas encore reçu les correctifs requis Aurora annule la mise à niveau. Mettez à niveau le réplica entre régions d’Aurora et réessayez.
Le cluster a des transactions XA à l’état préparé. Aurora annule la mise à niveau. Validez ou restaurez toutes les transactions XA préparées.
Le cluster traite toutes les instructions en langage de définition de données (DDL). Aurora annule la mise à niveau. Pensez à attendre et à effectuer la mise à niveau une fois toutes les instructions DDL terminées.
Le cluster a des modifications non validées pour de nombreuses lignes. La mise à niveau pourrait prendre beaucoup de temps.

Le processus de mise à niveau restaure les modifications non validées. L’indicateur de cette condition est la valeur de TRX_ROWS_MODIFIED dans la table INFORMATION_SCHEMA.INNODB_TRX.

Prévoyez d’effectuer la mise à niveau uniquement lorsque toutes les transactions volumineuses ont été validées ou restaurées.
Le cluster a un nombre élevé d’enregistrements d’annulation. La mise à niveau pourrait prendre beaucoup de temps.

Même si les transactions non validées affectent peu de lignes, elles peuvent impliquer un grand volume de données. Par exemple, si vous insérez des objets BLOB volumineux, Aurora ne détecte ni ne génère automatiquement d’événement pour ce type d’activité de transaction. L’indicateur de cette condition est la longueur de la liste d’historique (HLL). Le processus de mise à niveau restaure les modifications non validées.

Vous pouvez vérifier la liste HLL dans la sortie de la commande SQL SHOW ENGINE INNODB STATUS ou directement à l’aide de la requête SQL suivante :

SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

Vous pouvez également utiliser la métrique RollbackSegmentHistoryListLength dans Amazon CloudWatch.

Prévoyez d’effectuer la mise à niveau uniquement une fois que la longueur de la liste HLL sera plus petite.
Le cluster est en train de valider une transaction de journal binaire volumineuse La mise à niveau pourrait prendre beaucoup de temps.

Le processus de mise à niveau attend que les modifications de journaux binaires soient appliquées. Plus de transactions ou d’instructions DDL pourraient commencer pendant cette période, ce qui ralentirait encore le processus de mise à niveau.

Planifiez le processus de mise à niveau lorsque le cluster n’est pas occupé à générer des modifications de réplication de journaux binaires. Aurora ne détecte ni ne génère automatiquement d’événement pour cette condition.
Incohérences de schéma résultant de la suppression ou de l’endommagement de fichiers Aurora annule la mise à niveau.

Changez le moteur de stockage par défaut pour les tables temporaires de MyISAM à InnoDB. Procédez comme suit :

  1. Modifiez le paramètre de base de données default_tmp_storage_engine en spécifiant InnoDB.

  2. Redémarrez le cluster de bases de données.

  3. Après le redémarrage, confirmez que le paramètre de base de données default_tmp_storage_engine est défini sur InnoDB. Utilisez la commande suivante :

    show global variables like 'default_tmp_storage_engine';

  4. Veillez à ne pas créer de tables temporaires utilisant le moteur de stockage MyISAM. Nous vous recommandons de suspendre toute charge de travail de base de données et de ne pas créer de nouvelles connexions de base de données, car vous allez bientôt effectuer une mise à niveau.

  5. Réessayez la mise à niveau sur place.
L’utilisateur principal a été supprimé Aurora annule la mise à niveau.
Important

Ne supprimez pas l’utilisateur principal.

Toutefois, si, pour une raison ou une autre, vous venez à supprimer l’utilisateur principal, restaurez-le à l’aide des commandes SQL suivantes :

CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, 
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, 
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;

Pour plus de détails sur la résolution des problèmes à l’origine de l’échec des vérifications préalables de la mise à niveau, consultez les blogs suivants :

Vous pouvez suivre les étapes suivantes afin d’effectuer vos propres vérifications pour certaines des conditions du tableau précédent. Ainsi, vous pouvez planifier la mise à niveau à un moment où vous savez que la base de données sera dans un état permettant une mise à niveau rapide.

  • Vous pouvez vérifier les transactions XA ouvertes en exécutant l’instruction XA RECOVER. Vous pouvez ensuite valider ou restaurer les transactions XA avant de lancer la mise à niveau.

  • Vous pouvez vérifier les instructions DDL en exécutant une instruction SHOW PROCESSLIST et en recherchant les instructions CREATEDROP, ALTER, RENAME et TRUNCATE dans la sortie. Laissez toutes les instructions DDL se terminer avant de commencer la mise à niveau.

  • Vous pouvez vérifier le nombre total de lignes non validées en interrogeant la table INFORMATION_SCHEMA.INNODB_TRX. La table contient une ligne pour chaque transaction. La colonne TRX_ROWS_MODIFIED contient le nombre de lignes modifiées ou insérées par la transaction.

  • Vous pouvez vérifier la longueur de la liste d’historique InnoDB en exécutant l’instruction SHOW ENGINE INNODB STATUS SQL et en recherchant la valeur History list length dans la sortie. Vous pouvez également vérifier la valeur directement en exécutant la requête suivante : 

    SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

    La longueur de la liste d’historique correspond à la quantité d’informations d’annulation stockées par la base de données pour implémenter le contrôle de concurrence multi-version (MVCC).