Dépannage d’Amazon RDS - Amazon Relational Database Service

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 Amazon RDS et 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 de plus amples informations, veuillez consulter Masquer une 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 au AWS Management Console et ouvrez la console Amazon RDS à 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).

    Pour plus d'informations, consultez Utilisation d'une 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

Si vous pouvez vous connecter à votre instance de base de données, mais que vous obtenez des erreurs d'authentification, 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 d'utilisateur AWS et votre mot de passe pour un compte utilisateur. Une bonne pratique consiste à utiliser votre compte AWS principal pour créer des utilisateurs AWS Identity and Access Management (IAM) 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 IAM, consultez Création d'un utilisateur IAM.

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 IAM doit fournir les rôles nécessaires à votre compte. Pour de plus amples informations, veuillez consulter la documentation IAM.

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 compte AWS 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 d'une instance de base de données à l'aide de la console Amazon RDS, de la commande modify-db-instance de l'AWS CLI ou de l'opération d'API ModifyDBInstance. Pour plus d'informations sur la modification d'une instance de base de données , consultez 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 quand vous redémarrez manuellement votre instance de base de données ou que 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, ou il peut intervenir 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 zéro par zéro, et définissez Appliquer immédiatement sur la valeur true (vrai).

  • 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 à l'aide de la console RDS ou en appelant explicitement l'opération d'API RebootDBInstance (sans basculement, si l'instance de base de données est dans un Multi-AZ deployment). 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 de plus amples informations, veuillez consulter 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 métrique FreeStorageSpace publiée dans CloudWatch pour vous assurer que votre instance de base de données possè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 effectuer une récupération à partir de ce scénario, ajoutez plus d'espace de stockage à votre instance à l'aide de l'opération d'API ModifyDBInstance ou de la commande suivante de l'AWS CLI.

Pour Linux, macOS ou Unix :

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

Pour 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 available (disponible).

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 ou de modifier une instance de base de données, ou lorsque vous essayez de restaurer une instance de base de données à partir d'un instantané de bases de données. Lorsque cette erreur est renvoyée, les éléments suivants sont les raisons les plus courantes :

  • 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 Capacité d'instance insuffisante dans le Guide de l'utilisateur Amazon Elastic Compute Cloud.

  • L'instance de base de données se trouve sur la plateforme EC2-Classic. Par conséquent, elle n'est pas dans un VPC. Certaines classes d'instance de base de données nécessitent un VPC. Par exemple, vous obtenez cette erreur si vous êtes sur la plateforme EC2-Classic et que vous tentez d'augmenter la capacité en passant à une classe d'instance de base de données nécessitant un VPC. Pour de plus amples informations sur les types d'instance Amazon EC2 qui sont disponibles uniquement dans un VPC, consultez Types d'instance disponibles dans EC2-Classic dans le Guide de l'utilisateur Amazon Elastic Compute Cloud. Pour résoudre le problème, vous pouvez transférer l'instance de base de donnée vers un VPC. Pour plus d'informations, consultez Déplacement vers un VPC d'une instance de base de données n'appartenant pas à un VPC.

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

Amazon RDS 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 base de données RDS MySQL ou MariaDB est basé sur la quantité de mémoire disponible pour la classe de l'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 Utilisation de groupes de paramètres de base de données.

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 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 superviser ce retard dans Amazon CloudWatch en affichant la métrique Amazon RDS ReplicaLag .

La métrique ReplicaLag signale la valeur du champ Seconds_Behind_Master de la commande SHOW SLAVE STATUS MySQL ou MariaDB. Pour de plus amples informations, veuillez consulter SHOW SLAVE STATUS. 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 peut être 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.

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'E/S. 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, InnoDB pour MariaDB 10.2 ou version ultérieure, ou XtraDB pour MariaDB 10.1 ou version antérieure. 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 Linux, macOS ou Unix :

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

    Pour 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 supervise l'état de réplication de vos réplicas en lecture et met à jour le champ État de la réplication de l'instance du réplica en lecture avec la valeur 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-0047. Pour plus d'informations sur les événements et l'abonnement aux événements, consultez Utilisation de la notification d'événement 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. Si la valeur max_allowed_packet de l'instance de base de données source est inférieure à la valeur max_allowed_packet du réplica en lecture, le processus de réplication peut lever 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 est uniquement prise en charge pour les moteurs de stockage suivants : InnoDB pour MySQL, InnoDB pour MariaDB 10.2 ou version ultérieure, ou XtraDB pour MariaDB 10.1 ou version antérieure.

    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.

  • Si vous rencontrez temporairement un problème de performance en raison d'une charge DML élevée, vous pouvez définir le paramètre innodb_flush_log_at_trx_commit avec la valeur 2 dans le groupe de paramètres de base de données du 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 base de données MySQL ou MariaDB RDS, 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 base de données MySQL et MariaDB RDS. 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.

Pour créer un groupe de paramètres DB qui permet de créer des déclencheurs dans votre instance de base de données MySQL ou MariaDB RDS avec la journalisation binaire activée, 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

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

    Pour 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"

    Pour 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 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"

    Pour 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 Linux, macOS ou Unix :

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

    Pour 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 restauration à un point donné dans le passé

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

Lors d'une tentative de restauration à un instant dans le passé de votre instance de base de données MySQL ou MariaDB, vous pouvez recevoir 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é en effectuant 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 Utilisation 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, vous pouvez recevoir le message d'erreur suivant : Slave is down or disabled.

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.