Dépannage d'Amazon RDS - Amazon Relational Database Service
Impossible de se connecter à l'instance de base de données Problèmes de sécuritéRésolution des problèmes liés à l'état de réseau incompatibleRéinitialisation du mot de passe du propriétaire de l'instance de base de donnéesPanne ou redémarrage d'une instance de base de donnéesModifications de paramètre n'entrant pas en vigueurInstance de base de données à court de stockageCapacité d'instance de base de données insuffisanteProblèmes liés à la mémoire libérable dans RDSProblèmes MySQL et MariaDBImpossible de définir la période de rétention des sauvegardes sur 0

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 d'Amazon RDS

Utilisez les sections suivantes pour résoudre les problèmes que vous rencontrez avec les instances de base de données dans Amazon RDS et Amazon Aurora.

Pour de plus amples informations sur le débogage des problèmes à l'aide de l'API Amazon RDS, veuillez consulter Applications de dépannage sur Amazon RDS.

Impossible de se connecter à l'instance de base de données Amazon RDS

Voici des causes courantes empêchant la connexion à une instance de base de données :

  • Règles entrantes – Les règles d'accès appliquées par votre pare-feu local et les adresses IP autorisées à accéder à votre instance de base de données peuvent ne pas correspondre. Le problème est probablement lié aux règles entrantes de votre groupe de sécurité.

    Par défaut, les instances de base de données n'autorisent pas l'accès. L'accès est accordé via un groupe de sécurité associé au VPC qui autorise le trafic entrant et sortant de l'instance de base de données. Si nécessaire, ajoutez au groupe de sécurité des règles entrantes et sortantes pour votre situation. Vous pouvez indiquer une adresse IP, une plage d'adresses IP ou un autre groupe de sécurité VPC.

    Note

    Lorsque vous ajoutez une nouvelle règle entrante, vous pouvez choisir Mon adresse IP pour Source afin d'autoriser l'accès à l'instance de base de données à partir de l'adresse IP détectée dans votre navigateur.

    Pour de plus amples informations sur la configuration des groupes de sécurité, veuillez consulter Créer un groupe de sécurité qui autorise l'accès à votre instance de base de données dans votre VPC.

    Note

    Les connexions client à partir d'adresses IP dans la plage 169.254.0.0/16 ne sont pas autorisées. Il s'agit d'une plage d'adresses IP privées automatiques (APIPA, Automatic Private IP Addressing Range), qui est utilisée pour l'adressage de liens locaux.

  • Accessibilité publique – Pour vous connecter à votre instance de base de données depuis l'extérieur du VPC, par exemple en utilisant une application cliente, une adresse IP publique doit lui être attribuée.

    Pour rendre l'instance accessible au public, modifiez-la et choisissez Oui sous Public accessibility (Accessibilité publique). Pour plus d'informations, consultez Masquer un(e) instance de base de données dans un VPC depuis Internet.

  • Port – Le port que vous avez spécifié quand vous avez créé l'instance de base de données ne peut pas être utilisé pour envoyer ou recevoir des communications en raison des restrictions de votre pare-feu local. Pour déterminer si votre réseau autorise l'utilisation du port spécifié pour les communications entrantes et sortantes, vérifiez auprès de votre administrateur réseau.

  • Disponibilité – Pour une instance de base de données récemment créée, celle-ci a un état creating (création) jusqu'à ce qu'elle soit prête à l'emploi. Lorsque l'état devient available (disponible), vous pouvez vous connecter à l'instance de base de données. Selon la taille de votre instance de base de données, vous devez parfois patienter une vingtaine de minutes avant qu'elle ne soit disponible.

  • Passerelle Internet – Pour qu'une instance de base de données soit publiquement accessible, les sous-réseaux de son groupe de sous-réseaux de base de données doivent avoir une passerelle Internet.

    Pour configurer une passerelle Internet pour un sous-réseau

    1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

    2. Dans le panneau de navigation, sélectionnez Bases de données, puis sélectionnez le nom de l'instance de base de données.

    3. Dans l'onglet Connectivity & security (Connectivité et sécurité), notez les valeurs de l'ID du VPC sous VPC et de l'ID du sous-réseau sous Sous-réseaux (subnets).

    4. Ouvrez la console Amazon VPC à l'adresse https://console.aws.amazon.com/vpc/.

    5. Dans le panneau de navigation, choisissez Passerelles Internet. Vérifiez qu'il existe une passerelle Internet attachée à votre VPC. Sinon, choisissez Créer une passerelle Internet pour créer une passerelle Internet. Sélectionnez la passerelle Internet, puis choisissez Attacher au VPC et suivez les instructions pour l'attacher à votre VPC.

    6. Dans le panneau de navigation, sélectionnez Sous-réseaux, puis sélectionnez votre sous-réseau.

    7. Dans l'onglet Table de routage, vérifiez qu'il existe une route avec 0.0.0.0/0 comme destination et la passerelle Internet pour votre VPC comme cible.

      Si vous vous connectez à votre instance à l'aide de son adresse IPv6, vérifiez qu'il existe une route pour tout le trafic IPv6 (::/0) qui pointe vers la passerelle Internet. Sinon, procédez comme suit :

      1. Choisissez l'ID de la table de routage (rtb-xxxxxxxx) pour accéder à cette dernière.

      2. Dans l'onglet Routes, choisissez Edit routes (Modifier les routes). Choisissez Add route (Ajouter une route) et utilisez 0.0.0.0/0 comme destination et la passerelle Internet comme cible.

        Pour IPv6, choisissez Add route (Ajouter une route) et utilisez ::/0 comme destination et la passerelle Internet comme cible.

      3. Choisissez Save routes (Enregistrer les routes).

      En outre, si vous essayez de vous connecter à un point de terminaison IPv6, assurez-vous que la plage d'adresses IPv6 du client est autorisée à se connecter à l'instance de base de données.

    Pour plus d’informations, consultez Utilisation d'un(e) instance de base de données dans un VPC.

Pour les problèmes de connexion spécifiques au moteur, consultez les rubriques suivantes :

Test d'une connexion à une instance de base de données

Vous pouvez tester votre connexion à une instance de base de données à l'aide des outils courants Linux ou Microsoft Windows.

Depuis un terminal Linux ou Unix, vous pouvez tester la connexion en saisissant les informations suivantes. Remplacez DB-instance-endpoint par le point de terminaison et port par le port de votre instance de base de données.

nc -zv DB-instance-endpoint port

Par exemple, le code suivant illustre un exemple de commande et la valeur renvoyée.

nc -zv postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299

  Connection to postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded!

Les utilisateurs Windows peuvent utiliser Telnet pour tester la connexion à une instance de base de données. Les actions Telnet ne sont prises en charge que pour le test de la connexion. Si l'opération aboutit, l'action ne retourne aucun message. Si une connexion n'aboutit pas, vous recevez un message d'erreur similaire au message suivant.

C:\>telnet sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com 819

  Connecting To sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com...Could not open
  connection to the host, on port 819: Connect failed

Si les actions Telnet aboutissent, votre groupe de sécurité est correctement configuré.

Note

Amazon RDS n'accepte pas le trafic ICMP (Internet Control Message Protocol), y compris ping.

Dépannage des problèmes d'authentification de connexion

Dans certains cas, vous pouvez vous connecter à votre instance de base de données, mais vous obtenez des erreurs d'authentification. Dans ce cas, il se peut que vous vouliez réinitialiser le mot de passe utilisateur maître de l'instance de base de données. Vous pouvez modifier l'instance RDS pour ce faire.

Pour de plus amples informations sur la modification d'une instance de base de données, veuillez consulter Modification d'une instance de base de données Amazon RDS.

Problèmes de sécurité Amazon RDS

Pour éviter les problèmes de sécurité, n'utilisez jamais votre nom AWS d'utilisateur principal et votre mot de passe pour un compte utilisateur. La meilleure pratique consiste à utiliser votre master Compte AWS pour créer des utilisateurs et les attribuer à des comptes utilisateur de base de données. Vous pouvez aussi utiliser votre compte maître pour créer d'autres comptes utilisateur si nécessaire.

Pour plus d'informations sur la création d'utilisateurs, consultez Création d'un utilisateur IAM dans votre Compte AWS. Pour plus d'informations sur la création d'utilisateurs dans AWS IAM Identity Center, voir Gérer les identités dans IAM Identity Center.

Message d'erreur « Échec de l'extraction des attributs du compte. Certaines fonctions de la console sont peut être dégradées. »

Plusieurs raisons peuvent expliquer cette erreur. Cela peut être dû au fait que votre compte ne dispose pas de certaines autorisations ou que votre compte n'a pas été correctement configuré. Si votre compte est nouveau, vous n'avez peut-être pas attendu qu'il soit prêt. S'il s'agit d'un compte existant, il est possible que vos stratégies d'accès ne contiennent pas certaines autorisations permettant d'exécuter certaines actions, comme la création d'une instance de base de données. Pour résoudre le problème, votre administrateur doit fournir les rôles nécessaires à votre compte. Pour de plus amples informations, veuillez consulter la documentation IAM.

Résolution des problèmes liés à l'état de réseau incompatible

L'état de réseau incompatible signifie que la base de données est peut-être toujours accessible au niveau de la base de données, mais que vous ne pouvez pas la modifier ni la redémarrer.

Causes

L'état de réseau incompatible de votre instance de base de données peut être le résultat de l'une des actions suivantes :

  • Modification de la classe d'instances de base de données.

  • Modification de l'instance de base de données pour utiliser un déploiement de cluster de bases de données multi-AZ.

  • Remplacement d'un hôte en raison d'un événement de maintenance.

  • Lancement d'une instance de base de données de remplacement.

  • Restauration à partir d'une sauvegarde d'instantané.

  • Démarrage d'une instance de base de données qui a été arrêtée.

Résolution

Utiliser start-db-instance la commande

Pour corriger une base de données figurant dans l'état de réseau incompatible, suivez ces instructions :

  1. Ouvrez https://console.aws.amazon.com/rds/ et choisissez Bases de données dans le volet de navigation.

  2. Choisissez l'instance de base de données figurant dans l'état de réseau incompatible et notez l'identifiant de l'instance de base de données, l'ID de VPC et les ID de sous-réseaux dans l'onglet Connectivité et sécurité.

  3. Utilisez le AWS CLI pour exécuter la start-db-instance commande. Spécifiez la valeur --db-instance-identifier.

    Note

    L'exécution de cette commande lorsque votre base de données est en mode d'incompatibilité peut entraîner des temps d'arrêt.

    La commande start-db-instance ne résout pas ce problème pour les instances de base de données RDS for SQL Server.

Le statut de votre base de données passe à Disponible si la commande s'exécute correctement.

Si votre base de données redémarre, l'instance de base de données peut exécuter la dernière opération exécutée sur l'instance avant son passage à l'état de réseau incompatible. Cela peut ramener l'instance à l'état de réseau incompatible.

Si la commande start-db-instance échoue ou que l'instance revient à l'état de réseau incompatible, ouvrez la page Bases de données dans la console RDS et sélectionnez la base de données. Accédez à la section Journaux et événements. La section Événements récents affiche les étapes de résolution supplémentaires à suivre. Les messages sont classés comme suit :

  • VÉRIFICATION DES RESSOURCES INTERNES : il se peut que des problèmes soient liés à vos ressources internes.

  • VÉRIFICATION DNS : vérifiez les noms d'hôte et la résolution DNS pour le VPC dans la console VPC.

  • VÉRIFICATION ENI : l'interface réseau Elastic (ENI) pour votre base de données n'existe peut-être pas.

  • VÉRIFICATION DE LA PASSERELLE : la passerelle Internet de votre base de données accessible au public n'est pas attachée au VPC.

  • VÉRIFICATION IP : il n'y a pas d'adresses IP libres dans vos sous-réseaux.

  • VÉRIFICATION DES GROUPES DE SÉCURITÉ : aucun groupe de sécurité n'est associé à votre base de données ou les groupes de sécurité sont non valides.

  • VÉRIFICATION DES SOUS-RÉSEAUX : il n'y a aucun sous-réseau valide dans votre groupe de sous-réseaux de base de données ou il y a des problèmes avec votre sous-réseau.

  • VÉRIFICATION DU VPC : le VPC associé à votre base de données est non valide.

Effectuer une point-in-time restauration

Il est recommandé de disposer d'une sauvegarde (instantanée ou logique) au cas où votre base de données passerait à l'état de réseau incompatible. veuillez consulter Présentation des sauvegardes. Si vous avez activé les sauvegardes automatiques, arrêtez temporairement toute écriture dans la base de données et effectuez une point-in-time restauration.

Note

Une fois qu'une instance est passée à l'état de réseau incompatible, il est possible que l'instance de base de données ne soit pas accessible pour effectuer une sauvegarde logique.

Si vous n'avez pas activé les sauvegardes automatiques, créez une nouvelle instance de base de données. Migrez ensuite les données à l'aide d'AWS Database Migration Service (AWS DMS) ou en utilisant un outil de sauvegarde et de restauration.

Si cela ne résout pas le problème, contactez AWS Support pour obtenir de l'aide supplémentaire.

Réinitialisation du mot de passe du propriétaire de l'instance de base de données

Si l'accès à votre instance de base de données est verrouillé, vous pouvez vous connecter en tant qu'utilisateur principal. Ensuite, vous pouvez réinitialiser les informations d'identification pour d'autres utilisateurs ou rôles administratifs. Si vous ne parvenez pas à vous connecter en tant qu'utilisateur principal, le propriétaire du AWS compte peut réinitialiser le mot de passe de l'utilisateur principal. Pour de plus amples informations sur les comptes ou rôles administratifs que vous devrez peut-être réinitialiser, veuillez consulter Privilèges du compte utilisateur principal.

Vous pouvez modifier le mot de passe de l'instance de base de données à l'aide de la console Amazon RDS, de la AWS CLI commande modify-db-instanceou de l'opération d'API ModifyDBInstance. Pour plus d'informations sur la modification d'une instance de base de données, veuillez consulter Modification d'une instance de base de données Amazon RDS.

Panne ou redémarrage d'une instance de base de donnéesAmazon RDS

Une instance de base de données peut connaître une panne au redémarrage. Cela peut également se produire quand l'instance de base de données est placée dans un état qui empêche d'y accéder ou quand la base de données est redémarrée. Un redémarrage peut se produire lorsque vous redémarrez manuellement votre instance de base de données. Un redémarrage peut également se produire quand vous modifiez un paramètre de l'instance de base de données qui nécessite un redémarrage avant que la modification ne puisse prendre effet.

Un redémarrage de l'instance de base de données se produit lorsque vous démarrez un paramètre qui nécessite un redémarrage ou quand vous provoquez manuellement un redémarrage. Un redémarrage peut se produire immédiatement si vous modifiez un paramètre et demandez que la modification prenne effet immédiatement. Cela peut également se produire pendant la fenêtre de maintenance de l'instance de base de données.

Un redémarrage d'instance de base de données se produit immédiatement quand l'une des conditions suivantes est vraie :

  • Vous remplacez la période de rétention des sauvegardes pour une instance de base de données de 0 par une valeur différente de zéro, ou d'une valeur différente de 0 par 0. Vous définissez ensuite Ajouter un rôle (Appliquer immédiatement) sur true.

  • Vous pouvez modifier la classe d'instance de base de données et Appliquer immédiatement est défini sur la valeur true (vrai).

  • Vous remplacez le type de stockage Magnetic (Standard) [Magnétique (Standard)] par General Purpose (SSD) [Usage général (SSD)]) ou Provisioned IOPS (SSD) [IOPS dimensionné (SSD)], ou le type Provisioned IOPS (SSD) [IOPS dimensionné (SSD)] ou General Purpose (SSD) [Usage général (SSD)] par Magnetic (Standard) [Magnétique (Standard)].

Un redémarrage d'instance de base de données se produit pendant la fenêtre de maintenance quand l'une des conditions suivantes est vraie :

  • Vous remplacez la période de rétention des sauvegardes pour une instance de base de données de 0 par une valeur différente de zéro, ou d'une valeur différente de zéro par zéro, et Appliquer immédiatement est défini sur la valeur false (faux).

  • Vous pouvez modifier la classe d'instance de base de données et Appliquer immédiatement est défini sur la valeur false (vrai).

Lorsque vous modifiez un paramètre statique d'un groupe de paramètres de base de données, la modification prend effet seulement après le redémarrage de l'instance de base de données associée au groupe de paramètres. La modification nécessite un redémarrage manuel. L'instance de base de données n'est pas redémarrée automatiquement pendant la fenêtre de maintenance.

Pour afficher un tableau qui illustre les actions d'une instance de base de données et l'effet de l'application de la valeur Apply Immediately (Appliquer immédiatement), consultez Modification d'une instance de base de données Amazon RDS.

Modifications de paramètre de base de données Amazon RDS n'entrant pas en vigueur

Dans certains cas, vous pouvez modifier un paramètre dans un groupe de paramètres de base de données, mais vous ne voyez pas que les modifications prennent effet. Vous devrez alors probablement redémarrer l'instance de base de données associée au groupe de paramètres de base de données. Lorsque vous modifiez un paramètre dynamique, la modification prend effet immédiatement. Lorsque vous modifiez un paramètre statique, la modification ne prend effet que lorsque vous redémarrez l'instance de base de données associée au groupe de paramètres.

Vous pouvez redémarrer une instance de base de données en utilisant la console RDS. Vous pouvez également appeler explicitement l'opération d'API RebootDBInstance. Vous pouvez redémarrer sans basculement si l'instance de base de données se trouve dans un déploiement multi-AZ. Les critères pour redémarrer l'instance de base de données associée après un changement de paramètre statique contribuent à atténuer le risque d'erreur de configuration d'un paramètre affectant un appel d'API. Par exemple, appeler ModifyDBInstance pour changer la classe de l'instance de base de données. Pour plus d’informations, consultez Modification de paramètres dans un groupe de paramètres de bases de données.

Manque d'espace de stockage de l'instance de base de données Amazon RDS

Si votre instance de base de données ne dispose plus d'un espace de stockage suffisant, il se peut qu'elle ne soit plus disponible. Nous vous recommandons vivement de surveiller en permanence la FreeStorageSpace métrique publiée dans CloudWatch pour vous assurer que votre instance de base de données dispose de suffisamment d'espace de stockage disponible.

Si votre instance de base de données ne dispose plus d'un stockage suffisant, son état devient storage-full. Par exemple, l'appel de l'opération d'API DescribeDBInstances pour une instance de base de données qui a consommé la totalité de son stockage produit l'effet suivant.

aws rds describe-db-instances --db-instance-identifier mydbinstance

DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
storage-full  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Pour vous remettre de ce scénario, ajoutez de l'espace de stockage à votre instance à l'aide de l'opération ModifyDBInstance API ou de la AWS CLI commande suivante.

Pour LinuxmacOS, ou Unix :

aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --allocated-storage 60 \
    --apply-immediately

Dans Windows :

aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --allocated-storage 60 ^
    --apply-immediately
DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
storage-full  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3  60
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Désormais, lorsque vous décrivez votre instance de base de données, vous constatez que son état est modifying (modification), ce qui signifie que le stockage est en cours de mise à l'échelle.

aws rds describe-db-instances --db-instance-identifier mydbinstance 
DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
modifying  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com
3306  us-east-1b  3  60
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Une fois la mise à l'échelle du stockage terminée, l'état de votre instance de base de données devient (disponible available.

aws rds describe-db-instances --db-instance-identifier mydbinstance 
DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  60  sa
available  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

L'opération DescribeEvents vous permet de recevoir des notifications lorsque vous n'avez plus d'espace de stockage disponible. Par exemple, dans ce scénario, si vous appelez DescribeEvents après ces opérations, vous observez le résultat suivant.

aws rds describe-events --source-type db-instance --source-identifier mydbinstance 
2009-12-22T23:44:14.374Z  mydbinstance  Allocated storage has been exhausted db-instance
2009-12-23T00:14:02.737Z  mydbinstance  Applying modification to allocated storage db-instance
2009-12-23T00:31:54.764Z  mydbinstance  Finished applying modification to allocated storage

Capacité d'instance de base de données insuffisante Amazon RDS

L'erreur InsufficientDBInstanceCapacity peut être renvoyée lorsque vous essayez de créer, de démarrer ou de modifier une instance de base de données. Elle peut également être renvoyée lorsque vous essayez de restaurer une instance de base de données à partir d'un instantané de base de données. Lorsque cette erreur est renvoyée, la cause la plus fréquente est que la classe d'instance de base de données spécifique n'est pas disponible dans la zone de disponibilité demandée. Vous pouvez essayer une des actions suivantes pour résoudre le problème :

  • Renouveler la demande avec une classe d'instance de base de données différente.

  • Renouveler la demande avec une zone de disponibilité différente.

  • Renouveler la demande sans spécifier de zone de disponibilité explicite.

Pour de plus amples informations sur le dépannage de problèmes de capacité d'instance pour Amazon EC2, veuillez consulter la section Insufficient instance capacity (Capacité d'instance insuffisante) dans le Guide de l'utilisateur Amazon EC2.

Pour savoir comment modifier une instance de base de données, consultez Modification d'une instance de base de données Amazon RDS.

Problèmes liés à la mémoire libérable dans Amazon RDS

La mémoire libérable est la quantité totale de mémoire vive (RAM) sur une instance de base de données qui peut être mise à la disposition du moteur de base de données. Il s'agit de la somme de la mémoire libre du système d'exploitation et des mémoires tampon/cache de page disponibles. Le moteur de base de données utilise la plus grande partie de la mémoire sur l'hôte, mais les processus du système d'exploitation utilisent également une partie de la mémoire vive. La mémoire actuellement allouée au moteur de base de données ou utilisée par les processus du système d'exploitation n'est pas incluse dans la mémoire libérable. Lorsque le moteur de base de données manque de mémoire, l'instance de base de données peut utiliser l'espace temporaire normalement utilisé pour la mise en mémoire tampon et la mise en cache. Comme mentionné précédemment, cet espace temporaire est inclus dans la mémoire libérable.

Vous utilisez la FreeableMemory métrique dans Amazon CloudWatch pour surveiller la mémoire disponible. Pour plus d’informations, consultez Présentation de la surveillance des métriques dans Amazon RDS.

Si votre instance de base de données manque constamment de mémoire libérable ou utilise l'espace d'échange, envisagez d'augmenter la taille de la classe d'instance de base de données. Pour plus d’informations, consultez Classes d'instances de base de données .

Vous pouvez également modifier les paramètres de mémoire. Par exemple, sur RDS for MySQL, vous pouvez ajuster la taille du paramètre innodb_buffer_pool_size. Ce paramètre est défini par défaut sur 75 % de la mémoire physique. Pour obtenir des conseils de dépannage de MySQL, consultez Comment résoudre les problèmes liés à un manque de mémoire libérable dans une base de données Amazon RDS for MySQL ?

Problèmes MySQL et MariaDB

Vous pouvez diagnostiquer et corriger les problèmes des instances de base de données MySQL et MariaDB.

Maximum de connexions MySQL et MariaDB

Le nombre maximum de connexions autorisées à une instance de bases de données RDS for MySQL ou RDS pour MariaDB est basé sur la quantité de mémoire disponible pour la classe de l'instance de bases de données. Une classe d'instance de base de données avec plus de mémoire disponible entraîne un plus grand nombre de connexions disponibles. Pour plus d'informations sur les classes d'instance de base de données, consultez Classes d'instances de base de données .

La limite de connexions pour une instance de base de données est définie par défaut au nombre maximum pour la classe de l'instance de base de données. Vous pouvez limiter le nombre de connexions simultanées à toutes les valeurs jusqu'au nombre maximum de connexions autorisées. Utilisez le paramètre max_connections dans le groupe de paramètres pour l'instance de base de données. Pour de plus amples informations, veuillez consulter Nombre maximal de connexions à une base de données et Utilisation des groupes de paramètres.

Vous pouvez récupérer le nombre maximum de connexions autorisées pour une instance de base de données MySQL ou MariaDB en exécutant la requête suivante.

SELECT @@max_connections;

Vous pouvez récupérer le nombre maximum de connexions actives pour une instance de base de données MySQL ou MariaDB en exécutant la requête suivante.

SHOW STATUS WHERE `variable_name` = 'Threads_connected';

Diagnostic et résolution d'un état de paramètres incompatibles pour une limite de mémoire

Une instance de base de données MariaDB ou MySQL peut être placée dans un statut incompatible-parameters en raison d'une limite de mémoire lorsque les conditions suivantes sont remplies :

  • L'instance de base de données est redémarrée au moins trois fois en une heure ou au moins cinq fois en une journée quand le statut de l'instance de base de données est Disponible.

  • Une tentative de redémarrage de l'instance de base de données échoue car une action de maintenance ou un processus de surveillance n'a pas pu redémarrer l'instance de base de données.

  • L'utilisation potentielle de la mémoire de l'instance de base de données dépasse à hauteur de 1,2 fois la mémoire allouée à sa classe d'instance de base de données.

Lorsqu'une instance de base de données est redémarrée pour la troisième fois en une heure ou pour la cinquième fois en une journée, l'utilisation de la mémoire est vérifiée. Cette vérification effectue un calcul d'utilisation potentielle de la mémoire de l'instance de base de données. La valeur qui en découle correspond à la somme des valeurs suivantes :

  • Valeur 1 – Somme des paramètres suivants :

    • innodb_additional_mem_pool_size

    • innodb_buffer_pool_size

      Vous pouvez modifier la valeur deinnodb_buffer_pool_size. Cependant, la valeur ne correspondra pas toujours à ce que vous avez saisi. Cette incompatibilité se produit pour plusieurs raisons. Tout d'abord, si l'instance de base de données est une micro instance de base de données, nous annulons la valeur par défaut et la définissons sur 256 Mo. Pour plus d’informations, consultez Remplacer innodb_buffer_pool_size.

      Ensuite, nous nous assurons que 500 Mo de mémoire sont réservés sur l'instance de base de données pour le gestionnaire d'hôte, le moteur, le système d'exploitation et le noyau.

      Enfin, nous optimisons innodb_buffer_pool_size en le divisant en unités. Le responsable hôte arrondit au multiple inférieur le plus proche de ces unités. Les unités sont calculées en multipliant innodb_buffer_pool_chunk_size parinnodb_buffer_pool_instances. Pour plus d'informations, consultez Configuration de la taille du pool de mémoire tampon InnoDB dans la documentation MySQL.

      La valeur par défaut innodb_buffer_pool_instances est 8, sauf si innodb_buffer_pool_size elle est inférieure à 1 Go. Si la valeur innodb_buffer_pool_size est inférieure à 1 Go, la valeur par défaut innodb_buffer_pool_instances est 1. La valeur par défaut innodb_buffer_pool_chunk_size est de 128 Mo.

    • innodb_log_buffer_size

    • key_buffer_size

    • query_cache_size (MySQL version 5.7 uniquement)

    • tmp_table_size

  • Valeur 2 – Paramètre max_connections multiplié par la somme des paramètres suivants :

    • binlog_cache_size

    • join_buffer_size

    • read_buffer_size

    • read_rnd_buffer_size

    • sort_buffer_size

    • thread_stack

  • Valeur 3 – Si le paramètre performance_schema est activé, multipliez le paramètre max_connections par 429498.

    Si le performance_schema paramètre est désactivé, cette valeur est nulle.

Ainsi, la valeur renvoyée par le calcul est la suivante :

Value 1 + Value 2 + Value 3

Lorsque cette valeur dépasse à hauteur de 1,2 fois la mémoire allouée à la classe d'instance de base de données utilisée par l'instance de base de données, cette dernière est placée dans un état incompatible-parameters . Pour plus d'informations sur la mémoire allouée aux classes d'instances de bases de données, consultez Spécifications matérielles pour les classes d'instance de base de données .

Le calcul multiplie la valeur du paramètre max_connections par la somme de plusieurs paramètres. Si le paramètre max_connections est défini sur une valeur élevée, la vérification peut renvoyer une valeur excessivement élevée pour l'utilisation potentielle de la mémoire de l'instance de base de données. Dans ce cas, pensez à diminuer la valeur du paramètre max_connections.

Pour résoudre le problème, procédez comme suit :

  1. Ajustez les paramètres de mémoire du groupe de paramètres de base de données associé à l'instance de base de données. Procédez de telle sorte que l'utilisation potentielle de la mémoire soit inférieure à hauteur de 1,2 fois la mémoire allouée à sa classe d'instance de base de données.

    Pour plus d'informations sur la définition des paramètres, consultez Modification de paramètres dans un groupe de paramètres de bases de données.

  2. Redémarrez l'instance de base de données.

    Pour plus d'informations sur la définition des paramètres, consultez Démarrage d'une instance de bases de données Amazon RDS précédemment arrêtée.

Diagnostic et résolution du retard entre réplicas en lecture

Après que vous avez créé un réplica en lecture MySQL ou MariaDB et que le réplica en lecture est disponible, Amazon RDS réplique d'abord les modifications apportées à l'instance de base de données source à partir du moment où l'opération de création du réplica en lecture a été initiée. Durant cette phase, la durée du retard de réplication pour le réplica en lecture est supérieure à 0. Vous pouvez surveiller ce délai dans Amazon en CloudWatch consultant la ReplicaLagmétrique Amazon RDS.

La métrique ReplicaLag contient la valeur du champ Seconds_Behind_Master de la commande MariaDB ou MySQL SHOW REPLICA STATUS. Pour plus d'informations, consultez Instruction SHOW REPLICA STATUS dans la documentation sur MySQL.

Lorsque la métrique ReplicaLag atteint 0, le réplica a rattrapé l'instance de bases de données source. Si la métrique ReplicaLag retourne -1, la réplication n'est probablement pas active. Pour résoudre une erreur de réplication, consultez Diagnostic et résolution d'une défaillance de la réplication en lecture MySQL ou MariaDB. Une valeur de -1 pour ReplicaLag peut également signifier que la valeur Seconds_Behind_Master ne peut pas être déterminée ou qu'elle est NULL.

Note

Les versions précédentes de MariaDB et MySQL utilisaient SHOW SLAVE STATUS à la place de SHOW REPLICA STATUS. Si vous utilisez une version de MariaDB antérieure à la version 10.5 ou MySQL antérieure à la version 8.0.23, utilisez alors SHOW SLAVE STATUS.

La métrique ReplicaLag retourne -1 pendant une panne réseau ou lorsqu'un correctif est appliqué pendant la fenêtre de maintenance. Dans ce cas, attendez que la connexion réseau soit restaurée ou que la fenêtre de maintenance finisse avant de vérifier à nouveau la métrique ReplicaLag .

La technologie de réplication en lecture MySQL et MariaDB est asynchrone. Vous pouvez vous attendre à des augmentations occasionnelles de la métrique BinLogDiskUsage sur l'instance de base de données source, et de la métrique ReplicaLag sur le réplica en lecture. Prenez l'exemple d'une situation dans laquelle un volume élevé d'opérations d'écriture sur l'instance de base de données source se produit en parallèle. Au même moment, les opérations d'écriture sur le réplica en lecture sont sérialisées à l'aide d'un seul thread d'I/O. Une telle situation peut entraîner un décalage entre l'instance source et le réplica en lecture.

Pour de plus amples informations sur les réplicas en lecture et MySQL, veuillez consulter Détails d'implémentation de réplication dans la documentation MySQL. Pour de plus amples informations sur les réplicas en lecture et MariaDB, veuillez consulter Présentation de la réplication dans la documentation MariaDB.

Vous pouvez réduire le retard entre les mises à jour d'une instance de base de données source et les mises à jour suivantes du réplica en lecture en procédant comme suit :

  • Définissez la classe d'instance de base de données du réplica en lecture de telle sorte que sa taille de stockage soit comparable à celle de l'instance de base de données source.

  • Veillez à ce que les paramètres des groupes de paramètres de base de données utilisés par l'instance de base de données source et le réplica en lecture soient compatibles. Pour obtenir plus d'informations et un exemple, reportez-vous à la présentation du paramètre max_allowed_packet dans la section suivante.

  • Désactivez le cache de requête. Pour les tables modifiées fréquemment, l'utilisation du cache de requête peut augmenter le retard, parce que le cache est verrouillé et souvent actualisé. Si tel est le cas, il se peut que vous constatiez un retard de réplica inférieur si vous désactivez le cache de requête. Vous pouvez désactiver le cache de requête en définissant le paramètre query_cache_type parameter avec la valeur 0 dans le groupe de paramètres DB de l'instance de base de données. Pour de plus amples informations sur le cache de requête, veuillez consulter Configuration du pare-feu Windows.

  • Préparez le groupe de tampons sur le réplica en lecture pour InnoDB pour MySQL ou MariaDB. Supposons par exemple que vous disposez d'un ensemble réduit de tables mises à jour fréquemment et que vous utilisez le schéma de table InnoDB ou XtraDB. Dans ce cas, videz ces tables sur le réplica en lecture. Le moteur de base de données analyse alors les lignes des tables du disque et les met en cache dans le groupe de tampons. Cette approche peut réduire le retard de réplica. Voici un exemple.

    Pour LinuxmacOS, ou Unix :

    PROMPT> mysqldump \
    -h <endpoint> \
    --port=<port> \
    -u=<username> \
    -p <password> \
    database_name table1 table2 > /dev/null

    Dans Windows :

    PROMPT> mysqldump ^
    -h <endpoint> ^
    --port=<port> ^
    -u=<username> ^
    -p <password> ^
    database_name table1 table2 > /dev/null

Diagnostic et résolution d'une défaillance de la réplication en lecture MySQL ou MariaDB

Amazon RDS surveille l'état de réplication de vos réplicas lus. RDS met à jour le champ Replication State (État de réplication) de l'instance du réplica en lecture sur Error si la réplication s'arrête pour une raison quelconque. Vous pouvez passer en revue les détails de l'erreur associée et déclenchée par les moteurs MySQL ou MariaDB, en consultant le champ Erreur de réplication. Des événements indiquant l'état du réplica en lecture sont également générés, y compris RDS-EVENT-0045, RDS-EVENT-0046 et RDS-EVENT-0057. Pour plus d'informations sur les événements et l'abonnement aux événements, consultez Utiliser la notification d'événements d'Amazon RDS. Si un message d'erreur MySQL est renvoyé, veuillez consulter l'erreur dans la documentation sur les messages d'erreur MySQL. Si un message d'erreur MariaDB est renvoyé, consultez l'erreur dans la documentation sur les messages d'erreur MariaDB.

Voici d'autres situations courantes susceptibles d'entraîner des erreurs de réplication :

  • La valeur du paramètre max_allowed_packet d'un réplica en lecture est inférieure au paramètre max_allowed_packet de l'instance de base de données source.

    Le paramètre max_allowed_packet est un paramètre personnalisé que vous pouvez définir dans un groupe de paramètres de base de données. Le paramètre max_allowed_packet est utilisé pour spécifier la taille maximale du langage de manipulation de données (DML) qui peut être exécuté sur la base de données. Dans certains cas, la valeur max_allowed_packet de l'instance de base de données source peut être supérieure à la valeur max_allowed_packet du réplica en lecture. Dans ces cas, le processus de réplication peut lancer une erreur et arrêter la réplication. L'erreur la plus courante est packet bigger than 'max_allowed_packet' bytes. Vous pouvez corriger cette erreur en indiquant à la source et au réplica en lecture d'utiliser des groupes de paramètres de base de données avec les mêmes valeurs du paramètre max_allowed_packet.

  • Écriture sur les tables d'un réplica en lecture. Si vous créez des index sur un réplica en lecture, le paramètre read_only doit être défini sur 0 pour créer les index. Si vous écrivez dans des tables sur le réplica en lecture, cela peut interrompre la réplication.

  • Utilisation d'un moteur de stockage non transactionnel tel que MyISAM. Les réplicas en lecture nécessitent un moteur de stockage transactionnel. La réplication n'est prise en charge que pour les moteurs de stockage suivants : InnoDB pour MySQL ou MariaDB.

    Pour convertir une table MyISAM en InnoDB, exécutez la commande suivante :

    alter table <schema>.<table_name> engine=innodb;

  • Utilisation de requêtes non déterministes non sécurisées telles que SYSDATE(). Pour de plus amples informations, veuillez consulter Determination of Safe and Unsafe Statements in Binary Logging dans la documentation MySQL.

Les étapes suivantes peuvent vous aider à résoudre votre erreur de réplication :

  • Si vous rencontrez une erreur logique et que vous pouvez l'ignorer en toute sécurité, suivez la procédure décrite dans Ignorer une erreur de réplication. Votre instance de base de données MySQL ou MariaDB doit exécuter une version incluant la procédure mysql_rds_skip_repl_error. Pour plus d'informations, consultez mysql.rds_skip_repl_error.

  • Si vous rencontrez un problème de position de journal binaire, vous pouvez modifier la position de relecture du réplica avec la commande mysql_rds_next_master_log. Votre instance de base de données MySQL ou MariaDB doit exécuter une version prenant en charge la commande mysql_rds_next_master_log afin de pouvoir modifier la position de relecture du réplica. Pour plus d'informations sur la version, consultez mysql.rds_next_master_log.

  • Vous pouvez rencontrer un problème de performance temporaire en raison d'une charge DML élevée. Si tel est le cas, vous pouvez définir le paramètre innodb_flush_log_at_trx_commit sur 2 dans le groupe de paramètres de base de données pour le réplica en lecture. Cette action peut aider le réplica en lecture à se rattraper, même si l'atomicité, la cohérence, l'isolation et la durabilité s'en trouvent temporairement réduites.

  • Vous pouvez supprimer le réplica en lecture et créer une instance à l'aide du même identifiant d'instance de base de données. Dans ce cas, le point de terminaison reste le même que celui de votre ancien réplica en lecture.

Si une erreur de réplication est corrigée, le champ Replication State (Statut de réplication) prend la valeur replicating (réplication en cours). Pour plus d'informations, consultez Résolution d'un problème de réplica en lecture MySQL.

La création de déclencheurs avec la journalisation binaire activée requiert le privilège SUPER

Lors de la création de déclencheurs dans une instance de bases de données RDS for MySQL ou RDS pour MariaDB, vous pouvez recevoir l'erreur suivante.

"You do not have the SUPER privilege and binary logging is enabled"

L'utilisation des déclencheurs lorsque la journalisation binaire est activée nécessite le privilège SUPER, qui est limité pour les instances de bases de données RDS for MySQL et RDS pour MariaDB. Vous pouvez créer des déclencheurs lorsque la journalisation binaire est activée sans le privilège SUPER en définissant le paramètre log_bin_trust_function_creators avec la valeur true. Pour définir le paramètre log_bin_trust_function_creators sur true, créez un groupe de paramètres DB ou modifiez un groupe de paramètres DB existant.

Vous pouvez créer un nouveau groupe de paramètres de bases de données afin que vous puissiez créer des déclencheurs dans votre instance de bases de données RDS for MySQL ou RDS for MariaDB avec la journalisation binaire activée. Pour cela, utilisez les commandes de l'interface de ligne de commande suivantes. Pour modifier un groupe de paramètres existant, commencez par l'étape 2.

Pour créer un groupe de paramètres et autoriser les déclencheurs avec la journalisation binaire activée à l'aide de l'interface de ligne de commande (CLI)

  1. Créez un groupe de paramètres.

    Pour LinuxmacOS, ou Unix :

    aws rds create-db-parameter-group \
    --db-parameter-group-name allow-triggers \
    --db-parameter-group-family mysql8.0 \
    --description "parameter group allowing triggers"

    Dans Windows :

    aws rds create-db-parameter-group ^
    --db-parameter-group-name allow-triggers ^
    --db-parameter-group-family mysql8.0 ^
    --description "parameter group allowing triggers"

  2. Modifiez le groupe de paramètres DB pour autoriser les déclencheurs.

    Pour LinuxmacOS, ou Unix :

    aws rds modify-db-parameter-group \
    --db-parameter-group-name allow-triggers \
    --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

    Dans Windows :

    aws rds modify-db-parameter-group ^
    --db-parameter-group-name allow-triggers ^
    --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

  3. Modifiez votre instance de base de données pour utiliser le nouveau groupe de paramètres DB.

    Pour LinuxmacOS, ou Unix :

    aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --db-parameter-group-name allow-triggers \
    --apply-immediately

    Dans Windows :

    aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --db-parameter-group-name allow-triggers ^
    --apply-immediately

  4. Pour que les modifications deviennent effectives, redémarrez manuellement l'instance de base de données.

    aws rds reboot-db-instance --db-instance-identifier mydbinstance

Diagnostic et résolution des défaillances de point-in-time restauration

Restauration d'une instance de base de données incluant des tableaux temporaires

Lorsque vous tentez de point-in-time restaurer (PITR) votre instance de base de données MySQL ou MariaDB, vous pouvez rencontrer l'erreur suivante.

Database instance could not be restored because there has been incompatible database activity for restore
functionality. Common examples of incompatible activity include using temporary tables, in-memory tables,
or using MyISAM tables. In this case, use of Temporary table was detected.

Cette restauration s'appuie à la fois sur les instantanés de sauvegarde et les journaux binaires de MySQL ou MariaDB pour restaurer votre instance de base de données à une date spécifique. Les informations des tables temporaires peuvent ne pas être fiables dans les journaux binaires et provoquer une erreur de restauration à un instant dans le passé. Si vous utilisez des tables temporaires dans votre instance de base de données MySQL ou MariaDB, vous pouvez réduire le risque d'une défaillance d'un instant dans le passé. Pour ce faire, exécutez des sauvegardes plus fréquentes. Une telle défaillance est plus à même de se produire entre la création d'une table temporaire et l'instantané de sauvegarde suivant.

Restauration d'une instance de base de données incluant des tableaux en mémoire

Il se peut que vous rencontriez un problème lors de la restauration d'une base de données qui comporte des tables en mémoire. Les tables en mémoire sont vidées lors d'un redémarrage. En conséquence, vos tables en mémoire peuvent être vides après un redémarrage. Lorsque vous utilisez les tables en mémoire, nous vous recommandons de concevoir l'architecture de votre solution de façon à gérer les tables vides en cas de redémarrage. Si vous utilisez des tables en mémoire avec des instances de base de données répliquées, vous devrez peut-être recréer les réplicas en lecture après un redémarrage. Cela peut s'avérer nécessaire si un réplica en lecture redémarre et ne peut pas restaurer les données à partir d'une table en mémoire vide.

Pour plus d'informations sur les sauvegardes et les restaurations à un instant dans le passé, consultez Présentation des sauvegardes et Restauration d'une instance de base de données à une date spécifiée.

Erreur d'arrêt de réplication

Lorsque vous appelez la commande mysql.rds_skip_repl_error, un message d'erreur peut s'afficher pour indiquer que la réplication a rencontré une erreur ou est désactivée.

Ce message d'erreur s'affiche car la réplication a été arrêtée et ne peut pas être redémarrée.

Si vous avez besoin d'ignorer un grand nombre d'erreurs, le retard de réplication peut augmenter et dépasser la période de rétention par défaut pour les fichiers journaux binaires. Dans ce cas, vous pouvez rencontrer une erreur irrécupérable due à des fichiers-journaux binaires purgés avant d'avoir été réutilisés sur le réplica. Cette purge entraîne l'arrêt de la réplication et vous ne pouvez plus appeler la commande mysql.rds_skip_repl_error pour ignorer les erreurs de réplication.

Vous pouvez atténuer ce problème en augmentant le nombre d'heures pendant lequel les fichiers journaux binaires sont conservés sur votre source de réplication. Une fois que vous avez augmenté le temps de rétention de journaux binaires, vous pouvez redémarrer la réplication et appeler la commande mysql.rds_skip_repl_error en fonction des besoins.

Pour définir le temps de rétention du journal binaire, utilisez la procédure mysql.rds_set_configuration. Spécifiez un paramètre de configuration des heures de rétention des journaux binaires, ainsi que le nombre d'heures pendant lequel conserver les fichiers journaux binaires sur le cluster DB, 720 heures au plus (30 jours). L'exemple suivant définit la période de rétention des fichiers journaux binaires à 48 heures.

CALL mysql.rds_set_configuration('binlog retention hours', 48);

La création de réplica en lecture échoue ou la réplication s'arrête avec l'erreur irrécupérable 1236

Après avoir modifié les valeurs de paramètre par défaut pour une instance de base de données MySQL ou MariaDB, vous pouvez rencontrer un des problèmes suivants :

  • Vous ne pouvez pas créer un réplica en lecture pour l'instance de base de données.

  • La réplication échoue avec fatal error 1236.

Certaines valeurs de paramètres par défaut pour les instances de base de données MySQL et MariaDB aident à s'assurer que la base de données est conforme à ACID et que les réplicas en lecture sont sûrs en cas d'incident. Pour cela, les paramètres s'assurent que chaque validation est entièrement synchronisée en écrivant la transaction dans le journal binaire avant qu'elle ne soit validée. La modification de ces paramètres à partir de leurs valeurs par défaut pour améliorer les performances peut entraîner l'échec de la réplication quand une transaction n'a pas été écrite dans le journal binaire.

Pour résoudre ce problème, définissez les valeurs de paramètres suivantes :

  • sync_binlog = 1

  • innodb_support_xa = 1

  • innodb_flush_log_at_trx_commit = 1

Impossible de définir la période de rétention des sauvegardes sur 0

Plusieurs raisons peuvent vous obliger à définir la période de rétention des sauvegardes sur 0. Par exemple, vous pouvez immédiatement désactiver les sauvegardes automatiques en définissant la période de rétention sur 0.

Dans certains cas, vous pouvez définir la valeur sur 0 et recevoir un message indiquant que la période de rétention doit être comprise entre 1 et 35. Vérifiez alors que vous n'avez pas configuré un réplica en lecture pour l'instance. En effet, les réplicas en lecture requièrent des sauvegardes pour la gestion des journaux des réplicas en lecture, ce qui ne vous permet pas de définir la période de rétention sur 0.