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 lié à SQL la réplique My read
Pour les instances My SQL DB, dans certains cas, les répliques en lecture présentent des erreurs de réplication ou des incohérences de données (ou les deux) entre la réplique 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 My SQL sont asynchrones. Par conséquent, des augmentations 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épliques en lecture seule dans ma SQL documentation, consultez la section Détails de l'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épliques de lecture et met à jour le Replication State champ de l'instance de réplication de lecture en Error cas d'arrêt de la réplication pour une quelconque raison. Par exemple, si les DML requêtes exécutées sur votre réplique de lecture entrent en conflit avec les mises à jour effectuées sur l'instance de base de données source.
Vous pouvez consulter les détails de l'erreur associée générée par le SQL moteur My en consultant le Replication Error champ. Des événements indiquant l'état du réplica en lecture sont également générés, y compris RDS-EVENT-0045, RDS-EVENT-0046 et RDS-EVENT-0047. Pour plus d'informations sur les événements et l'abonnement aux événements, consultez Utilisation des notifications d'RDSévénements Amazon. Si un message Mon SQL erreur est renvoyé, consultez le numéro d'erreur dans la documentation Mon message SQL d'erreur
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 l'utilisez max_allowed_packet pour spécifier la taille maximale du DML code pouvant ê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.-
En utilisant un moteur de stockage non transactionnel tel que My. ISAM Les réplicas en lecture nécessitent un moteur de stockage transactionnel. La réplication n'est prise en charge que pour le moteur de stockage InnoDB sur My. SQL
-
Utilisation de requêtes non déterministes non sécurisées telles que
SYSDATE(). Pour de plus amples 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 l'erreur de réplication actuelle pour RDS for My SQL. 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).
