Utilisation de réplicas en lecture MySQL - Amazon Relational Database Service

Utilisation de réplicas en lecture MySQL

Cette section contient des informations spécifiques sur l'utilisation des réplicas en lecture dans Amazon RDS MySQL. Pour obtenir des informations générales sur les réplicas en lecture et des instructions pour les utiliser, veuillez consulter Utilisation des réplicas en lecture.

Configuration de réplicas en lecture avec MySQL

Avant qu'une instance de base de données MySQL puisse être utilisée comme source de réplication, vous devez activer les sauvegardes automatiques sur l'instance de base de données source. Pour cela, vous devez définir la période de rétention des sauvegardes sur une valeur autre que 0. Cette exigence s'applique également à un réplica en lecture qui serait l'instance de base de données source d'un autre réplica en lecture. Les sauvegardes automatiques sont prises en charge uniquement pour les réplicas en lecture exécutant une version de MySQL 5.6 ou une version ultérieure. Vous pouvez configurer la réplication en fonction des coordonnées des journaux binaires pour une instance de base de données MySQL.

Dans Amazon RDS MySQL 5.7.23 et les versions MySQL 5.7 ultérieures, vous pouvez configurer la réplication avec des identifiants de transaction globaux (GTID). Pour plus d'informations, consultez Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID) pour Amazon RDS MySQL.

Vous pouvez créer jusqu'à cinq réplicas en lecture à partir d'une seule instance de base de données. Pour que la réplication fonctionne de façon efficace, chaque réplica en lecture doit avoir la même quantité de ressources de calcul et de stockage que l'instance de base de données source. Si vous mettez à l'échelle l'instance de base de données source, faites-le également pour les réplicas en lecture.

Si un réplica en lecture exécute une version de MySQL 5.6 ou ultérieure, vous pouvez la spécifier comme instance de base de données source pour un autre réplica en lecture. Par exemple, vous pouvez créer ReadReplica1 from MyDBInstance, puis ReadReplica2 à partir de ReadReplica1. Les mises à jour effectuées sur InstanceDB sont répliquées sur ReplicaEnLecture1 puis répliquées de ReplicaEnLecture1 vers ReplicaEnLecture2. Vous ne pouvez pas avoir plus de quatre instances impliquées dans une chaîne de réplication. Par exemple, vous pouvez créer ReadReplica1 à partir de MySourceDBInstance, ReadReplica2 à partir de ReadReplica1, puis ReadReplica3 à partir de ReadReplica2, mais vous ne pouvez pas créer ReadReplica4 à partir de ReadReplica3.

Si vous procédez à la promotion d'un réplica en lecture MySQL qui réplique à son tour vers d'autres réplicas en lecture, ces réplicas en lecture restent actifs. Considérez un exemple dans lequel InstanceDB1 réplique vers InstanceDB2, et InstanceDB2 réplique vers InstanceDB3. Si vous promouvez InstanceDB2, la réplication d'InstanceDB1 vers InstanceDB2 n'intervient plus, mais InstanceDB2 continue à répliquer vers InstanceDB3.

Pour activer les sauvegardes automatiques sur un réplica en lecture pour Amazon RDS MySQL version 5.6 ou ultérieure, commencez par créer le réplica en lecture. Modifiez ensuite le réplica en lecture pour activer les sauvegardes automatiques.

Vous pouvez exécuter plusieurs actions de création ou de suppression simultanées pour les réplicas en lecture qui référencent la même instance de base de données source. Pour cela, restez dans la limite de cinq réplicas en lecture pour chaque instance source.

Un réplica en lecture d'une instance de base de données MySQL ne peut pas utiliser une version de moteur de base de données inférieure à son instance de base de données source.

Préparation des instances de base de données MySQL qui utilisent MyISAM

Si votre instance de base de données MySQL utilise un moteur non transactionnel tel que MyISAM, vous devez effectuer les étapes suivantes pour configurer correctement votre réplica en lecture. Ces étapes sont nécessaires pour vous assurer que le réplica en lecture dispose d'une copie cohérente de vos données. Ces étapes ne sont pas nécessaires si toutes vos tables utilisent un moteur transactionnel comme InnoDB.

  1. Arrêtez toutes les opérations DML (Data Manipulation Language) et DDL (Data Definition Language) sur les tables non transactionnelles dans l'instance de bases de données source et attendez qu'elles se terminent. Les instructions SELECT peuvent continuer à fonctionner.

  2. Videz et verrouillez les tables dans l'instance de bases de données source.

  3. Créez le réplica en lecture en suivant l'une des méthodes présentées dans les sections suivantes.

  4. Vérifiez l'avancement de la création du réplica en lecture en utilisant, par exemple, l'opération d'API DescribeDBInstances. Une fois que le réplica en lecture est disponible, déverrouillez les tables de l'instance de base de données source et reprenez les opérations de base de données normales.

Configuration de la réplication retardée avec MySQL

Vous pouvez utiliser la réplication retardée comme stratégie pour la reprise après sinistre. Grâce à elle, vous spécifiez le temps minimal, en secondes, à utiliser pour retarder la réplication à partir de la base de données principale vers le réplica en lecture. En cas de sinistre, par exemple la suppression accidentelle d'une table, vous appliquez la procédure suivante pour reprendre rapidement après le sinistre :

  • Arrêtez la réplication vers le réplica en lecture avant que lui soit envoyée la modification qui a provoqué le sinistre.

    Utilisez la procédure stockée mysql.rds_stop_replication pour arrêter la réplication.

  • Arrêtez la réplication et précisez qu'elle doit s'arrêter automatiquement à une position donnée dans un fichier journal.

    Vous indiquez une position juste avant le sinistre grâce à la procédure stockée mysql.rds_start_replication_until.

  • Effectuez la promotion du réplica en lecture pour qu'il devienne la nouvelle instance de base de données source, en suivant les instructions figurant dans Promotion d'un réplica en lecture en instance de bases de données autonome.

Note
  • Dans Amazon RDS MySQL 5.7, la réplication retardée est prise en charge pour MySQL 5.7.22 et versions ultérieures. Dans Amazon RDS MySQL 5.6, la réplication retardée est prise en charge pour MySQL 5.6.40 et versions ultérieures. La réplication retardée n'est pas prise en charge dans Amazon RDS MySQL 8.0.

  • Utilisez des procédures stockées pour configurer la réplication retardée. Vous ne pouvez pas configurer la réplication retardée avec la AWS Management Console, l'AWS CLI ou l'API Amazon RDS.

  • Dans Amazon RDS MySQL 5.7.23 et les versions MySQL 5.7 ultérieures, vous pouvez utiliser une réplication basée sur des identifiants de transaction globaux (GTID) dans une configuration de réplication retardée. Si vous utilisez une réplication basée sur des identifiants de transaction globaux (GTID), utilisez la procédure stockée mysql.rds_start_replication_until_gtid au lieu de la procédure stockée mysql.rds_start_replication_until. Pour en savoir plus sur les réplications basées sur des identifiants de transaction globaux (GTID), consultez Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID) pour Amazon RDS MySQL.

Configuration de la réplication retardée pendant la création du réplica en lecture

Pour configurer la réplication retardée pour tout réplica en lecture à venir créé à partir d'une instance de base de données, exécutez la procédure stockée mysql.rds_set_configuration avec le paramètre target delay.

Pour configurer la réplication retardée pendant la création du réplica en lecture

  1. À l'aide d'un client MySQL, connectez-vous à l'instance de base de données MySQL qui constituera la source des réplicas en lecture en tant qu'utilisateur principal.

  2. Exécutez la procédure stockée mysql.rds_set_configuration avec le paramètre target delay.

    Par exemple, exécutez la procédure stockée suivante pour indiquer que la réplication est retardée d'au moins une heure (3 600 secondes) pour tout réplica en lecture créé à partir de l'instance de base de données actuelle.

    call mysql.rds_set_configuration('target delay', 3600);
    Note

    Une fois cette procédure stockée exécutée, tout réplica en lecture que vous créez en utilisant l'AWS CLI ou l'API Amazon RDS est configuré avec la réplication retardée du nombre de secondes spécifié.

Modification de la réplication retardée pour un réplica en lecture existant

Pour modifier la réplication retardée pour un réplica en lecture existant, exécutez la procédure stockée mysql.rds_set_source_delay.

Pour modifier la réplication retardée pour un réplica en lecture existant

  1. En utilisant un client MySQL, connectez-vous au réplica en lecture en tant qu'utilisateur principal.

  2. Utilisez la procédure stockée mysql.rds_stop_replication pour arrêter la réplication.

  3. Exécutez la procédure stockée mysql.rds_set_source_delay.

    Par exemple, exécutez la procédure stockée suivante pour indiquer que la réplication vers le réplica en lecture est retardée d'au moins une heure (3 600 secondes).

    call mysql.rds_set_source_delay(3600);
  4. Utilisez la procédure stockée mysql.rds_start_replication pour lancer la réplication.

Définition d'une position où arrêter la réplication vers un réplica en lecture

Après avoir arrêté la réplication vers le réplica en lecture, vous pouvez démarrer la réplication, puis l'arrêter à la position spécifiée dans le fichier journal binaire en utilisant la procédure stockée mysql.rds_start_replication_until.

Pour démarrer la réplication vers un réplica en lecture et l'arrêter à une position donnée

  1. En utilisant un client MySQL, connectez-vous à l'instance de base de données MySQL source en tant qu'utilisateur principal.

  2. Exécutez la procédure stockée mysql.rds_start_replication_until.

    L'exemple suivant lance la réplication et réplique les modifications jusqu'à ce qu'il atteigne la position 120 dans le fichier journal binaire mysql-bin-changelog.000777. Dans un scénario de reprise après sinistre, nous supposons que cette position 120 est juste avant le sinistre.

    call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120);

La réplication s'arrête automatiquement lorsque le point d'arrêt est atteint. L'événement RDS suivant est généré : Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure

Une fois la réplication arrêtée, dans un scénario de reprise après sinistre, vous pouvez Promotion d'un réplica en lecture en instance de bases de données autonome promouvoir le réplica en lecture pour qu'il devienne la nouvelle instance de base de données source. Pour de plus amples informations sur la promotion du réplica en lecture, veuillez consulter Promotion d'un réplica en lecture en instance de bases de données autonome.

Mises à jour de réplicas en lecture avec MySQL

Les réplicas en lecture sont conçus pour prendre en charge les requêtes de lecture, mais vous pouvez avoir besoin de mises à jour ponctuelles. À titre d'exemple, vous pouvez avoir besoin d'ajouter un index, pour optimiser les types spécifiques de requêtes qui accèdent au réplica. Vous pouvez autoriser les mises à jour en affectant au paramètre read_only la valeur 0 dans le groupe de paramètres de base de données pour le réplica en lecture. Soyez prudent lors de la désactivation de la lecture seule sur un réplica en lecture car cela peut poser des problèmes si le réplica en lecture devient incompatible avec l'instance de base de données source. Remplacez la valeur du paramètre read_only par 1 dès que possible.

Déploiements multi-AZ de réplicas en lecture avec MySQL

Vous pouvez créer un réplica en lecture à partir de déploiements d'instance de base de données mono-AZ ou multi-AZ. Vous utilisez des déploiements multi-AZ pour améliorer la durabilité et la disponibilité des données critiques, mais vous ne pouvez pas utiliser une instance secondaire multi-AZ pour servir les requêtes en lecture seule. À la place, vous pouvez créer des réplicas en lecture à partir d'instances de base de données multi-AZ à trafic élevé pour décharger les requêtes en lecture seule. Si l'instance source d'un déploiement multi-AZ bascule vers l'instance secondaire, tous les réplicas en lecture associés se mettent automatiquement à utiliser l'instance secondaire (désormais principale) comme source de réplication. Pour plus d'informations, consultez Haute disponibilité (multi-AZ) pour Amazon RDS.

Vous pouvez désormais créer un réplica en lecture en tant qu'instance de base de données multi-AZ. Amazon RDS crée une instance de secours de votre réplica dans une autre zone de disponibilité pour la prise en charge du basculement pour le réplica. La création de votre réplica en lecture en tant qu'instance de base de données multi-AZ est indépendante du fait que la base de données source soit ou non une instance de base de données multi-AZ.

Note

Pour créer un réplica en lecture en tant qu'instance de base de données multi-AZ, l'instance de base de données doit être MySQL 5.6 ou une version ultérieure.

Surveillance des réplicas en lecture MySQL

Pour les réplicas en lecture MySQL, vous pouvez surveiller le retard de réplication dans Amazon CloudWatch en consultant la métrique Amazon RDS ReplicaLag. La métrique ReplicaLag contient la valeur du champ Seconds_Behind_Master de la commande SHOW SLAVE STATUS.

Les causes courantes du retard de réplication pour MySQL sont les suivantes :

  • Une indisponibilité du réseau.

  • L'écriture dans des tables avec des index différents sur un réplica en lecture. Si le paramètre read_only est défini sur 0 sur le réplica en lecture, la réplication peut être rompue 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ètre read_only sur 1.

  • Utilisation d'un moteur de stockage non transactionnel tel que MyISAM. La réplication est uniquement prise en charge pour le moteur de stockage InnoDB sur MySQL.

Lorsque la métrique ReplicaLag atteint 0, le réplica a rattrapé l'instance de bases de données source. Si la métrique ReplicaLag retourne -1, la réplication n'est actuellement pas active. ReplicaLag= -1 est équivalent à Seconds_Behind_Master = NULL.

Démarrage et arrêt de la réplication avec des réplicas en lecture MySQL

Vous pouvez arrêter et redémarrer le processus de réplication sur une instance de base de données Amazon RDS en appelant les procédures stockées système mysql.rds_stop_replication et mysql.rds_start_replication. Vous pouvez procéder ainsi lors d'une réplication entre deux instances Amazon RDS pour des opérations de longue durée, telles que la création d'un grand index. Vous devez également arrêter et démarrer la réplication lors de l'importation ou de l'exportation de bases de données. Pour de plus amples informations, veuillez consulter Importation de données vers une instance de base de données MySQL ou MariaDB Amazon RDS avec un temps réduit et Exportation de données à partir d'une instance DB MySQL grâce à la réplication.

Si la réplication est arrêtée pendant plus de 30 jours consécutifs, manuellement ou en raison d'une erreur de réplication, Amazon RDS met fin à la réplication entre l'instance de base de données source et tous les réplicas en lecture. Cela permet d'éviter l'augmentation des besoins en stockage sur l'instance de bases de données source et d'importants délais de basculement. L'instance de base de données du réplica en lecture est toujours disponible. En revanche, la réplication ne peut pas être reprise, car les journaux binaires requis par le réplica en lecture sont supprimés de l'instance de base de données source une fois la réplication terminée. Vous pouvez créer un nouveau réplica en lecture pour l'instance de base de données source afin de rétablir la réplication.

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 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 dans MySQL 5.5 en définissant les variables dynamiques suivantes : sync_binlog=1, innodb_flush_log_at_trx_commit=1 et innodb_support_xa=1. Ces paramètres peuvent réduire les performances. Testez donc leur impact avant d'implémenter les modifications dans un environnement de production. Pour MySQL 5.5, sync_binlog utilise la valeur 0 par défaut, mais dans MySQL 5.6 et les versions ultérieures, ces problèmes se produisent moins souvent dans la mesure où ces paramètres sont tous définis sur les valeurs recommandées par défaut.

Les technologies de réplication pour MySQL 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 de plus amples informations sur les réplicas en lecture seule dans la documentation MySQL, veuillez consulter 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 Utilisation de la notification d'événement 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_only 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 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ètre read_only sur 1.

  • 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 de plus amples informations, veuillez consulter Détermination d'instructions sécurisées et non sécurisées dans la journalisation binaire.

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