Résolution d'un problème de réplica en lecture MariaDB - Amazon Relational Database Service

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 MariaDB

Les technologies de réplication pour MariaDB 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'E/S, 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 MariaDB, consultez Présentation 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 passer en revue les détails de l'erreur associée et déclenchée par le moteur MariaDB, 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 Utilisation des notifications d'RDSévénements Amazon. Si un message d'erreur MariaDB est retourné, consultez l'erreur dans la documentation sur les messages d'erreur MariaDB.

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 max_allowed_packet paramètre est un paramètre personnalisé que vous pouvez définir dans un groupe de paramètres de base de données utilisé pour spécifier la taille maximale du DML code pouvant être exécuté sur la base de données. Dans certains cas, la valeur du paramètre max_allowed_packet dans le groupe de paramètres de base de données associé à une instance de base de données source est inférieure à la valeur du paramètre max_allowed_packet dans le groupe de paramètres de base de données associé au réplica en lecture de la source. Le processus de réplication peut alors générer une erreur (Packet bigger than 'max_allowed_packet' bytes) et arrêter la réplication. 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.

Voici d'autres situations courantes susceptibles de causer des erreurs de réplication :

  • É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.

  • L'utilisation d'un moteur de stockage non transactionnel tel que les répliques ISAM My. read nécessite un moteur de stockage transactionnel. La réplication est uniquement prise en charge pour le moteur de stockage InnoDB sur MariaDB.

  • 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 Ignorer l'erreur de réplication actuelle pour RDS for My SQL. Dans le cas contraire, 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 de sorte que 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 prend la valeur replicating (réplication en cours).

Pour les instances de base de données MariaDB, dans certains cas, les réplicas en lecture ne peuvent pas être basculés vers l'instance secondaire si des événements de journaux binaires (binlog) ne sont pas vidés au cours de la panne. 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.