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. 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 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é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 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 Utiliser la notification d'événements d'Amazon RDS. 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 paramètre max_allowed_packet est un paramètre personnalisé que vous pouvez définir dans un groupe de paramètres DB utilisé 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 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.

  • Lorsqu'elles utilisent 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 MariaDB.

  • 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 Ignorer une erreur de réplication pour RDS for MySQL. 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.