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.
# Utilisation de réplicas en lecture MariaDB
Ensuite, vous trouverez des informations spécifiques sur l'utilisation des réplicas en lecture sur Amazon RDS for MariaDB. 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 d'instance de base de données](USER_ReadRepl.md).
+ [Configuration des filtres de réplication avec MariaDB](USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.md)
+ [Configuration de la réplication différée avec MariaDB](USER_MariaDB.Replication.ReadReplicas.DelayReplication.md)
+ [Mise à jour des réplicas en lecture avec MariaDB](USER_MariaDB.Replication.ReadReplicas.Updates.md)
+ [Utiliser des déploiements de réplicas en lecture Multi-AZ avec MariaDB](USER_MariaDB.Replication.ReadReplicas.MultiAZ.md)
+ [Utilisation de réplicas en lecture en cascade avec RDS for MariaDB](USER_MariaDB.Replication.ReadReplicas.Cascading.md)
+ [Surveillance des réplicas en lecture MariaDB](USER_MariaDB.Replication.ReadReplicas.Monitor.md)
+ [Démarrage et arrêt de la réplication avec des réplicas en lecture MariaDB](USER_MariaDB.Replication.ReadReplicas.StartStop.md)
+ [Résolution d'un problème de réplica en lecture MariaDB](USER_ReadRepl.Troubleshooting.MariaDB.md)
## Configurer des réplicas en lecture avec MariaDB
Avant qu'une instance de base de données MariaDB puisse servir de source de réplication, assurez-vous d'activer les sauvegardes automatiques sur l'instance de base de données source en définissant la période de rétention des sauvegardes avec une valeur différente de 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.
Vous pouvez créer jusqu'à 15 réplicas en lecture à partir d'une seule instance de base de données au sein de la même région. 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.
RDS for MariaDB prend en charge les réplicas en lecture en cascade. Pour apprendre à configurer des réplicas en lecture en cascade, consultez [Utilisation de réplicas en lecture en cascade avec RDS for MariaDB](USER_MariaDB.Replication.ReadReplicas.Cascading.md).
Vous pouvez exécuter simultanément plusieurs actions de création et suppression de réplicas en lecture qui référencent la même instance de base de données source. Lorsque vous effectuez ces actions, restez dans la limite de 15 réplicas en lecture pour chaque instance source.
# Configuration des filtres de réplication avec MariaDB
Vous pouvez utiliser des filtres de réplication pour spécifier quelles bases de données et tables sont répliquées avec un réplica en lecture. Les filtres de réplication peuvent inclure des bases de données et des tables dans la réplication ou les en exclure.
Voici quelques cas d’utilisation pour les filtres de réplication :
+ Pour réduire la taille d’un réplica en lecture. Avec le filtrage de réplication, vous pouvez exclure les bases de données et les tables qui ne sont pas nécessaires sur le réplica en lecture.
+ Pour exclure des bases de données et des tables des réplicas en lecture, pour des raisons de sécurité.
+ Pour répliquer différentes bases de données et tables pour des cas d’utilisation spécifiques au niveau de différents réplicas en lecture. Par exemple, vous pouvez utiliser des réplicas en lecture spécifiques pour l’analyse ou le partage.
+ Pour une instance de base de données qui a des réplicas en lecture dans différentes Régions AWS, pour répliquer différentes bases de données ou tables dans différentes Régions AWS.
**Note**
Vous pouvez également utiliser des filtres de réplication pour spécifier quelles bases de données et tables sont répliquées avec une instance de base de données MariaDB principale configurée en tant que réplica dans une topologie de réplication entrante. Pour plus d’informations sur cette configuration, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
**Topics**
+ [Définition des paramètres de filtrage de la réplication pour RDS for MariaDB](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Configuring)
+ [Limites du filtrage de réplication pour RDS for MariaDB](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Limitations)
+ [Exemples de filtrage de réplication pour RDS for MariaDB](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Examples)
+ [Affichage des filtres de réplication pour un réplica en lecture](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Viewing)
## Définition des paramètres de filtrage de la réplication pour RDS for MariaDB
Pour configurer des filtres de réplication, définissez les paramètres de filtrage de réplication suivants sur le réplica en lecture :
+ `replicate-do-db` – Répliquer les modifications apportées aux bases de données spécifiées. Lorsque vous définissez ce paramètre pour un réplica en lecture, seules les bases de données spécifiées dans le paramètre sont répliquées.
+ `replicate-ignore-db` – Ne pas répliquer les modifications apportées aux bases de données spécifiées. Lorsque le paramètre `replicate-do-db` est défini pour un réplica en lecture, ce paramètre n’est pas évalué.
+ `replicate-do-table` – Répliquer les modifications apportées aux tables spécifiées. Lorsque vous définissez ce paramètre pour un réplica en lecture, seules les tables spécifiées dans le paramètre sont répliquées. En outre, lorsque le paramètre `replicate-do-db` ou `replicate-ignore-db` est défini, la base de données qui inclut les tables spécifiées doit être incluse dans la réplication avec le réplica en lecture.
+ `replicate-ignore-table` – Ne pas répliquer les modifications apportées aux tables spécifiées. Lorsque le paramètre `replicate-do-table` est défini pour un réplica en lecture, ce paramètre n’est pas évalué.
+ `replicate-wild-do-table` – Répliquer les tables en fonction des modèles de nom de base de données et nom de table spécifiés. Les caractères génériques `%` et `_` sont pris en charge. Lorsque le paramètre `replicate-do-db` ou `replicate-ignore-db` est défini, assurez-vous d’inclure la base de données qui comprend les tables spécifiées dans la réplication avec le réplica en lecture.
+ `replicate-wild-ignore-table` – Ne pas répliquer les tables en fonction des modèles de nom de base de données et de nom de table spécifiés. Les caractères génériques `%` et `_` sont pris en charge. Lorsque le paramètre `replicate-do-table` ou `replicate-wild-do-table` est défini pour un réplica en lecture, ce paramètre n’est pas évalué.
Les paramètres sont évalués dans l’ordre dans lequel ils sont répertoriés. Pour plus d'informations sur le fonctionnement de ces paramètres, consultez [la documentation de MariaDB](https://mariadb.com/kb/en/replication-filters/#replication-filters-for-replication-slaves).
Par défaut, chacun de ces paramètres a une valeur vide. Sur chaque réplica en lecture, vous pouvez utiliser ces paramètres pour définir, modifier et supprimer des filtres de réplication. Lorsque vous définissez l’un de ces paramètres, séparez chaque filtre des autres par une virgule.
Vous pouvez utiliser les caractères génériques `%` et `_` dans les paramètres `replicate-wild-do-table` et `replicate-wild-ignore-table`. Le caractère générique `%` correspond à un nombre quelconque de caractères, et le caractère générique `_` ne correspond qu’à un seul caractère.
Le format de journalisation binaire de l’instance de base de données source est important pour la réplication, car il détermine l’enregistrement des modifications de données. Le réglage du paramètre `binlog_format` détermine si la réplication est basée sur les lignes ou les instructions. Pour plus d’informations, consultez [Configuration de la journalisation binaire MariaDB](USER_LogAccess.MariaDB.BinaryFormat.md).
**Note**
Toutes les instructions DDL (Data Definition Language) sont répliquées en tant qu’instructions, quel que soit le paramètre `binlog_format` de l’instance de base de données source.
## Limites du filtrage de réplication pour RDS for MariaDB
Les limites suivantes s'appliquent au filtrage de réplication pour RDS for MariaDB :
+ Chaque paramètre de filtrage de réplication a une limite de 2 000 caractères.
+ Les virgules ne sont pas prises en charge dans les filtres de réplication.
+ Les options `binlog_do_db` et `binlog_ignore_db` de MariaDB pour le filtrage des journaux binaires ne sont pas prises en charge.
+ Le filtrage de réplication ne prend pas en charge les transactions XA.
Pour plus d’informations, consultez la section [Restrictions on XA Transactions](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) dans la documentation MySQL.
+ Le filtrage de réplication n'est pas pris en charge pour RDS for MariaDB versions 10.2.
## Exemples de filtrage de réplication pour RDS for MariaDB
Pour configurer le filtrage de réplication pour un réplica en lecture, modifiez les paramètres de filtrage de réplication dans le groupe de paramètres associé au réplica en lecture.
**Note**
Vous ne pouvez pas modifier un groupe de paramètres par défaut. Si le réplica en lecture utilise un groupe de paramètres par défaut, créez un nouveau groupe de paramètres et associez-le au réplica en lecture. Pour plus d’informations sur les groupes de paramètres de base de données, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Vous pouvez définir des paramètres dans un groupe de paramètres à l’aide de la console AWS Management Console, de la AWS CLI ou de l’API RDS. Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Lorsque vous définissez des paramètres dans un groupe de paramètres, toutes les instances de base de données associées au groupe de paramètres utilisent les réglages des paramètres. Si vous définissez les paramètres de filtrage de réplication dans un groupe de paramètres, assurez-vous que le groupe de paramètres est associé uniquement aux réplicas en lecture. Laissez les paramètres de filtrage de réplication vides pour les instances de base de données source.
Les exemples suivants définissent les paramètres à l’aide de la AWS CLI. Ces exemples définissent `ApplyMethod` sur `immediate` de sorte que les modifications de paramètre se produisent immédiatement après la fin de la commande de la CLI. Si vous souhaitez qu’une modification en attente soit appliquée après le redémarrage du réplica en lecture, définissez `ApplyMethod` sur `pending-reboot`.
Les exemples suivants définissent des filtres de réplication :
+ [Including databases in replication](#rep-filter-in-dbs-mariadb)
+ [Including tables in replication](#rep-filter-in-tables-mariadb)
+ [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-mariadb)
+ [Escaping wildcard characters in names](#rep-filter-escape-wildcards-mariadb)
+ [Excluding databases from replication](#rep-filter-ex-dbs-mariadb)
+ [Excluding tables from replication](#rep-filter-ex-tables-mariadb)
+ [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-mariadb)
**Example Inclusion de bases de données dans la réplication**
L’exemple suivant inclut les bases de données `mydb1` et `mydb2` dans la réplication. Lorsque vous définissez `replicate-do-db` pour un réplica en lecture, seules les bases de données spécifiées dans le paramètre sont répliquées.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
**Example Inclusion de tables dans la réplication**
L’exemple suivant inclut les tables `table1` et `table2` dans la base de données `mydb1` dans la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
**Example Inclusion de tables dans la réplication à l’aide de caractères génériques**
L’exemple suivant inclut des tables dont les noms commencent par `orders` et `returns` dans la base de données `mydb` dans la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
**Example Échappement de caractères génériques dans les noms**
L'exemple suivant montre comment utiliser le caractère d'échappement `\` pour échapper à un caractère générique faisant partie d'un nom.
Supposons que vous avez plusieurs noms de tables dans la base de données `mydb1` qui commencent par `my_table`, et que vous souhaitez inclure ces tables dans la réplication. Les noms de table incluent un trait de soulignement, qui est également un caractère générique, de sorte que l'exemple échappe le trait de soulignement dans les noms de table.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"
```
**Example Exclusion de bases de données de la réplication**
L’exemple suivant exclut les bases de données `mydb1` et `mydb2` de la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
**Example Exclusion de tables de la réplication**
L'exemple suivant exclut les tables `table1` et `table2` dans la base de données `mydb1` de la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
**Example Exclusion de tables de la réplication à l’aide des caractères génériques**
L’exemple suivant exclut de la réplication les tables dont les noms commencent par `orders` et `returns` dans la base de données `mydb`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
## Affichage des filtres de réplication pour un réplica en lecture
Vous pouvez afficher les filtres de réplication pour un réplica en lecture de la manière suivante :
+ Vérifiez les réglages des paramètres de filtrage de réplication dans le groupe de paramètres associé au réplica en lecture.
Pour obtenir des instructions, consultez [Affichage des valeurs de paramètres pour un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Viewing.md).
+ Dans un client MariaDB, connectez-vous au réplica en lecture et exécutez l'instruction `SHOW REPLICA STATUS`.
Dans la sortie, les champs suivants affichent les filtres de réplication pour le réplica en lecture :
+ `Replicate_Do_DB`
+ `Replicate_Ignore_DB`
+ `Replicate_Do_Table`
+ `Replicate_Ignore_Table`
+ `Replicate_Wild_Do_Table`
+ `Replicate_Wild_Ignore_Table`
Pour plus d’informations sur ces champs, consultez [Vérification du statut de la réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) dans la documentation MySQL.
**Note**
Les versions précédentes de MariaDB utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version de MariaDB antérieure à la version 10.5, utilisez `SHOW SLAVE STATUS`.
# Configuration de la réplication différée avec MariaDB
Vous pouvez utiliser la réplication retardée comme stratégie pour la reprise après sinistre. Avec la réplication retardée, vous spécifiez la durée minimale, en secondes, pour retarder la réplication de la source vers la réplique de 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.
Pour arrêter la réplication, utilisez la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication).
+ 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](USER_ReadRepl.Promote.md).
**Note**
La réplication différée est prise en charge pour MariaDB 10.6 et versions ultérieures.
Utilisez des procédures stockées pour configurer la réplication retardée. Vous ne pouvez pas configurer une réplication retardée avec l’AWS Management Console, l’AWS CLI ou l’API Amazon RDS.
Vous pouvez utiliser la réplication basée sur les identifiants de transaction globaux (GTID) dans une configuration de réplication différée.
**Topics**
+ [Configuration de la réplication retardée pendant la création du réplica en lecture](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.ReplicaCreation)
+ [Modification de la réplication retardée pour un réplica en lecture existant](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.ExistingReplica)
+ [Promotion d’un réplica en lecture](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.Promote)
## 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\$1set\$1configuration](mysql-stored-proc-configuring.md#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. En utilisant un client MariaDB, connectez-vous à l'instance de base de données MariaDB qui sera la source des répliques en lecture en tant qu'utilisateur principal.
1. Exécutez la procédure stockée [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#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\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay).
**Pour modifier la réplication retardée pour un réplica en lecture existant**
1. En utilisant un client MariaDB, connectez-vous au réplica en lecture en tant qu'utilisateur principal.
1. Utilisez la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) pour arrêter la réplication.
1. Exécutez la procédure stockée [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#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);
```
1. Utilisez la procédure stockée [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour lancer la réplication.
## Promotion d’un réplica en lecture
Après l’arrêt de la réplication, dans un scénario de reprise après sinistre, vous pouvez promouvoir un réplica en lecture comme nouvelle instance de base de données source. Pour en savoir plus sur la promotion d’un réplica en lecture, consultez [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
# Mise à jour des réplicas en lecture avec MariaDB
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. A titre d'exemple, vous pouvez avoir besoin d'ajouter un index, pour accélérer les types spécifiques de requêtes accédant 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.
# Utiliser des déploiements de réplicas en lecture Multi-AZ avec MariaDB
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 [Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS](Concepts.MultiAZ.md).
Vous pouvez 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.
# Utilisation de réplicas en lecture en cascade avec RDS for MariaDB
RDS for MariaDB prend en charge les réplicas en lecture en cascade. Les *réplicas en lecture en cascade* vous permettent de mettre à l'échelle les lectures sans surcharger votre instance de base de données RDS for MariaDB source.
Avec les réplicas en lecture en cascade, votre instance de base de données RDS for MariaDB envoie des données au premier réplica en lecture de la chaîne. Ce réplica en lecture envoie ensuite les données au deuxième réplica de la chaîne, etc. Au final, tous les réplicas en lecture de la chaîne ont reçu les modifications de l'instance de base de données RDS for MariaDB, sans surcharger uniquement l'instance de base de données source.
Vous pouvez créer une série comportant jusqu'à trois réplicas en lecture dans une chaîne à partir d'une instance de base de données RDS for MariaDB source. Par exemple, supposons que vous disposez d'une instance de base de données RDS for MariaDB, `mariadb-main`. Vous pouvez effectuer les actions suivantes :
+ À partir de `mariadb-main`, créez le premier réplica en lecture de la chaîne, `read-replica-1`.
+ Ensuite, à partir de `read-replica-1`, créez le réplica en lecture suivant dans la chaîne, `read-replica-2`.
+ Enfin, à partir de `read-replica-2`, créez le troisième réplica en lecture de la chaîne, `read-replica-3`.
Vous ne pouvez pas créer un autre réplica en lecture au-delà de ce troisième réplica en lecture en cascade dans la série pour `mariadb-main`. Une série complète d'instances allant d'une instance de base de données source RDS for MariaDB jusqu'à la fin d'une série de réplicas en lecture en cascade peut comporter au plus quatre instances de base de données.
Pour que les réplicas en lecture en cascade fonctionnent, les sauvegardes automatisées doivent être activées sur chaque instance de base de données RDS for MariaDB. Pour activer les sauvegardes automatiques sur un réplica en lecture, commencez par créer le réplica en lecture, puis modifiez-le pour activer les sauvegardes automatiques. Pour plus d’informations, consultez [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
Comme pour tout réplica en lecture, vous pouvez promouvoir un réplica en lecture faisant partie d’une cascade. La promotion d’un réplica en lecture depuis une chaîne de réplicas en lecture retire ce réplica de la chaîne. Par exemple, supposons que vous souhaitez déplacer une partie de la charge de travail de votre instance de base de données `mariadb-main` vers une nouvelle instance destinée uniquement au service comptable. En prenant pour hypothèse la chaîne de trois réplicas en lecture de l’exemple, vous décidez de promouvoir `read-replica-2`. La chaîne est affectée comme suit :
+ La promotion de `read-replica-2` le retire de la chaîne de réplication.
+ Il s’agit désormais d’une instance de base de données en lecture/écriture complète.
+ La réplication continue sur `read-replica-3`, tout comme avant la promotion.
+ Votre `mariadb-main` continue la réplication sur `read-replica-1`.
Pour plus d’informations sur la promotion des réplicas en lecture, consultez [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
# Surveillance des réplicas en lecture MariaDB
Pour les réplicas en lecture MariaDB, 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 REPLICA STATUS`.
**Note**
Les versions précédentes de MariaDB utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version de MariaDB antérieure à la version 10.5, utilisez `SHOW SLAVE STATUS`.
Les causes courantes du retard de réplication pour MariaDB sont les suivantes :
+ Une indisponibilité du réseau.
+ L’écriture dans des tables avec des index sur un réplica en lecture. Si le paramètre `read_only` n’a pas pour valeur 0 sur le réplica en lecture, il peut interrompre la réplication.
+ 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 MariaDB.
Lorsque la métrique `ReplicaLag` atteint 0, le réplica a rattrapé le retard sur l’instance de base 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 MariaDB
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\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#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 plus d’informations, consultez [Importation de données vers une instance de base de données Amazon RDS for MariaDB avec une durée d’indisponibilité réduite](mariadb-importing-data-reduced-downtime.md) et [Exportation de données à partir d'une instance DB MySQL grâce à la réplication](MySQL.Procedural.Exporting.NonRDSRepl.md).
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 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](http://mariadb.com/kb/en/mariadb/replication-overview/).
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](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) et [RDS-EVENT-0047](USER_Events.Messages.md#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](USER_Events.md). Si un message d'erreur MariaDB est retourné, consultez l'erreur dans la [documentation sur les messages d'erreur MariaDB](http://mariadb.com/kb/en/mariadb/mariadb-error-codes/).
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\$1allowed\$1packet' 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](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html).
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](Appendix.MySQL.CommonDBATasks.SkipError.md). 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.