Résolution des problèmes pour 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 stockageInstances de base de données disponibles insuffisantesProblèmes de mémoire RDSlibérable avec Mes problèmes SQL et ceux de 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.

Résolution des problèmes pour 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 plus d'informations sur les problèmes de débogage à l'aide d'Amazon RDSAPI, consultezApplications de dépannage sur Amazon RDS.

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

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 spécifier une adresse IP, une plage d'adresses IP ou un autre groupe VPC de sécurité.

    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 Donnez accès à votre instance de base VPC de données dans votre.

    Note

    Les connexions client à partir d'adresses IP dans la plage 169.254.0.0/16 ne sont pas autorisées. Il s'agit de la plage d'adressage IP privé automatique (APIPA), qui est utilisée pour l'adressage par liaison locale.

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

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

  • 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 RDS console Amazon 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 Connectivité et sécurité, notez les valeurs de l'VPCID sous VPCet de l'ID de sous-réseau sous Sous-réseaux.

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

    5. Dans le panneau de navigation, choisissez Passerelles Internet. Vérifiez qu'une passerelle Internet est connectée à votreVPC. Sinon, choisissez Créer une passerelle Internet pour créer une passerelle Internet. Sélectionnez la passerelle Internet, puis choisissez Joindre à VPC et suivez les instructions pour la joindre à votreVPC.

    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 un itinéraire avec 0.0.0.0/0 comme destination et qu'il existe une passerelle Internet pour vous VPC comme cible.

      Si vous vous connectez à votre instance à l'aide de son IPv6 adresse, vérifiez qu'il existe un itinéraire pour tout le IPv6 trafic (::/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.

        PourIPv6, choisissez Ajouter un itinéraire, utilisez ::/0 comme destination et la passerelle Internet comme cible.

      3. Choisissez Save routes (Enregistrer les acheminements).

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

    Pour de plus amples informations, veuillez consulter Utilisation d'un d'instances 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 Internet Control Message Protocol (ICMP), y compris le 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 le faire en modifiant l'RDSinstance.

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

Problèmes de RDS sécurité liés à Amazon

Pour éviter les problèmes de sécurité, n'utilisez jamais votre adresse e-mail d'utilisateur Compte AWS root ni le mot de passe d'un compte utilisateur. La meilleure pratique consiste à utiliser votre utilisateur root pour créer des utilisateurs et les attribuer à des comptes utilisateur de base de données. Vous pouvez également utiliser votre utilisateur root pour créer d'autres comptes utilisateur, si nécessaire.

Pour plus d'informations sur la création d'utilisateurs, consultez la section Création IAM d'un utilisateur 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 plus d'informations, consultez la IAM documentation.

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 le https://console.aws.amazon.com/rds/et choisissez Databases dans le volet de navigation.

  2. Choisissez l'instance de base de données dont l'état de réseau est incompatible et notez l'identifiant, l'VPCID et le sous-réseau de l'instance de base IDs de données 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 start-db-instance commande ne résout pas ce problème RDS pour les instances de base de données SQL du serveur.

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 start-db-instance commande échoue ou si l'instance revient à un état de réseau incompatible, ouvrez la page Bases de données dans la RDS console 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 :

  • INTERNALRESOURCECHECK: il se peut que des problèmes soient liés à vos ressources internes.

  • DNSCHECK: Vérifiez DNS la résolution et les noms d'hôte VPC dans la VPC console.

  • ENICHECK: L'elastic network interface (ENI) de votre base de données n'existe peut-être pas.

  • GATEWAYCHECK: La passerelle Internet de votre base de données accessible au public n'est pas rattachée auVPC.

  • IP CHECK : il n'y a aucune adresse IP libre dans vos sous-réseaux.

  • SECURITYGROUPCHECK: aucun groupe de sécurité n'est associé à votre base de données ou les groupes de sécurité ne sont pas valides.

  • SUBNETCHECK: 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.

  • VPCCHECK: Le fichier VPC associé à votre base de données n'est pas valide.

Procéder à point-in-time la 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. Consultez 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 RDS console Amazon modify-db-instance, de la AWS CLI commande ou de l'odifyDBInstanceAPIopération M. Pour plus d'informations sur la modification d'une instance de base de données, veuillez consulter Modification d'une RDS instance de base de données Amazon.

Panne ou redémarrage de l'RDSinstance de base de données Amazon

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 modifiez le type de stockage magnétique (standard) à usage général (SSD) ou provisionné IOPS (SSD), ou de provisionné IOPS (SSD) ou à usage général (SSD) à 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 RDS instance de base de données Amazon.

Les modifications des paramètres Amazon RDS DB ne prennent pas effet

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 à l'aide de la RDS console. Vous pouvez également appeler explicitement l'RebootDBInstanceAPIopération. Vous pouvez redémarrer sans basculement si l'instance de base de données se trouve dans un déploiement multi-AZ. L'obligation de redémarrer l'instance de base de données associée après une modification de paramètre statique contribue à atténuer le risque qu'une mauvaise configuration des paramètres affecte un API appel. Par exemple, appeler ModifyDBInstance pour changer la classe de l'instance de base de données. Pour de plus amples informations, veuillez consulter Modification des paramètres d'un groupe de paramètres de base de données dans Amazon RDS.

L'RDSinstance de base de données Amazon est à court de stockage

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, un appel à l'DescribeDBInstancesAPIopération pour une instance de base de données qui a épuisé son espace de stockage produit les résultats suivants.

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'ModifyDBInstanceAPIopération ou de la AWS CLI commande suivante.

Dans Linux, macOS, 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

Amazon : RDS nombre insuffisant d'instances de base de données disponibles

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 plus d'informations sur la résolution des problèmes de capacité d'instance pour AmazonEC2, consultez la section Capacité d'instance insuffisante dans le guide de EC2 l'utilisateur Amazon.

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

Problèmes liés à la mémoire disponible dans RDS

La mémoire disponible est la quantité totale de mémoire à accès aléatoire (RAM) d'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 majeure partie de la mémoire de l'hôte, mais les processus du système d'exploitation en utilisent également une partieRAM. 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 de plus amples informations, veuillez consulter Outils de surveillance pour 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 de plus amples informations, veuillez consulter Classes d'instances de base de données .

Vous pouvez également modifier les paramètres de mémoire. Par exemple, dans for My SQL, vous pouvez ajuster la taille du innodb_buffer_pool_size paramètre. Ce paramètre est défini par défaut sur 75 % de la mémoire physique. Pour en savoir plus sur mes conseils de SQL résolution des problèmes, consultez Comment puis-je résoudre le problème du manque de mémoire disponible dans une base de données Amazon RDS for My ? SQL

Mes problèmes SQL et ceux de MariaDB Amazon Mes problèmes de réplication SQL

Vous pouvez diagnostiquer et corriger les problèmes liés aux instances de base de SQL données My et MariaDB.

Nombre maximal de connexions My SQL et MariaDB

Le nombre maximum de connexions autorisées à une instance de base de données RDS RDS for My SQL ou pour MariaDB est basé sur la quantité de mémoire disponible pour sa classe d'instance de base 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 plus d’informations, consultez Nombre maximal de connexions à une base de données et Groupes de paramètres pour Amazon RDS.

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

SELECT @@max_connections;

Vous pouvez récupérer le nombre de connexions actives à une instance de base de données My SQL 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 MariaDB ou SQL My DB peut être placée dans un état de paramètres incompatibles pour 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 de plus amples informations, veuillez consulter 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 la section Configuration de la taille du pool de mémoire tampon InnoDB dans la section Ma SQL documentation.

      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(Ma SQL 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 des paramètres d'un groupe de paramètres de base de données dans Amazon RDS.

  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 RDS instance de base de données Amazon précédemment arrêtée.

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

Une fois que vous avez créé une réplique de lecture My SQL ou MariaDB et que la réplique est disponible, RDS Amazon réplique d'abord les modifications apportées à l'instance de base de données source depuis le début de l'opération de création de la réplique de lecture. Durant cette phase, la durée du retard de réplication pour le réplica en lecture est supérieure à 0. Vous pouvez suivre ce décalage dans Amazon en CloudWatch consultant la RDS ReplicaLagmétrique Amazon.

La ReplicaLag métrique indique la valeur du Seconds_Behind_Master champ de la commande MariaDB ou My. SQL SHOW REPLICA STATUS Pour plus d'informations, consultez la section SHOWREPLICASTATUSDéclaration dans la section Ma SQL documentation.

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'un échec de réplication en SQL lecture My 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 SQL My SHOW SLAVE STATUS utilisaient à la place de. SHOW REPLICA STATUS Si vous utilisez une version de MariaDB antérieure à 10.5 ou une version SQL My antérieure à 8.0.23, utilisez. 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 de lecture My SQL 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 plus d'informations sur Read Replicas et MySQL, consultez la section Détails de l'implémentation de la réplication dans la SQL documentation My. 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.

  • Réchauffez le pool de mémoire tampon sur la réplique en lecture pour InnoDB for My ou SQL 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.

    Dans Linux, macOS, 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'un échec de réplication en SQL lecture My ou MariaDB

Amazon RDS surveille l'état de réplication de vos répliques de lecture. RDSmet à jour le champ État de réplication de l'instance de réplique lue pour indiquer Error si la réplication s'arrête pour une raison quelconque. Vous pouvez consulter les détails de l'erreur associée générée par les moteurs My SQL 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 Utilisation des notifications d'RDSévénements Amazon. Si un message Mon SQL erreur est renvoyé, vérifiez l'erreur dans la documentation Mon message SQL d'erreur. 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 max_allowed_packet paramètre 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.

  • À l'aide d'un moteur de stockage non transactionnel tel que My. ISAM 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 for My ou SQL MariaDB.

    Vous pouvez convertir une ISAM table My en InnoDB à l'aide de 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 plus d'informations, consultez la section Détermination des instructions sûres et non sûres dans la journalisation binaire dans la section Ma SQL documentation.

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 l'erreur de réplication actuelle pour RDS for My SQL. Votre instance de base de données My SQL ou MariaDB doit exécuter une version qui inclut la procédure. mysql_rds_skip_repl_error Pour de plus amples informations, veuillez consulter 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 My SQL ou MariaDB doit exécuter une version prenant en charge la commande permettant de modifier mysql_rds_next_master_log la position de rediffusion de la réplique. Pour plus d'informations sur la version, consultez .

  • Il se peut que vous rencontriez un problème de performance temporaire en raison d'une DML charge é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. Cela peut aider la réplique lue à rattraper son retard, tout en réduisant temporairement l'atomicité, la cohérence, l'isolation et la durabilité (ACID).

  • 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 lié à SQL la réplique My read.

La création de déclencheurs avec la journalisation binaire activée nécessite des SUPER privilèges

Lorsque vous essayez de créer des déclencheurs dans une instance de base de données RDS RDS for My SQL ou pour MariaDB, le message d'erreur suivant peut s'afficher.

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

L'utilisation de déclencheurs lorsque la journalisation binaire est activée nécessite le SUPER privilège, qui est restreint RDS pour les instances de base de SQL données My et RDS MariaDB. Vous pouvez créer des déclencheurs lorsque la journalisation binaire est activée sans le SUPER privilège en définissant le log_bin_trust_function_creators paramètre sur 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 base de données afin de créer des déclencheurs dans votre instance de base de données RDS RDS for My SQL ou pour MariaDB avec la journalisation binaire activée. Pour ce faire, utilisez les CLI commandes suivantes. Pour modifier un groupe de paramètres existant, commencez par l'étape 2.

Pour créer un nouveau groupe de paramètres afin d'autoriser les déclencheurs avec la journalisation binaire activée à l'aide du CLI

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

    Dans Linux, macOS, 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.

    Dans Linux, macOS, 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.

    Dans Linux, macOS, 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 qui inclut des tables temporaires

Lorsque vous tentez de point-in-time restaurer (PITR) de votre instance de base de données My SQL 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.

PITRs'appuie à la fois sur les instantanés de sauvegarde et les journaux binaires (binlogs) de My ou SQL MariaDB pour restaurer votre instance de base de données à un moment donné. Les informations des tables temporaires peuvent ne pas être fiables dans les journaux binaires et provoquer une PITR défaillance. Si vous utilisez des tables temporaires dans votre instance de base de données My SQL ou MariaDB, vous pouvez réduire le risque de panne en effectuant des PITR sauvegardes plus fréquentes. Un PITR échec est très probable entre la création d'une table temporaire et le prochain instantané de sauvegarde.

Restauration d'une instance de base de données qui inclut des tables 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 etPITR, voir Présentation des sauvegardes etRestauration d'une instance de base de données à une heure spécifiée pour Amazon RDS.

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 des paramètres par défaut pour une instance de base de données My SQL ou MariaDB, vous pouvez rencontrer l'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 My SQL et MariaDB permettent de s'assurer que la base de données ACID est conforme et que les répliques en lecture sont protégées contre les pannes. 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.