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éplication de clusters de bases de données Amazon Aurora MySQL sur Régions AWS
Vous pouvez créer un cluster de base de données Amazon Aurora MySQL sous forme de réplique en lecture dans un cluster de base de données Région AWS différent du cluster de base de données source. Cette approche peut améliorer vos capacités de reprise après sinistre, vous permettre d'adapter les opérations de lecture à un Région AWS niveau plus proche de vos utilisateurs et de faciliter la migration de l'une Région AWS à l'autre.
Vous pouvez créer des réplicas en lecture pour les clusters de bases de données chiffrés et non chiffrés. Le réplica en lecture doit être chiffré si le cluster de bases de données source est chiffré.
Pour chaque cluster de bases de données source, vous pouvez avoir jusqu'à cinq clusters de bases de données entre régions qui sont des réplicas en lecture.
Note
Comme alternative aux réplicas en lecture entre régions, vous pouvez mettre à l'échelle les opérations de lecture avec un temps de latence minimal à l'aide d'une base de données Aurora globale. Une base de données globale Aurora possède un cluster de base de données Aurora principal dans un Région AWS et jusqu'à 10 clusters de base de données secondaires en lecture seule dans différentes régions. Chaque cluster de bases de données secondaire peut inclure jusqu'à 16 réplicas Aurora (plutôt que 15). La réplication du cluster de base de données primaire vers tous les clusters secondaires est gérée par la couche de stockage Aurora plutôt que par le moteur de base de données. Ainsi, le temps de latence de réplication des modifications est minime (généralement inférieur à 1 seconde). Exclure le moteur de base de données du processus de réplication permet de le dédier au traitement des charges de travail. En outre, vous n'avez pas besoin de configurer ou de gérer la réplication binlog (journalisation binaire) d'Aurora MySQL. Pour en savoir plus, veuillez consulter la section Utilisation de la base de données mondiale Amazon Aurora.
Lorsque vous créez une réplique en lecture d'un cluster de bases de données Aurora MySQL dans un autre Région AWS, vous devez tenir compte des points suivants :
-
Votre cluster de bases de données source et votre cluster de bases de données de réplica en lecture entre régions peuvent avoir jusqu'à 15 réplicas Aurora, avec l'instance principale du cluster de bases de données. Grâce à cette fonctionnalité, vous pouvez dimensionner les opérations de lecture à la fois pour votre source Région AWS et pour votre cible de réplication Région AWS.
-
Dans un scénario entre régions, le retard entre le cluster de bases de données source et le réplica en lecture est plus important du fait que les canaux de réseau entre les Régions AWS sont plus longs.
-
Les données transférées pour la réplication entre régions génèrent des frais de transfert de données Amazon RDS. Les actions de réplication entre régions suivantes génèrent des frais pour les données transférées hors de la Région AWS source :
-
Lorsque vous créez la réplique en lecture, Amazon RDS prend un instantané du cluster source et le transfère vers Région AWS celui qui contient le réplica en lecture.
-
Pour chaque modification de données effectuée dans les bases de données sources, Amazon RDS transfère les données de la région source vers Région AWS celle qui contient la réplique lue.
Pour plus d'informations sur la tarification du transfert de données Amazon RDS, consultez Tarification Amazon Aurora
. -
-
Vous pouvez exécuter plusieurs actions de création ou de suppression simultanées pour les réplicas en lecture qui référencent le même cluster de bases de données source. Vous devez toutefois rester dans la limite de cinq réplicas en lecture pour chaque cluster de bases de données source.
-
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 le cluster de bases de données source. Si vous mettez à l'échelle le cluster de bases de données source, vous devez également le faire pour les réplicas en lecture.
Rubriques
Avant de commencer
Pour pouvoir créer un cluster de bases de données Aurora MySQL en tant que réplica en lecture entre régions, vous devez commencer par activer la journalisation binaire sur votre cluster de bases de données Aurora MySQL source. La réplication entre régions pour Aurora MySQL utilise la réplication binaire MySQL pour relire les modifications apportées au cluster de bases de données du réplica en lecture entre régions.
Pour activer la journalisation binaire sur un cluster de bases de données Aurora MySQL, mettez à jour le paramètre binlog_format de votre cluster de bases de données source. Le paramètre binlog_format est un paramètre de niveau cluster qui figure dans le groupe de paramètres de cluster par défaut. Si votre cluster de bases de données utilise le groupe de paramètres de cluster de bases de données par défaut, créez un nouveau groupe de paramètres de cluster de bases de données pour modifier les paramètres binlog_format. Nous vous recommandons de définir le binlog_format sur MIXED. Cependant, vous pouvez également définir binlog_format sur ROW ou STATEMENT si vous avez besoin d'un format binlog spécifique. Redémarrez votre cluster de bases de données Aurora pour que les modifications prennent effet.
Pour plus d'informations sur l'utilisation de la journalisation binaire Aurora, consultez Réplication entre Aurora et My SQL ou entre Aurora et un autre cluster de base de données Aurora (réplication de journaux binaires). Pour plus d'informations sur la modification des paramètres de configuration de Aurora MySQL, consultez Paramètres de cluster de base de données et d'instance de base de données Amazon Aurora et Groupes de paramètres pour Amazon Aurora ().
