Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Résolution d'un problème de réplica en lecture MySQL
Dans certains cas, pour les instances de base de données, les réplicas en lecture présentent des erreurs ou des incohérences de données (ou les deux) entre le réplica en lecture et son instance de base de données source. Ce problème survient quand des événements de journaux binaires ou des journaux redo InnoDB ne sont pas vidés lors d'une panne du réplica en lecture ou de l'instance de base de données source. Dans ces situations, supprimez et recréez manuellement les réplicas en lecture. Vous pouvez réduire la probabilité que cela se produise en définissant les valeurs de paramètre suivantes : sync_binlog=1 et innodb_flush_log_at_trx_commit=1. Ces paramètres peuvent réduire les performances. Testez donc leur impact avant d’implémenter les modifications dans un environnement de production.
Avertissement
Dans le groupe de paramètres associé à l'instance de base de données source, nous recommandons de conserver ces valeurs de paramètres : sync_binlog=1 et innodb_flush_log_at_trx_commit=1. Ces paramètres sont dynamiques. Si vous ne souhaitez pas utiliser ces paramètres, nous vous recommandons de définir temporairement ces valeurs avant d'exécuter toute opération sur l'instance de base de données source susceptible de provoquer son redémarrage. Ces opérations incluent, sans s'y limiter, le redémarrage, le redémarrage avec basculement, la mise à niveau de la version de la base de données et la modification de la classe d'instance de base de données ou de son stockage. La même recommandation s'applique à la création de nouveaux réplicas en lecture pour l'instance de base de données source.
Le non-respect de ces instructions augmente le risque que les réplicas en lecture présentent des erreurs ou des incohérences de données (ou les deux) entre le réplica en lecture et son instance de base de données source.
Les technologies de réplication pour MySQL sont asynchrones. Parce qu’elles sont asynchrones, des augmentations occasionnelles de BinLogDiskUsage sur l’instance de base de données source et ReplicaLag sur le réplica en lecture sont prévisibles. Par exemple, un volume élevé d’opérations d’écriture sur l’instance de bases de données source peut se produire en parallèle. Tandis que les opérations d’écritures sur le réplica en lecture sont sérialisées à l’aide d’un seul thread d’I/O, ce qui peut conduire à un retard entre l’instance source et le réplica. Pour plus d’informations sur les réplicas en lecture seule dans la documentation MySQL, consultez Détails d’implémentation de la réplication
Vous pouvez effectuer plusieurs opérations pour réduire le retard entre les mises à jour d’une instance de base de données source et les mises à jour suivantes appliquées au réplica en lecture, telles que les opérations suivantes :
-
Dimensionnement d’un réplica en lecture pour qu’il ait une taille de stockage et une classe d’instance de base de données comparables à celles de l’instance de base de données source.
-
Garantie que les réglages des paramètres dans les 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 sont compatibles. Pour obtenir plus d’informations et un exemple, reportez-vous à la présentation du paramètre
max_allowed_packet, plus loin dans cette section.
Amazon RDS surveille l’état de réplication de vos réplicas en lecture et met à jour le champ Replication State de l’instance du réplica en lecture avec la valeur Error si la réplication s’arrête pour une raison quelconque. Par exemple, dans le cas de requêtes DML exécutées sur votre réplica en lecture qui sont en conflit avec les mises à jour effectuées sur l’instance de base de données source.
Vous pouvez passer en revue les détails de l'erreur associée et déclenchée par le moteur MySQL, en consultant le champ Replication Error. 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 Utiliser la notification d'événements d'Amazon RDS. Si un message d'erreur MySQL est renvoyé, passez en revue le numéro de l'erreur dans la documentation sur les messages d'erreur MySQL
Un problème courant susceptible de causer des erreurs de réplication se pose lorsque la valeur du paramètre max_allowed_packet d’un réplica en lecture est inférieure à celle du 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. Vous utilisez max_allowed_packet pour spécifier la taille maximale du code DML qui peut être exécuté sur la base de données. Dans certains cas, la valeur max_allowed_packet du groupe de paramètres de base de données associé à un réplica en lecture est inférieure à la valeur max_allowed_packet du groupe de paramètres de base de données associé à l'instance de base de données source. Dans ces cas, le processus de réplication peut lancer l'erreur Packet bigger than
'max_allowed_packet' bytes et arrêter la réplication. Pour corriger cette erreur, faites en sorte que l'instance de base de données source et le réplica en lecture utilisent des groupes de paramètres de base de données avec les mêmes valeurs pour le paramètre max_allowed_packet.
Voici d’autres situations courantes susceptibles de causer des erreurs de réplication :
Écriture sur les tables d’un réplica en lecture. Dans certains cas, vous pouvez créer des index sur un réplica en lecture différents des index sur l'instance de base de données source. Vous devez alors définir le paramètre
read_onlysur0pour créer les index. Si vous écrivez dans des tables sur le réplica en lecture, cela peut interrompre la réplication si le réplica en lecture devient incompatible avec l'instance de base de données source. Une fois que vous avez effectué les tâches de maintenance sur le réplica en lecture, nous vous recommandons de définir à nouveau le paramètreread_onlysur1.-
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 le moteur de stockage InnoDB sur MySQL.
-
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.
Si vous décidez que vous pouvez ignorer une erreur en toute sécurité, vous pouvez suivre la procédure décrite dans la section Ignorer une erreur de réplication pour RDS for MySQL. Sinon, vous pouvez d'abord supprimer le réplica en lecture. Vous créez ensuite une instance à l'aide du même identifiant d'instance de base de données, de telle sorte que le point de terminaison demeure 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 prend la valeur replicating (réplication en cours).
