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. **Topics** + [Impossible de se connecter à l’instance de base de données Amazon RDS](#CHAP_Troubleshooting.Connecting) + [Problèmes de sécurité Amazon RDS](#CHAP_Troubleshooting.Security) + [Résolution des problèmes liés à l’état de réseau incompatible](#CHAP_Troubleshooting.IncompatibleNetworkMode) + [Réinitialisation du mot de passe du propriétaire de l’instance de base de données](#CHAP_Troubleshooting.ResetPassword) + [Panne ou redémarrage d’une instance de base de donnéesAmazon RDS](#CHAP_Troubleshooting.Reboots) + [Modifications de paramètre de base de données Amazon RDS n’entrant pas en vigueur](#CHAP_Troubleshooting.Parameters) + [Manque d’espace de stockage de l’instance de base de données Amazon RDS](#CHAP_Troubleshooting.Storage) + [Nombre d’instances de base de données Amazon RDS disponibles insuffisant](#CHAP_Troubleshooting.Capacity) + [Problèmes liés à la mémoire libérable dans Amazon RDS](#Troubleshooting.FreeableMemory) + [Problèmes MySQL et MariaDB](#CHAP_Troubleshooting.MySQL) + [Impossible de définir la période de rétention des sauvegardes sur 0](#CHAP_Troubleshooting.Backup.Retention) Pour plus d’informations sur le débogage des problèmes à l’aide de l’API Amazon RDS, consultez [Applications de dépannage sur Amazon RDS](APITroubleshooting.md). ## 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 plus d’informations sur la configuration des groupes de sécurité, consultez [Créer un groupe de sécurité qui autorise l'accès à votre instance de base de données dans votre VPC](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup). **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 une instance de base de données dans un VPC depuis Internet](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding). + **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 à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse. 1. Dans le panneau de navigation, sélectionnez **Bases de données**, puis sélectionnez le nom de l’instance de base de données. 1. 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)**. 1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. 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. 1. Dans le panneau de navigation, sélectionnez **Sous-réseaux**, puis sélectionnez votre sous-réseau. 1. 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 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. 1. 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 **Ajouter un itinéraire**, utilisez `::/0` comme destination et la passerelle Internet comme cible. 1. 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' IPv6 adresses client est autorisée à se connecter à l'instance de base de données. Pour de plus amples informations, veuillez consulter [Utilisation d’une instance de base de données dans un VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md). Pour les problèmes de connexion spécifiques au moteur, consultez les rubriques suivantes : + [Résolution des problèmes de connexion à votre instance de base de données SQL Server](USER_ConnectToMicrosoftSQLServerInstance.Troubleshooting.md) + [Résolution des problèmes de connexion à votre instance de base de données Oracle](USER_ConnectToOracleInstance.Troubleshooting.md) + [Résolution des problèmes de connexion à votre instance RDS pour PostgreSQL](USER_ConnectToPostgreSQLInstance.Troubleshooting.md) + [Maximum de connexions MySQL et MariaDB](#USER_ConnectToInstance.max_connections) ### 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 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](Overview.DBInstance.Modifying.md). ## Problèmes de sécurité Amazon RDS 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. Une bonne pratique consiste à utiliser votre utilisateur racine pour créer des utilisateurs et les affecter à des comptes d’utilisateur de base de données. Vous pouvez aussi utiliser votre utilisateur racine 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html). 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](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html). ### 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 documentation IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/). ## 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’instance 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 à la suite 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/](https://console.aws.amazon.com/rds/)et choisissez **Databases** dans le volet de navigation. 1. **Choisissez l'instance de base de données dont l'état de réseau est incompatible et notez l'identifiant de l'instance de base de données, l'ID VPC et le sous-réseau dans l'onglet Connectivité IDs et sécurité.** 1. 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 une durée d’indisponibilité. 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. #### 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](USER_WorkingWithAutomatedBackups.md). 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 instance de base de données. Migrez ensuite les données à l’aide d’[AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/;Welcome.html) ou en utilisant un outil de sauvegarde et de restauration. Si cela ne résout pas le problème, contactez 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 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 plus d’informations sur les comptes ou rôles administratifs que vous devrez peut-être réinitialiser, consultez [Privilèges du compte utilisateur principal](UsingWithRDS.MasterAccounts.md). Vous pouvez modifier le mot de passe de l'instance de base de données à l'aide de la console Amazon RDS [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html), de la AWS CLI commande ou de l'opération [DBInstanceModify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API. 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](Overview.DBInstance.Modifying.md). ## 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](Overview.DBInstance.Modifying.md). ## 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 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html). 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 base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ## 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 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. ``` 1. 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 ``` ## Nombre d’instances de base de données Amazon RDS disponibles insuffisant 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 le dépannage de problèmes de capacité d’instance pour Amazon EC2, consultez [Insufficient instance capacity](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html#troubleshooting-launch-capacity) (Capacité d’instance insuffisante) dans le *Guide de l’utilisateur Amazon EC2*. 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](Overview.DBInstance.Modifying.md). ## 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 de plus amples informations, veuillez consulter [Surveillance des outils d’Amazon RDS](MonitoringOverview.md). 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 ](Concepts.DBInstanceClass.md). 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 ?](https://aws.amazon.com/premiumsupport/knowledge-center/low-freeable-memory-rds-mysql-mariadb/) ## Problèmes MySQL et MariaDB Vous pouvez diagnostiquer et corriger les problèmes des instances de base de données MySQL et MariaDB. **Topics** + [Maximum de connexions MySQL et MariaDB](#USER_ConnectToInstance.max_connections) + [Diagnostic et résolution d’un état de paramètres incompatibles pour une limite de mémoire](#CHAP_Troubleshooting.incompatible-parameters-memory) + [Diagnostic et résolution du retard entre réplicas en lecture](#CHAP_Troubleshooting.MySQL.ReplicaLag) + [Diagnostic et résolution d'un échec de réplication en lecture MySQL ou MariaDB](#CHAP_Troubleshooting.MySQL.RR) + [La création de déclencheurs avec la journalisation binaire activée requiert le privilège SUPER](#CHAP_Troubleshooting.MySQL.CreatingTriggers) + [Diagnostic et résolution des défaillances de point-in-time restauration](#CHAP_Troubleshooting.MySQL.PITR) + [Erreur d’arrêt de réplication](#CHAP_Troubleshooting.MySQL.ReplicationStopped) + [La création de réplica en lecture échoue ou la réplication s’arrête avec l’erreur irrécupérable 1236](#CHAP_Troubleshooting.MySQL.ReadReplicas) + [La réplication du réplica en lecture ne parvient pas à initialiser la structure des métadonnées](#CHAP_Troubleshooting.MySQL.ReadReplicas.ReplicationErrorMetadata) ### Maximum de connexions MySQL et MariaDB Le nombre maximum de connexions autorisées à une instance de base de données RDS for MySQL ou RDS for 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 ](Concepts.DBInstanceClass.md). 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](CHAP_Limits.md#RDS_Limits.MaxConnections) et [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md). 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 d’`innodb_buffer_pool_size`. Cependant, la valeur ne correspond pas toujours à ce que vous avez saisi. Plusieurs raisons peuvent expliquer cette inadéquation. Tout d’abord, si l’instance de base de données est une micro instance de base de données, nous remplaçons la valeur par défaut par 256 Mo. Pour plus d’informations, consultez [Remplacer innodb\$1buffer\$1pool\$1size](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.innodb-bp-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 gestionnaire hôte arrondit cette valeur au multiple inférieur le plus proche de ces unités. Les unités sont calculées en multipliant `innodb_buffer_pool_chunk_size` par `innodb_buffer_pool_instances`. Pour plus d’informations, consultez [Configuring InnoDB Buffer Pool Size](https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool-resize.html) dans la documentation MySQL. La valeur par défaut de `innodb_buffer_pool_instances` est 8, sauf si `innodb_buffer_pool_size` est inférieur à 1 Go. Si `innodb_buffer_pool_size` est inférieur à 1 Go, la valeur par défaut de `innodb_buffer_pool_instances` est 1. La valeur par défaut de `innodb_buffer_pool_chunk_size` est 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’instance de base de données, consultez [Spécifications matérielles pour les classes d'instances de base de données ](Concepts.DBInstanceClass.Summary.md). 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 base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. 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](USER_StartInstance.md). ### 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 `ReplicaLag`mé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](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) dans la documentation sur MySQL. Lorsque la métrique `ReplicaLag` atteint 0, le réplica a rattrapé l’instance de base 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 lecture MySQL ou MariaDB](#CHAP_Troubleshooting.MySQL.RR). 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 utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version de MariaDB antérieure à 10.5, 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 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. Dans le même temps, les opérations d'écriture sur la réplique de lecture sont sérialisées à l'aide d'un seul I/O thread. Une telle situation peut entraîner un décalage entre l’instance source et le réplica en lecture. Pour plus d’informations sur les réplicas en lecture et MySQL, consultez [Détails d’implémentation de réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html) dans la documentation MySQL. Pour plus d’informations sur les réplicas en lecture et MariaDB, consultez [Présentation de la réplication](http://mariadb.com/kb/en/mariadb/replication-overview/) 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 plus d’informations sur le cache de requête, consultez [Configuration du pare-feu Windows](https://dev.mysql.com/doc/refman/5.7/en/query-cache-configuration.html). + 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 Linux, macOS ou Unix : ``` PROMPT> mysqldump \ -h \ --port= \ -u= \ -p \ database_name table1 table2 > /dev/null ``` Pour Windows : ``` PROMPT> mysqldump ^ -h ^ --port= ^ -u= ^ -p ^ database_name table1 table2 > /dev/null ``` ### Diagnostic et résolution d'un échec de 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](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) et [RDS-EVENT-0057](USER_Events.Messages.md#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](USER_Events.md). Si un message d’erreur MySQL est renvoyé, consultez l’erreur dans la [documentation sur les messages d’erreur MySQL](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html). Si un message d’erreur MariaDB est renvoyé, consultez l’erreur dans la [documentation sur les messages d’erreur MariaDB](http://mariadb.com/kb/en/mariadb/mariadb-error-codes/). 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 . engine=innodb;` + Utilisation de requêtes non déterministes non sécurisées telles que `SYSDATE()`. Pour plus d’informations, consultez [Determination of Safe and Unsafe Statements in Binary Logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) 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 pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). 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\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error). + Si vous rencontrez un problème de position de journal binaire (binlog), vous pouvez modifier la position de relecture du réplica avec la commande [mysql.rds\$1next\$1source\$1log (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_next_source_log) ou [](mysql-stored-proc-replicating.md#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](USER_ReadRepl.Troubleshooting.md). ### 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 RDS for MySQL ou RDS for 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 base de données RDS for MySQL et RDS for 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 base 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 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" ``` 1. 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" ``` 1. 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 ``` 1. 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 tables 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 ponctuelle. Si vous utilisez des tables temporaires dans votre instance de base de données MySQL ou MariaDB, vous pouvez réduire le risque d’échec de reprise ponctuelle 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 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 et les restaurations à un instant dans le passé, consultez [Présentation des sauvegardes](USER_WorkingWithAutomatedBackups.md) et [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md). ### 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\$1set\$1configuration](mysql-stored-proc-configuring.md#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 de bases de données, 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` ### La réplication du réplica en lecture ne parvient pas à initialiser la structure des métadonnées Lorsque vous avez essayé de démarrer la réplication, vous avez reçu le message d’erreur suivant : ``` Read Replica Replication Error - SQLError: 13124, reason: Replica failed to initialize applier metadata structure from the repository ``` Cette erreur se produit en cas de problème lié à la structure des métadonnées du réplica. Pour corriger la structure des métadonnées, vous devez créer un nouveau réplica. Pour éviter que cela ne se reproduise à l’avenir, effectuez une des actions suivantes : + Si possible, désactivez le multithreading sur vos réplicas. À partir de MySQL 8.0.27, le multithreading est activé par défaut. + Si vous devez utiliser le multithreading sur vos réplicas, nous vous recommandons d’utiliser la réplication basée sur le GTID. Pour plus d’informations, consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md). ## 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.