Comparaison entre RDS et EC2 pour la gestion de MySQL ou MariaDB sur AWS

RDS est une base de données en tant que service (DBaaS) qui configure et gère automatiquement vos bases de données dans le cloud AWS. L'utilisateur a un pouvoir limité sur des configurations spécifiques par rapport à l'exécution de MySQL directement sur Elastic Compute Cloud (EC2). Mais RDS est un service pratique, tant que vous pouvez vivre avec les instances et les configurations qu'il propose.

Amazon RDS prend actuellement en charge diverses versions de MySQL et MariaDB ainsi que le moteur de base de données Amazon Aurora compatible avec MySQL. Il prend en charge la réplication, mais comme vous pouvez vous y attendre d'une console Web prédéfinie, il existe certaines limitations.

Il y a quelques compromis lors de l'utilisation de RDS. Ceux-ci peuvent non seulement affecter la façon dont vous gérez et provisionnez vos instances de base de données, mais également des éléments clés tels que les performances, la sécurité et la haute disponibilité.

Dans ce blog, nous examinerons les différences entre l'utilisation de RDS et l'exécution de MySQL sur EC2, en mettant l'accent sur la réplication. Comme nous le verrons, choisir entre héberger MySQL sur une instance EC2 ou utiliser Amazon RDS n'est pas une mince affaire.

Compromis de la plate-forme RDS

La plus grande taille de base de données qu'AWS peut héberger dépend de votre environnement source, de l'allocation des données dans votre base de données source et de l'occupation de votre système.

AWS est divisé en régions. Chaque compte AWS a des limites, par région, sur le nombre de ressources AWS pouvant être créées. Une fois qu'une limite pour une ressource a été atteinte, les appels supplémentaires pour créer cette ressource échoueront.

Pour les instances de base de données MySQL Amazon RDS, la limite maximale de stockage provisionné limite la taille d'une table à une taille maximale de 6 To lors de l'utilisation d'espaces de table fichier par table InnoDB.

La fonctionnalité de fichier par table d'InnoDB est quelque chose que vous devriez considérer même si vous ne cherchez pas à migrer une grande base de données vers le cloud. Vous remarquerez peut-être que certaines instances de base de données existantes ont une limite inférieure. Par exemple, les instances de base de données MySQL créées avant avril 2014 ont une limite de taille de fichier et de table de 2 To. Cette limite de taille de fichier de 2 To s'applique également aux instances de base de données ou aux réplicas en lecture créés à partir d'instantanés de base de données pris avant avril 2014.

L'une des principales différences qui affecte la façon dont vous configurez et gérez la réplication de la base de données est l'absence d'utilisateur SUPER. Pour remédier à cette limitation, Amazon a introduit des procédures stockées qui prennent en charge diverses tâches DBA. Vous trouverez ci-dessous les procédures clés pour gérer la réplication MySQL RDS.

Ignorer l'erreur de réplication :

CALL mysql.rds_skip_repl_error;

Arrêter la réplication :

CALL mysql.rds_stop_replication;

Démarrer la réplication

CALL mysql.rds_start_replication;

Configure une instance RDS en tant que réplica en lecture d'une instance MySQL exécutée en dehors d'AWS.

CALL mysql.rds_set_external_master;

Reconfigure une instance MySQL pour qu'elle ne soit plus un réplica en lecture d'une instance MySQL exécutée en dehors d'AWS.

CALL mysql.rds_reset_external_master;

Importe un certificat. Ceci est nécessaire pour activer la communication SSL et la réplication cryptée.

CALL mysql.rds_import_binlog_ssl_material;

Supprime un certificat.

CALL mysql.rds_remove_binlog_ssl_material;

Modifie la position du journal du maître de réplication au début du prochain journal binaire sur le maître.

CALL mysql.rds_next_master_log;

Alors que les procédures stockées prennent en charge un certain nombre de tâches, c'est un peu une courbe d'apprentissage. L'absence de privilège SUPER peut également créer des problèmes lors de l'utilisation de la surveillance de la réplication externe.

Amazon RDS ne prend actuellement pas en charge les éléments suivants :

• ID de transaction globale
• Espace table transportable
• Plug-in d'authentification
• Plug-in de force de mot de passe
• Filtres de réplication
• Réplication semi-synchrone

Dernier point mais non le moindre - accès au shell. Amazon RDS n'autorise pas l'accès direct de l'hôte à une instance de base de données via Telnet, Secure Shell (SSH) ou Windows Remote Desktop Connection (RDP). Vous pouvez toujours utiliser le client sur un hôte d'application pour vous connecter à la base de données via des outils standard tels que le client mysql.

Il existe d'autres limitations, comme décrit dans la documentation RDS.

Haute disponibilité avec MySQL sur EC2

Pour automatiser les tâches de déploiement et de gestion/maintenance (tout en gardant le contrôle), il est possible d'utiliser ClusterControl. Tout comme avec RDS, vous avez la possibilité de déployer une configuration de base de données en quelques minutes via une interface graphique. L'ajout de nœuds, la planification de sauvegardes, l'exécution de basculements, etc., peuvent également être effectués facilement via l'interface graphique. Il existe des options pour faire fonctionner MySQL directement sur EC2, et ainsi conserver le contrôle de ses options de haute disponibilité. Lorsque vous empruntez cette voie, il est important de comprendre comment tirer parti des différentes fonctionnalités AWS qui sont à votre disposition. Assurez-vous de consulter notre livre blanc "DIY Cloud Database".

Déploiement

ClusterControl peut automatiser le déploiement de différentes configurations de bases de données à haute disponibilité - de la réplication maître-esclave aux clusters multi-maîtres. Toutes les principales versions de MySQL sont prises en charge - Oracle MySQL, MariaDB et Percona Server. Une configuration initiale du VPC/groupe de sécurité est requise, et celles-ci sont bien décrites dans le livre blanc DIY Cloud Database. Notez que des concepts similaires s'appliquent, qu'il s'agisse d'AWS, de Google Cloud ou d'Azure

Galera Cluster est une bonne alternative à considérer lors du déploiement d'un service MySQL hautement disponible. Il s'est imposé comme un remplaçant crédible des architectures maître-esclave MySQL traditionnelles, bien qu'il ne s'agisse pas d'un remplacement instantané. La plupart des applications peuvent encore être adaptées pour fonctionner dessus. Il est possible de définir différents segments pour les bases de données qui s'étendent sur plusieurs régions AWS.

Il est possible de mettre en place une « réplication hybride » en combinant la réplication synchrone au sein d'un cluster Galera et la réplication asynchrone entre le cluster et un ou plusieurs esclaves. Des options telles que le retardement de l'esclave donnent un niveau supplémentaire de protection aux données.

Couche proxy

Pour obtenir une haute disponibilité, le déploiement d'une configuration hautement disponible ne suffit pas. Les applications doivent en quelque sorte savoir quels nœuds fonctionnent et lesquels ne fonctionnent pas. Changements de topologie, par ex. le déplacement d'un maître vers un autre hôte, doit également être propagé d'une manière ou d'une autre afin d'éviter les erreurs dans la couche application. ClusterControl prend en charge les déploiements de proxys tels que HAProxy, MaxScale et ProxySQL. Pour HAProxy et ProxySQL, il existe des options supplémentaires pour déployer des instances redondantes avec Keepalived et VirtualIP.

Réplication interrégionale

Amazon RDS fournit des services de réplica en lecture. Les réplicas interrégionaux vous permettent d'adapter les lectures, car AWS propose ses services dans un certain nombre de centres de données à travers le monde. Tous les réplicas en lecture sont accessibles et peuvent être utilisés pour la lecture dans un nombre maximum de cinq régions. Ces nœuds sont indépendants et peuvent être utilisés dans votre chemin de mise à niveau, ou peuvent être promus en bases de données autonomes.

En plus de cela, Amazon propose des déploiements multi-AZ basés sur DRBD, la réplication de disque synchrone. Quelle est la différence avec les réplicas en lecture ? La principale différence est que seul le moteur de base de données de l'instance principale est actif, ce qui entraîne d'autres variantes architecturales.

Contrairement aux réplicas en lecture, les mises à niveau de version du moteur de base de données se produisent sur le principal. Une autre différence est qu'AWS RDS basculera automatiquement avec DRBD, tandis que les réplicas en lecture (utilisant la réplication asynchrone) nécessiteront des opérations manuelles de votre part.

Le basculement multi-AZ sur RDS utilise un changement DNS pour pointer vers l'instance de secours, selon Amazon, cela devrait se produire dans les 60 à 120 secondes pendant le basculement. Étant donné que le serveur de secours utilise les mêmes données de stockage que le serveur principal, il y aura probablement une récupération des transactions/journaux. Les bases de données plus volumineuses peuvent consacrer beaucoup de temps à la récupération d'InnoDB, veuillez donc en tenir compte dans votre plan de DR et votre calcul de RTO.

Bien sûr, cela s'accompagne d'un surcoût. Jetons un coup d'œil à un exemple de base. Le coût de l'hôte db.t2.medium avec 2 vCPU, 4 Go de RAM est de 185,98 USD par mois, le prix doublera lorsque vous activez la réplique multizone (MZ) à 370,98 UDB. Le prix variera selon les régions mais il doublera en MZ.

Afin d'obtenir la même chose avec EC2, vous pouvez déployer vos machines virtuelles dans différentes régions. Chaque région AWS est complètement indépendante. Le paramètre de la région AWS peut être modifié dans la console, en définissant la variable d'environnement EC2_REGION, ou il peut être remplacé à l'aide du paramètre --region avec l'interface de ligne de commande AWS. Lorsque votre ensemble de serveurs est prêt, vous pouvez utiliser ClusterControl pour déployer et surveiller votre réplication. Vous pouvez également configurer manuellement la réplication via la console à l'aide de commandes standard.

Réplication inter-technologies

Il est possible de configurer la réplication entre une instance de base de données Amazon RDS MySQL ou MariaDB et une instance MySQL ou MariaDB externe à Amazon RDS. Cela se fait en utilisant la méthode de réplication standard dans mysql, via des journaux binaires. Pour activer les journaux binaires, vous devez modifier la configuration my.cnf. Sans accès au shell, cette tâche devenait impossible dans RDS. C'est fait d'une manière pas si évidente. Vous avez deux options. L'une consiste à activer les sauvegardes - définissez des sauvegardes automatisées sur votre instance de base de données Amazon RDS avec une rétention supérieure à 0. Ou activez la réplication vers un serveur esclave prédéfini. Les deux tâches activeront les journaux binaires que vous pourrez utiliser ultérieurement pour votre réplication.

Conservez les binlogs dans votre instance maître jusqu'à ce que vous ayez vérifié qu'ils ont été appliqués sur le réplica. Cette maintenance garantit que vous pouvez restaurer votre instance maître en cas de panne.

Un autre obstacle peut être les autorisations. Les autorisations requises pour démarrer la réplication sur une instance de base de données Amazon RDS sont restreintes et ne sont pas disponibles pour votre utilisateur principal Amazon RDS. Pour cette raison, vous devez utiliser les commandes Amazon RDS mysql.rds_set_external_master et mysql.rds_start_replication pour configurer la réplication entre votre base de données en direct et votre base de données Amazon RDS.

Surveillez les événements de basculement pour l'instance Amazon RDS qui est votre réplica. Si un basculement se produit, l'instance de base de données qui est votre réplica peut être recréée sur un nouvel hôte avec une adresse réseau différente. Pour plus d'informations sur la surveillance des événements de basculement, consultez Utilisation de la notification d'événement Amazon RDS.

Dans l'exemple ci-dessous, nous verrons comment activer la réplication de RDS vers une base de données externe située sur une instance EC2.
Vous devez avoir activé les journaux binaires, nous utilisons ici un esclave RDS.

Spécifiez le nombre d'heures de conservation des journaux binaires.

mysql -h RDS_MASTER -u<username> -u<password>
call mysql.rds_set_configuration('binlog retention hours', 7);

Sur RDS MASTER, créez un utilisateur de réplication avec les commandes suivantes :

CREATE USER 'repl'@'ec2DBslave' IDENTIFIED BY 's3cr3tp4SSw0rd';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'ec2DBslave';

Sur RDS SLAVE, lancez les commandes :

mysql -u<username> -u<password> -h RDS_SLAVE
call mysql.rds_stop_replication;
SHOW SLAVE STATUS;  Exec_Master_Log_Pos, Relay_Master_Log_File.

Sur RDS SLAVE, exécutez mysqldump au format suivant :

mysqldump -u<username> -u<password> -h RDS_SLAVE --routines --triggers --single-transaction --databases DB1 DB2 DB3 > mysqldump.sql

Importez le vidage de la base de données dans une base de données externe :

mysql -u<username> -u<password> -h ec2DBslave
tee import_database.log;
source mysqldump.sql;

CHANGE MASTER TO 
 MASTER_HOST='RDS_MASTER', 
 MASTER_USER='repl',
 MASTER_PASSWORD='s3cr3tp4SSw0rd',
 MASTER_LOG_FILE='<Relay_Master_Log_File>',
 MASTER_LOG_POS=<Exec_Master_Log_Pos>;

Créez un filtre de réplication pour ignorer les tables créées par AWS uniquement sur RDS

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('mysql.rds\_%');

Démarrer la réplication

START SLAVE;

Vérifier l'état de la réplication

SHOW SLAVE STATUS;

C'est tout pour le moment. La gestion de MySQL sur AWS est un sujet important. Faites-nous part de vos réflexions dans la section des commentaires ci-dessous.