FAQ sur Amazon RDS for MySQL

Amazon Relational Database (Amazon RDS) for MySQL prend actuellement en charge les versions 8.4 et 8.0 de MySQL Community Edition. RDS pour MySQL prend également en charge MySQL 5.7 dans le cadre du support étendu RDS. Pour en savoir plus sur les versions mineures prises en charge, reportez-vous au Guide de l’utilisateur Amazon RDS.

Dans le contexte de MySQL, les numéros de versions sont organisés comme suit :
MySQL version = X.Y.Z

X = Version majeure, Y = Niveau de mise à jour, Z = Numéro de version dans la série de mise à jour.
Du point de vue d'Amazon RDS, un changement de version serait considéré comme étant majeur si la version majeure ou le niveau de mise à jour est modifié. Exemple : passer de 5.6.X -> 5.7.X.

Un changement de version serait considéré comme étant mineur si le numéro de version dans la mise à jour est modifié. Exemple : passer de 5.6.27 à 5.6.29.

Oui. Consultez les Questions fréquentes (FAQ) sur Amazon RDS.

Les fonctionnalités de restauration à un instant dans le passé, de restauration d'instantanés et d'intégration zéro ETL avec Amazon Redshift d'Amazon RDS for MySQL nécessitent un moteur de stockage tolérant au plantage. Elles ne sont prises en charge que pour le moteur de stockage InnoDB. Même si MySQL prend en charge plusieurs moteurs de stockage avec diverses capacités, toutes ne sont pas optimisées pour la récupération de plantage et la durabilité des données. Par exemple, le moteur de stockage MyISAM ne prend pas en charge une récupération de plantage fiable et peut causer une perte ou une corruption des données quand MySQL est redémarré après un plantage, empêchant la restauration à un instant dans le passé et la restauration d'instantané de fonctionner comme espéré. Cependant, si vous choisissez d'utiliser MyISAM avec Amazon RDS, il peut être utile de suivre ces étapes dans certaines situations pour la fonctionnalité de restauration d'instantané de base de données. RDS for MySQL ne prend actuellement pas en charge le moteur de stockage fédéré.

Lorsque vous créez une instance de base de données, l'utilisateur principal par défaut que vous employez bénéficie de certains privilèges. Consultez Privilèges du compte utilisateur principal dans le guide de l'utilisateur Amazon RDS pour en connaître la liste.

Les réplicas en lecture RDS for MySQL nécessitent un moteur de stockage transactionnel et sont uniquement pris en charge par le moteur de stockage InnoDB. Les moteurs de stockage MySQL non transactionnels, comme MyISAM, peuvent empêcher le bon fonctionnement des réplicas en lecture. Toutefois, si vous choisissez tout de même d'utiliser MyISAM avec les réplicas en lecture, nous vous conseillons de consulter attentivement la métrique Replica Lag (délai de réplication) dans Amazon CloudWatch (disponible par le biais de la console de gestion AWS ou des API Amazon CloudWatch) et de recréer le réplica en lecture s'il continue de prendre du retard en raison d'erreurs de réplication. Les mêmes conseils s'appliquent à l'utilisation de tables temporaires et de tout autre moteur non transactionnel.

Vous pouvez définir le format de journalisation binaire par ligne, pour MySQL 5.6 et les versions ultérieures. Par défaut, la réplication est définie sur format mixte (ce qui inclut la réplication par ligne et par instruction). Cette option devrait répondre aux exigences de la plupart des cas d'application. La documentation MySQL comprend des explications supplémentaires sur la différence entre la réplication par ligne et la réplication de type format mixte.

Les déploiements bleus/verts d'Amazon RDS sont disponibles dans les versions 5.7 et supérieures de RDS for MySQL. Pour en savoir plus sur les versions disponibles, consultez la documentation relative à RDS for MySQL.

Les déploiements bleus/verts d'Amazon RDS sont disponibles dans toutes les régions AWS applicables ainsi que dans les régions AWS GovCloud.

Les déploiements bleus/verts d'Amazon RDS vous permettent d'effectuer des modifications plus sûres, plus simples et plus rapides des bases de données, telles que des mises à niveau de versions majeures ou mineures, des modifications de schémas, des mises à l'échelle d'instances, des modifications de paramètres de moteurs et des mises à jour de maintenance.

Les déploiements bleus/verts d'Amazon RDS vous permettent d'effectuer des modifications de bases de données plus sûres, plus simples et plus rapides. Les déploiements bleus/verts conviennent parfaitement aux cas d'utilisation tels que les mises à niveau majeures ou mineures de moteurs de bases de données, les mises à jour de systèmes d'exploitation, les modifications de schémas dans des environnements verts qui n'interrompent pas la réplication logique (comme l'ajout d'une nouvelle colonne à la fin d'une table) ou les modifications des paramètres de bases de données. Vous pouvez utiliser les déploiements bleus/verts pour effectuer plusieurs mises à jour de bases de données en même temps à l'aide d'un seul basculement. Cela vous permet de rester à jour en ce qui concerne les correctifs de sécurité, d'améliorer les performances des bases de données et d'accéder aux nouvelles fonctionnalités de bases de données avec des temps d'arrêt courts et prévisibles.

L'exécution de vos charges de travail sur des instances vertes vous coûte le même prix que sur les instances bleues. Le coût d'utilisation des instances bleues et vertes comprend notre tarification standard actuelle pour les instances db.instances, le coût du stockage, le coût des E/S en lecture/écriture ainsi que le prix de toutes les fonctionnalités activées, telles que les sauvegardes et l'analyse des performances d'Amazon RDS. En fait, vous payez environ deux fois le coût d'exécution des charges de travail sur une instance db.instance pendant la durée de vie du déploiement bleu/vert.

Par exemple : vous avez une base de données RDS for MySQL 5.7 exécutée sur deux db.instances r5.2xlarge, une instance de base de données principale et un réplica en lecture, dans la région AWS us-east-1 avec une configuration Multi-AZ (MAZ). Chacune des db.instance r5.2xlarge est configurée pour 20 Gio Amazon Elastic Block Store (Amazon EBS) à usage général. Vous créez un clone de la topologie de l'instance bleue en utilisant les déploiements bleus/verts d'Amazon RDS, vous l'exécutez pendant 15 jours (360 heures), puis vous supprimez les instances bleues après un basculement réussi. Les instances bleues coûtent 1 387 USD pour 15 jours à un tarif à la demande de 1,926 USD/h (coût de l'instance + EBS). Le coût total de l'utilisation des déploiements bleus/verts pour ces 15 jours est de 2 774 USD, soit environ deux fois le coût de l'exécution des instances bleues pour cette période.

Les déploiements bleus/verts d'Amazon RDS vous permettent d'effectuer des modifications plus sûres, plus simples et plus rapides des bases de données, telles que des mises à niveau de versions majeures ou mineures, des modifications de schémas, des mises à l'échelle d'instances, des modifications de paramètres de moteurs et des mises à jour de maintenance.

Lorsque les déploiements bleus/verts d'Amazon RDS initient un basculement, ils bloquent les écritures dans les environnements bleus et verts, jusqu'à ce que le basculement soit terminé. Pendant le basculement, l'environnement de transit, ou environnement vert, rattrape l'environnement bleu, garantissant la cohérence des données entre les environnements bleu et vert. Une fois que les environnements bleu et vert sont complètement synchronisés, les déploiements bleus/verts promeuvent l'environnement vert comme le nouvel environnement bleu en redirigeant le trafic vers l'environnement vert. Les déploiements bleus/verts d'Amazon RDS sont conçus pour permettre les écritures sur l'environnement vert une fois le basculement terminé, ce qui élimine toute perte de données pendant le processus de basculement.

Si votre environnement bleu est un réplica logique autogéré ou un abonné, nous bloquons le basculement. Nous vous recommandons d'arrêter d'abord la réplication vers l'environnement bleu, d'effectuer le basculement, puis de reprendre la réplication. En revanche, si votre environnement bleu est la source d'un réplica logique autogéré ou d'un diffuseur de publication, vous pouvez continuer vers le basculement. Cependant, vous devrez mettre à jour le réplica autogéré afin de le répliquer à partir de l'environnement vert après le basculement.

Les déploiements bleus/verts d'Amazon RDS ne suppriment pas votre ancien environnement de production. Si nécessaire, vous pouvez y accéder pour des validations supplémentaires et des tests de performance/régression. Si vous n'avez plus besoin de l'ancien environnement de production, vous pouvez le supprimer. Les frais de facturation standard s'appliquent aux anciennes instances de production jusqu'à ce que vous les supprimiez.

Les barrières de protection pour le basculement des déploiements bleus/verts d'Amazon RDS bloquent les écritures sur vos environnements bleus et verts jusqu'à ce que votre environnement vert rattrape son retard avant le basculement. Les déploiements bleus/verts effectuent également des surveillances de l'état de l'instance primaire et des réplicas dans vos environnements bleus et verts. Ils effectuent également des surveillances de l'état de la réplication, par exemple, pour vérifier si la réplication s'est arrêtée ou s'il y a des erreurs. Ils détectent les transactions de longue durée entre vos environnements bleu et vert. Vous pouvez spécifier votre temps d'arrêt maximum tolérable, jusqu'à 30 secondes. Ainsi, le basculement est interrompu lorsqu'une transaction en cours dépasse ce temps.

Non, les déploiements bleus/verts d'Amazon RDS ne prennent pas en charge le proxy Amazon RDS, les réplicas en lecture inter-régions ni les réplicas en lecture en cascade.

Non, pour le moment, vous ne pouvez pas utiliser les déploiements bleus/verts d'Amazon RDS pour annuler les modifications.

MySQL protège les utilisateurs contre la perte de données en écrivant les données dans des pages de 16 Kio en mémoire deux fois dans un stockage durable : d'abord dans le « tampon de double écriture », puis dans le stockage des tables. Les écritures optimisées pour Amazon RDS écrivent vos pages de données de 16 Kio directement dans vos fichiers de données de manière fiable et durable en une seule étape grâce à la fonctionnalité de prévention des écritures déchirées d’AWS Nitro System.

Les écritures optimisées pour Amazon RDS sont disponibles pour les versions majeure 8.0.30 et supérieures de MySQL.

Les écritures optimisées pour Amazon RDS sont disponibles dans les instances db.r6i et db.r5b. Le service est disponible dans toutes les régions où ces instances sont disponibles, à l'exception des régions AWS Chine.

Tous les utilisateurs de RDS for MySQL devraient implémenter les écritures optimisées pour Amazon RDS afin d'obtenir jusqu'à deux fois plus de débit pour les transactions d'écriture. Les applications avec des charges de travail à forte intensité d'écriture telles que les paiements numériques, les transactions financières et les applications de jeu en ligne trouveront cette fonctionnalité particulièrement utile.

Non. L'édition compatible avec Amazon Aurora MySQL permet déjà d'éviter l'utilisation du « tampon de double écriture ». À la place, Aurora réplique les données de six façons dans trois zones de disponibilité (AZ) et utilise une approche basée sur le quorum pour écrire durablement les données et les lire correctement par la suite.

Actuellement, cette version initiale ne prend pas en charge les écritures optimisées pour Amazon RDS pour vos instances de bases de données existantes, et ce, même si la classe d'instance prend en charge les écritures optimisées.

Les écritures optimisées pour Amazon RDS sont disponibles pour les clients RDS for MySQL sans frais supplémentaires.

Les charges de travail qui utilisent des objets temporaires dans MySQL pour le traitement des requêtes tirent parti des lectures optimisées pour Amazon RDS. Les lectures optimisées placent les objets temporaires sur le stockage d'instance NVMe de l'instance de base de données, au lieu du volume Amazon EBS. Cela permet d'accélérer le traitement des requêtes complexes jusqu'à 50 %.

Les lectures optimisées pour Amazon RDS sont disponibles pour RDS for MySQL sur MySQL 8.0.28 et les versions supérieures.

Les lectures optimisées pour Amazon RDS sont disponibles dans toutes les régions où les instances db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn et X2iedn sont disponibles. Pour plus d'informations, consultez la documentation sur les classes d'instances de bases de données Amazon RDS.

Les clients devraient utiliser les lectures optimisées pour Amazon RDS dans les cas suivants : les charges de travail nécessitant des requêtes complexes, l'analytique à usage général ou les charges de travail nécessitant des groupes complexes, des tris, des agrégations de hachage, des jointures à forte charge et des expressions de tables communes (CTE). Ces cas d'utilisation entraînent la création de tables temporaires, ce qui permet aux lectures optimisées d'accélérer le traitement des requêtes de votre charge de travail.

Oui, les clients peuvent convertir leur base de données Amazon RDS existante pour utiliser Amazon RDS Optimized Reads en déplaçant la charge de travail vers une instance compatible avec Optimized Read. Optimized Reads est également disponible par défaut sur toutes les classes d'instance prises en charge. Si vous exécutez votre charge de travail sur des instances db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn et X2iedn, vous bénéficiez déjà de Lectures optimisées.

Vous devez utiliser l’intégration zéro ETL d’Amazon RDS for MySQL à Amazon Redshift lorsque vous voulez supprimer la nécessité de créer et de gérer des pipelines de données complexes. Une fois que les données sont dans Amazon Redshift, vous avez accès à des fonctionnalités d’analyse et de machine learning (ML) en temps quasi réel sur vos données transactionnelles depuis RDS for MySQL.

L’intégration zéro ETL de RDS for MySQL à Amazon Redshift est disponible pour les versions 8.0.32 et supérieures de MySQL dans les régions AWS prises en charge.

L’intégration zéro ETL de RDS for MySQL à Amazon Redshift permet de réaliser des analyses en temps quasi réel et un machine learning (ML) sur des pétaoctets de données transactionnelles et vous évite de devoir créer et gérer des pipelines de données complexes. Quelques secondes après avoir été écrites sur RDS for MySQL, les données sont répliquées sur Amazon Redshift. Vous pouvez consolider les données de plusieurs bases de données et tables depuis RDS for MySQL vers Amazon Redshift. En fonction de vos besoins analytiques, le filtrage des données de bases de données et de tables spécifiques vous permet d’importer des données de manière sélective dans Amazon Redshift.

Vous payez pour les ressources RDS for MySQL et Amazon Redshift utilisées pour créer et traiter les données de modification créées dans le cadre d'une intégration zéro ETL. Ces ressources comprennent les coûts d'exportation des instantanés Amazon RDS pour ensemencer et resynchroniser vos entrepôts des données Amazon Redshift, les coûts de transfert des données de capture des données de changement (CDC) pour la réplication continue des modifications de données de la source à la cible, les E/S et le stockage RDS ordinaires utilisés pour traiter les données de changement, ainsi que les coûts de stockage et de calcul Amazon Redshift ordinaires pour les données répliquées. Pour en savoir plus, consultez la page de tarification de RDS for MySQL.

Par exemple : vous avez une base de données RDS for MySQL 8.0.32 et un entrepôt des données Amazon Redshift fonctionnant dans la région USA Est (Virginie du Nord). Cette instance de base de données RDS for MySQL utilise actuellement 50 Go de capacité de stockage à usage général (gp3) qui inclut des IOPS de base provisionnés, des sauvegardes automatisées sont activées et la journalisation binaire de MySQL est activée.

Lorsque vous créez une intégration zéro ETL avec Amazon Redshift pour votre instance de base de données RDS for MySQL, un instantané des données (50 Go) est créé et exporté pour ensemencer un entrepôt des données Amazon Redshift. Le lendemain, vous modifiez la clé primaire d'une table dans votre instance de base de données RDS for MySQL, ce qui entraîne une resynchronisation de l'exportation de l'instantané vers Amazon Redshift. Au cours d'une période de 30 jours, la base de données traite 5 Go de données modifiées.

Dans cet exemple, le coût d'utilisation de RDS pour l'intégration zéro ETL de MySQL avec Amazon Redshift dans la région USA Est (Virginie du Nord) dans les 30 jours est de 50 Go x (0,10 USD/Go) pour l'exportation initiale plus 50 Go x (0,10 USD/Go) pour les coûts de resynchronisation plus 5 Go x (2,00 USD/Go) pour le transfert de données CDC, pour un total de 20,00 USD. En plus de ces coûts pour l’intégration zéro ETL, vous êtes responsable des frais liés à l’utilisation normale d’Amazon RDS et d’Amazon Redshift pour traiter les données répliquées, tels que les coûts d’E/S, de stockage et de calcul.

Oui. Pour réduire la consommation de ressources sur l’instance principale, vous pouvez utiliser un réplica en lecture Amazon RDS en tant qu’instance Amazon RDS source pour une intégration zéro ETL à Amazon Redshift.

Oui, vous pouvez utiliser AWS CloudFormation pour gérer et automatiser la configuration et le déploiement des ressources nécessaires à une intégration zéro ETL de RDS for MySQL à Amazon Redshift. Pour en savoir plus, consultez le guide de l’utilisateur AWS CloudFormation.

L’intégration zéro ETL de RDS for MySQL à Amazon Redshift réplique de manière atomique les transactions afin de garantir la cohérence des données entre la base de données RDS for MySQL source et le cluster Amazon Redshift cible.

Voici quelques points clés concernant l’atomicité des transactions grâce à cette intégration :

• Seules les transactions validées dans RDS for MySQL sont répliquées sur Amazon Redshift. Les transactions non validées ou annulées ne sont pas appliquées.
• L’intégration utilise un processus de validation en deux phases pour appliquer de manière atomique chaque transaction à Amazon Redshift. Toutes les modifications apportées aux données de la transaction sont appliquées ou, en cas d’erreur, aucune n’est appliquée.
• La cohérence des transactions est maintenue entre la source et la cible. Après la réplication, les données d’une transaction donnée seront cohérentes à la fois dans RDS for MySQL et dans Amazon Redshift.
• Les modifications de schéma via DDL ou DML sont également appliquées de manière atomique pour préserver l’intégrité.
• L’application atomique des transactions garantit qu’aucune transaction partielle ou aucun état de données incohérent ne peut se produire entre les bases de données.

L’intégration zéro ETL de RDS for MySQL avec Amazon Redshift assure une cohérence transactionnelle totale entre la base de données RDS for MySQL source et le cluster Amazon Redshift cible.

Voici quelques points clés sur la façon dont les modifications de schéma sont gérées :

• Les instructions DDL telles que CREATE TABLE, ALTER TABLE, DROP TABLE, etc. sont automatiquement répliquées depuis RDS for MySQL vers Amazon Redshift.
• L’intégration effectue les vérifications et les ajustements nécessaires dans les tables Amazon Redshift pour les modifications de schéma répliquées. Par exemple, l’ajout d’une colonne dans RDS for MySQL ajoutera la colonne dans Amazon Redshift.
• La réplication et la synchronisation du schéma se font automatiquement en temps quasi réel avec un décalage minimal entre les bases de données source et cible.
• La cohérence du schéma est maintenue même si les modifications DML se produisent parallèlement aux modifications DDL.