Limites et considérations relatives aux clusters actifs-actifs

Le nom d’utilisateur principal ne peut pas être rdsgrprepladmin pour les instances de base de données d’un cluster actif-actif. Ce nom d’utilisateur est réservé aux connexions de réplication de groupe.

Pour les instances de base de données avec des réplicas en lecture dans des clusters actifs-actifs, un état de réplication prolongé autre que Replicating peut entraîner le dépassement des limites de stockage des fichiers journaux. Pour en savoir plus sur le statut des réplicas en lecture, consultez Supervision de la réplication en lecture.

Les déploiements bleu/vert ne sont pas pris en charge pour les instances de base de données au sein d’un cluster actif-actif. Pour plus d’informations, consultez Utilisation des déploiements bleu/vert Amazon RDS pour les mises à jour de base de données.

L’authentification Kerberos n’est pas prise en charge pour les instances de base de données d’un cluster actif-actif. Pour plus d’informations, consultez Utilisation de l’authentification Kerberos pour Amazon RDS for MySQL.

Les instances de base de données d’un cluster de bases de données multi-AZ ne peuvent pas être ajoutées à un cluster actif-actif. Toutefois, les instances de base de données d’un déploiement d’instance de base de données multi-AZ peuvent être ajoutées à un cluster actif-actif. Pour plus d’informations, consultez Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS.

Les tables dépourvues de clé primaire ne sont pas répliquées dans un cluster actif-actif, car les écritures sont rejetées par le plug-in Réplication de groupe.

Les tables non-InnoDB ne sont pas répliquées dans un cluster actif-actif.

Les clusters actifs-actifs ne prennent pas en charge les instructions DML et DDL simultanées sur les différentes instances de base de données du cluster.

Vous ne pouvez pas configurer un cluster actif-actif afin d’utiliser le mode primaire unique pour le mode de réplication du groupe. Pour cette configuration, nous vous recommandons d’utiliser plutôt un cluster de bases de données multi-AZ. Pour plus d’informations, consultez Déploiements de cluster de bases de données multi-AZ pour Amazon RDS.

La réplication multisource n’est pas prise en charge pour les instances de base de données d’un cluster actif-actif.

Un cluster actif-actif entre régions ne peut pas appliquer la vérification de l’autorité de certification (CA) pour les connexions de réplication de groupe.

Les clusters actifs-actifs ne peuvent pas contenir plus de neuf instances de base de données.

Avec le plug-in Réplication de groupe, vous pouvez contrôler les garanties de cohérence des transactions du cluster actif-actif. Pour plus d’informations, consultez Garanties de cohérence des transactions dans la documentation MySQL.

Des conflits sont possibles lorsque différentes instances de base de données mettent à jour la même ligne dans un cluster actif-actif. Pour en savoir plus sur les conflits et leur résolution, consultez Réplication de groupe dans la documentation MySQL.

Pour la tolérance aux pannes, ajoutez au moins trois instances de base de données dans votre cluster actif-actif. Il est possible de configurer un cluster actif-actif avec une ou deux instances de base de données uniquement, mais le cluster ne tolérera pas les pannes. Pour en savoir plus sur la tolérance aux pannes, consultez Tolérance aux pannes dans la documentation MySQL.

Lorsqu’une instance de base de données rejoint un cluster actif-actif existant et exécute la même version de moteur que la version la plus basse du cluster, l’instance de base de données le rejoint en mode lecture-écriture.

Lorsqu’une instance de base de données rejoint un cluster actif-actif existant et exécute une version de moteur supérieure à la version la plus basse du cluster, l’instance de base de données doit rester en mode lecture seule.

Si vous activez la réplication de groupe pour une instance de base de données en définissant son paramètre rds.group_replication_enabled sur 1 dans le groupe de paramètres de base de données, mais que la réplication n’a pas démarré ou n’a pas pu démarrer, l’instance de base de données est placée en mode super lecture seule pour éviter les incohérences dans les données. Pour en savoir plus sur le mode super lecture seule, consultez la documentation MySQL.

Vous pouvez mettre à niveau une instance de base de données dans un cluster actif-actif, mais elle est en lecture seule jusqu’à ce que toutes les autres instances de base de données du cluster actif-actif soient mises à niveau vers une version du moteur identique ou supérieure. Lorsque vous mettez à niveau une instance de base de données, celle-ci rejoint automatiquement le même cluster actif-actif une fois la mise à niveau terminée. Afin d’éviter un passage involontaire en mode lecture seule pour une instance de base de données, désactivez les mises à niveau automatiques des versions mineures pour celle-ci. Pour en savoir plus sur la mise à niveau d’une instance de base de données MySQL, consultez Mises à niveau du moteur de base de données RDS for MySQL.

Vous pouvez ajouter une instance de base de données dans un déploiement d’instance de base de données multi-AZ à un cluster actif-actif existant. Vous pouvez également convertir une instance de base de données mono-AZ d’un cluster actif-actif en déploiement d’instance de base de données multi-AZ. Si une instance de base de données principale échoue dans un déploiement multi-AZ, cette instance principale bascule vers l’instance de secours. La nouvelle instance de base de données principale rejoint automatiquement le même cluster une fois le basculement terminé. Pour plus d’informations sur les déploiements d’instance de base de données multi-AZ, consultez Déploiements de l’instance de base de données multi-AZ pour Amazon RDS.

Nous recommandons des plages de temps différentes pour les fenêtres de maintenance des instances de base de données d’un cluster actif-actif. Cette pratique évite la mise hors ligne simultanée de plusieurs instances de base de données du cluster pour des raisons de maintenance. Pour plus d’informations, consultez Fenêtre de maintenance Amazon RDS.

Les clusters actifs-actifs peuvent utiliser SSL pour les connexions entre les instances de base de données. Pour configurer les connexions SSL, définissez les paramètres group_replication_recovery_use_ssl et group_replication_ssl_mode. Les valeurs de ces paramètres doivent correspondre à toutes les instances de base de données du cluster actif-actif.

Actuellement, les clusters actifs-actifs ne prennent pas en charge la vérification par l’autorité de certification (CA) pour les connexions entre des Régions AWS. Le paramètre group_replication_ssl_mode doit donc être défini sur DISABLED (valeur par défaut) ou sur REQUIRED pour les clusters entre régions.

Un cluster actif-actif RDS for MySQL s’exécute en mode multi-primaire. La valeur par défaut de group_replication_enforce_update_everywhere_checks est ON et le paramètre est statique. Lorsque ce paramètre est défini sur ON, les applications ne peuvent pas l’insérer dans une table soumise à des contraintes de clé étrangère en cascade.

Un cluster actif-actif RDS for MySQL utilise la pile de communication MySQL pour la sécurité des connexions au lieu de XCOM. Pour plus d’informations, consultez Pile de communication pour la gestion de la sécurité des connexions dans la documentation MySQL.

Lorsqu’un groupe de paramètres de base de données est associé à une instance de base de données dans un cluster actif-actif, nous recommandons de n’associer ce groupe qu’aux autres instances de base de données présentes dans le cluster.

Les clusters actifs-actifs prennent en charge uniquement les instances de base de données RDS for MySQL. Ces instances de base de données doivent exécuter des versions prises en charge du moteur de base de données.

Lorsqu’une instance de base de données d’un cluster actif-actif subit une défaillance inattendue, RDS démarre automatiquement la récupération de l’instance de base de données. Si la récupération de l’instance de base de données échoue, nous vous recommandons de la remplacer par une nouvelle, en effectuant une reprise ponctuelle avec une instance de base de données saine dans le cluster. Pour obtenir des instructions, consultez Ajout d’une instance de base de données à un cluster actif-actif à l’aide de la reprise ponctuelle.

Vous pouvez supprimer une instance de base de données d’un cluster actif-actif sans affecter les autres instances de base de données du cluster. Pour en savoir plus sur la suppression d’une instance de base de données, consultez Suppression d'une instance DB.

Lorsqu’une instance de base de données quitte involontairement un cluster actif-actif, le paramètre group_replication_exit_state_action passe par défaut à OFFLINE_MODE. Dans cet état, l’instance de base de données est inaccessible et vous devez la redémarrer pour qu’elle se remette en ligne et rejoigne le cluster. Vous pouvez changer ce comportement en modifiant le paramètre group_replication_exit_state_action dans un groupe de paramètres personnalisés. En définissant le paramètre sur READ_ONLY, lorsque l’instance de base de données quitte involontairement un cluster, elle passe en mode super lecture seule au lieu d’être mise hors ligne.