Dépannage d'Amazon Aurora - Amazon Aurora
Impossible de se connecter à l'instance de base de données Problèmes de sécuritéRéinitialisation du mot de passe du propriétaire de l'instance de base de donnéesPanne ou redémarrage d'une instance de base de donnéesModifications de paramètre n'entrant pas en vigueurProblèmes liés à la mémoire libérable dans AuroraProblèmes de réplication Aurora MySQL

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 Aurora

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

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

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 au cluster de bases de données dans le VPC.

    Note

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      3. Choisissez Save routes (Enregistrer les routes).

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

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

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.

Problèmes de sécurité Amazon RDS

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

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

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

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

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

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

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

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).

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.

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

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

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

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

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

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

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 Aurora.

Vous pouvez également modifier les paramètres de mémoire. Par exemple, sur Aurora 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 ?

Pour Aurora Serverless v2, FreeableMemory représente la quantité de mémoire inutilisée qui est disponible lorsque l'instance de base de données Aurora Serverless v2 est mise à l'échelle jusqu'à sa capacité maximale. La capacité de l'instance peut être réduite à une valeur relativement faible, mais elle indique toujours une valeur élevée pour FreeableMemory, car la taille de l'instance peut augmenter. Cette mémoire n'est pas disponible pour le moment, mais vous pouvez l'obtenir si vous en avez besoin.

Pour chaque unité de capacité Aurora (ACU) dont la capacité actuelle est inférieure à la capacité maximale, FreeableMemory augmente d'environ 2 Gio. Par conséquent, cette métrique ne se rapproche pas de zéro tant que l'instance de base de données ne fait pas l'objet d'une augmentation d'échelle aussi élevée que possible.

Si cette métrique se rapproche de la valeur 0, l'instance de base de données a fait l'objet d'une augmentation d'échelle aussi élevée que possible. Elle approche de sa limite de mémoire disponible. Envisagez d'augmenter le nombre maximal d'ACU pour le cluster. Si cette métrique se rapproche de la valeur 0 sur une instance de base de données de lecteur, envisagez d'ajouter des instances de base de données de lecteur supplémentaires au cluster. De cette façon, vous pouvez répartir la partie en lecture seule de la charge de travail sur un plus grand nombre d'instances de base de données, réduisant ainsi l'utilisation de la mémoire sur chaque instance de base de données de lecteur. Pour plus d’informations, consultez Statistiques Amazon CloudWatch importantes pour Aurora Serverless v2.

Pour Aurora Serverless v1, vous pouvez modifier la plage de capacité pour utiliser plus d'ACU. Pour plus d’informations, consultez Modification d'un cluster de bases de données Aurora Serverless v1.

Problèmes de réplication Amazon Aurora MySQL

Certains problèmes de réplication MySQL s'appliquent également à Aurora MySQL. Vous pouvez diagnostiquer et corriger ces problèmes.

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

Après que vous avez créé un réplica en lecture MySQL 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 métrique Amazon RDS.

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

Lorsque la métrique AuroraBinlogReplicaLag atteint 0, le réplica a rattrapé l'instance de bases de données source. Si la métrique AuroraBinlogReplicaLag retourne -1, la réplication n'est probablement pas active. Pour résoudre une erreur de réplication, consultez Diagnostic et résolution d'une défaillance de la réplication en lecture MySQL. Une valeur de -1 pour AuroraBinlogReplicaLag 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 d'Aurora MySQL utilisaient SHOW SLAVE STATUS à la place de SHOW REPLICA STATUS. Si vous utilisez une version Aurora MySQL version 1 ou 2, utilisez alors SHOW SLAVE STATUS. Utilisez SHOW REPLICA STATUS pour Aurora MySQL version 3 et ultérieure.

La métrique AuroraBinlogReplicaLag 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 AuroraBinlogReplicaLag.

La technologie de réplication en lecture MySQL 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 AuroraBinlogReplicaLag sur le réplica en lecture. Prenez l'exemple d'une situation dans laquelle un volume élevé d'opérations d'écriture sur l'instance de base de données source se produit en parallèle. Au même moment, les opérations d'écriture sur le réplica en lecture sont sérialisées à l'aide d'un seul thread d'I/O. Une telle situation peut entraîner un décalage entre l'instance source et le réplica en lecture.

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

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

    Pour LinuxmacOS, ou Unix :

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

    Dans Windows :

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

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

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, en consultant le champ Erreur de réplication. Des événements indiquant l'état du réplica en lecture sont également générés, y compris RDS-EVENT-0045, RDS-EVENT-0046 et RDS-EVENT-0057. Pour plus d'informations sur les événements et l'abonnement aux événements, consultez Utiliser la notification d'événements d'Amazon RDS. Si un message d'erreur MySQL est renvoyé, veuillez consulter l'erreur dans la documentation sur les messages d'erreur MySQL.

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

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

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

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

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

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

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

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

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

  • Si vous rencontrez une erreur logique et que vous pouvez l'ignorer en toute sécurité, suivez la procédure décrite dans Skipping the Current Replication Error (Ignorer l'erreur de réplication actuelle). Votre instance de base de données Aurora MySQL 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. Pour ce faire, utilisez la commande mysql.rds_next_master_log pour Aurora MySQL versions 1 et 2. Pour ce faire, utilisez la commande mysql.rds_next_source_log pour Aurora MySQL versions 3 et ultérieures. Votre instance de base de données Aurora MySQL doit exécuter une version prenant en charge cette commande 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 de plus amples informations, veuillez consulter Résolution d'un problème de réplica en lecture MySQL.

Erreur d'arrêt de réplication

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

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

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

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

Pour définir le temps de rétention du journal binaire, utilisez la procédure mysql_rds_set_configuration. Spécifiez un paramètre de configuration des heures de rétention des journaux binaires, ainsi que le nombre d'heures pendant lequel conserver les fichiers journaux binaires sur le cluster de base de données, 2 160 heures au plus (90 jours). La valeur par défaut de Aurora MySQL est de 24 heures (1 jour). 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);