Résolution des problèmes liés à la mise à niveau SQL sur place d'Aurora My - 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.

Résolution des problèmes liés à la mise à niveau SQL sur place d'Aurora My

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

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
La réplique interrégionale Aurora associée n'est pas encore corrigée Aurora annule la mise à niveau. Mettez à niveau la réplique interrégionale 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 du langage de définition des données (DDL) Aurora annule la mise à niveau. Pensez à attendre et à effectuer la mise à niveau une fois toutes les DDL instructions 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, il se peut que vous insériez une taille importanteBLOBs. 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 HLL le résultat de la SHOW ENGINE INNODB STATUS SQL commande ou directement à l'aide de la SQL requête suivante :

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

Vous pouvez également surveiller la RollbackSegmentHistoryListLength métrique sur Amazon CloudWatch.

Envisagez d'effectuer la mise à niveau uniquement une fois que la HLL valeur est 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. D'autres transactions ou DDL relevés pourraient commencer au cours de cette période, ce qui ralentirait davantage 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.

Modifiez le moteur de stockage par défaut pour les tables temporaires de My ISAM à 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. Assurez-vous de ne pas créer de tables temporaires utilisant le moteur My ISAM storage. 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 deviez supprimer l'utilisateur principal, restaurez-le à l'aide des SQL commandes 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 prévérifications de 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 la présence d'DDLinstructions en exécutant une SHOW PROCESSLIST instruction et en recherchant les TRUNCATE instructions CREATE DROP ALTERRENAME,,, et dans la sortie. Laissez toutes les DDL instructions 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 simultanéité multiversion ()MVCC.