A peine fini de digérer la première partie…
Rappel des épisodes précédents :
– épisode 1 : MySQL sur Google Cloud platform.
– épisode 2 : MySQL et MariaDB sur Microsoft Azure.
– épisode 3 1/2 : MySQL et MariaDB dans Amazon RDS 1/2
Dans l’article précédent 1/2 nous avions vu le contexte technique dans lequel les bases RDS évoluent, ainsi que les premiers éléments de découverte d’une instance MySQL ou MariaDB sur le cloud Amazon : limitations, connexion, configuration, etc…
Dans cette suite et fin, nous allons poursuivre notre exploration des fonctionnalités et terminer par un match comparatif entre les offres Azure, GCP et RDS.
MySQL et MariaDB sur RDS (suite)
Gestion du stockage:
Une fois alloué, que ce soit en GP2 ou en IO1, les caractéristiques du stockage peuvent être modifiées à chaud:
– Sa capacité peut être augmentée (mais pas réduite):
$ aws rds modify-db-instance --db-instance-identifier my57 \ --allocated-storage 30 --apply-immediately
– Son type peut être modifié:
$ aws rds modify-db-instance --db-instance-identifier my57 \ --storage-type io1 --apply-immediately
– Ses IOPS provisionnés peuvent être modifiés:
$ aws rds modify-db-instance --db-instance-identifier my57 \ --storage-type io1 --allocated-storage 200 \ --iops 3000 --apply-immediately
La transition peut s’étaler sur une période plus ou moins longue en fonction du type de modification, mais pendant cette période transitoire, l’instance va entrer dans un mode ‘storage optimization’ …
$ aws rds describe-db-instances --db-instance-identifier my57 (...) "DBInstanceStatus": "storage-optimization", (...)
… durant lequel elle n’accepte plus d’autre changement au niveau stockage. On ne pourra donc pas modifier une caractéristique puis une autre dans la foulée, il faudra bien réfléchir à la séquence des modifications à réaliser avant de se lancer:
$ aws rds modify-db-instance --db-instance-identifier my57 \ --allocated-storage 40 --apply-immediately An error occurred (InvalidParameterCombination) when calling the ModifyDBInstance operation: You can't currently modify the storage of this DB instance because the previous storage change is being optimized.
Autre remarque,contrairement à GCP, il n’y a pas d’auto scaling du stockage sur AWS, ce qui veut dire que des alarmes sur seuil doivent être mises en place pour éviter un remplissage intempestif. Ces alarmes sont gérées par les briques de supervision Cloudwatch et SNS:
$ aws cloudwatch put-metric-alarm --alarm-name "err-low-storage" \ --metric-name "FreeStorageSpace" --namespace "AWS/RDS" \ --statistic "Average" --period 600 --evaluation-periods 1 \ --threshold 10 --unit Percent \ --comparison-operator "LessThanOrEqualToThreshold" \ --dimensions "Name=DBInstanceIdentifier,Value=my57" \ --alarm-actions "arn:aws:sns:eu-west-3:XXXXXXXXXXX:my-sns-target"
Nous verrons un autre exemple d’utilisation de cloudwatch et SNS un peu plus loin dans la section Supervision et outils de diagnostics.
Protection contre la suppression:
Comme sur Azure, il existe un mécanisme de protection contre la suppression d’instance activé par défaut:
La propriété est exposée par describe-db-instances…
$ aws rds modify-db-instance --db-instance-identifier my57 \ --deletion-protection $ aws rds describe-db-instances --db-instance-identifier my57 (...) "DeletionProtection": true, (...)
…de sorte qu’une suppression par erreur est impossible:
$ aws rds delete-db-instance --db-instance-identifier my57 \ --skip-final-snapshot An error occurred (InvalidParameterCombination) when calling the DeleteDBInstance operation: Cannot delete protected DB Instance, please disable deletion protection and try again.
Gestion des logs binaires:
Par défaut les logs binaires au format MIXED sont activés, pour permettre d’assurer une restauration point-in-time en étant couplés avec des snapshots au niveau stockage. En sachant que les 2 autres formats (STATEMENT, ROW) sont aussi supportés à partir de la 5.6+.
Là encore un gros avantage en termes de manageabilité, la possibilité offerte de décoder les logs binaires à distance via le client mysqlbinlog et l’option –read-from-remote-server :
$ mysqlbinlog --read-from-remote-server \ --host=my57.xxxxxxxxx.eu-west-3.rds.amazonaws.com \ --port=3306 --user=my57_user \ --base64-output=DECODE-ROWS --verbose --password \ mysql-bin-changelog.000359 Enter password: ************ /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #190404 11:45:00 server id 556576755 end_log_pos 123 CRC32 0x27f680cd Start: binlog v 4, server v 5.7.25-log created 190404 11:45:00 (...)
Encore une fonctionnalité qui ferait presque oublier qu’on a affaire à une instance en PaaS 🙂
Par contre les logs binaires utilisent de l’espace disque et donc consomment aussi quelques euros, attention donc si vous souhaitez activer le format ROW qui risque de faire exploser cette partie. Et attention aussi à la rétention, qui peut être gérée via des procédures stockées :
mysql> call mysql.rds_show_configuration() ;
+------------------------+-------+------------------------------------...
| name | value | description ...
+------------------------+-------+------------------------------------...
| binlog retention hours | NULL | binlog retention hours specifies th...
| source delay | 0 | source delay specifies replication...
| target delay | 0 | target delay specifies replication...
+------------------------+-------+------------------------------------...
mysql> call mysql.rds_set_configuration("binlog retention hours", 96) ;
Query OK, 0 rows affected (0.02 sec)
Enfin, et hors cas de réplication, il est aussi possible de désactiver les logs binaires bien que ce ne soit pas conseillé car plus de possibilité de restaurer à un point précis dans le temps, en passant la valeur de backup-retention-period de l’instance à 0.
Export / import de données:
Pas de SELECT INTO OUTFILE, et pas pour l’instant de LOAD DATA LOCAL INFILE depuis S3 pour MySQL, alors que son petit camarade de jeu PostgreSQL lui bénéficie de COPY via S3 depuis le 24 avril, ça viendra peut être plus tôt qu’on ne le pense…
En dehors de cela, pas trouvé grand chose à se mettre sous la dent pour l’export de données, en dehors de mysqldump ou du bricolage via un SELECT CONCAT pour produire du CSV en sortie…
$ mysql --login-path=rds57 --batch \ --execute="SELECT CONCAT(actor_id,',\"',first_name,'\",\"',last_name,'\",\"', last_update,'\"') FROM sakila.actor;" > ~/actor.csv
Pas mieux.
Sinon l’autre alternative serait d’utiliser AWS Data Pipeline mais là on touche à un ETL dédié et potentiellement un sujet à part entière, qui ferait sans doute un bon candidat pour un prochain article … en deux parties 🙂 je n’ai donc pas creusé le sujet plus loin que ça pour l’instant.
Pour les volumétries importantes, il est possible de passer par un backup physique généré par Percona Xtrabackup dont l’archive serait à copier sur S3, et à intégrer ensuite dans une nouvelle instance RDS en utilisant aws rds restore-db-instance-from-s3.
Sauvegarde et restauration:
Ce qui nous amène à la question de sauvegarde et restauration.
Dans le PaaS Amazon, comme dans les autres PaaS, les backups sont pris en charge automatiquement. Les logs binaires étant activés par défaut, l’ensemble fournit une solution robuste de restauration point-in-time pour peu que toutes les tables soient créées en InnoDB.
Le premier snapshot est pris à la création de l’instance, il contient l’intégralité du stockage utilisé, de sorte que les snapshots suivants se contenteront de capturer un incrémental de l’activité.
La plage de sauvegarde est paramétrable ainsi que la rétention (0-35 jours, 7 jours par défaut via la console, 1 jour via API/aws cli):
$ aws rds describe-db-instances --db-instance-identifier my57 (...)"PreferredBackupWindow": "23:00-23:30", "BackupRetentionPeriod": 7, (...)
Comme sur Azure, l’espace de backup sur RDS reste hors charges tant qu’il ne dépasse pas la valeur de ce qui a été provisionné en stockage de données. Par ailleurs, cet espace de backup est partagé par toutes les instances d’un même compte et d’une même région. Donc il faut estimer l’espace global de backup par rapport à l’espace global provisionné pour toutes les instances RDS même compte / même région, et pas uniquement instance par instance.
Sur les déploiements Multi-AZ, le backup est effectué sur l’instance standby pour ne pas pénaliser les IO sur l’instance nominale.
Autre avantage par rapport à la concurrence, à la suppression de l’instance, il est possible de conserver les snapshots automatiques, et/ou d’en créer un supplémentaire avant de supprimer définitivement l’instance :
$ aws rds delete-db-instances --db-instance-identifier my57 \ --no-delete-automated-backups --no-skip-final-snapshot \ --final-db-snapshot-identifier "my57.KEEP.bak"
En plus des backups automatiques, des backups additionnels en plus des backups automatiques peuvent être effectués (50 maximum par région):
$ aws rds create-db-snapshot --db-instance-identifier my57 \ --db-snapshot-identifier "my57-20190404-1456-BAK" \ --tags "Key=DateCr,Value=20190404-1456"
Dans le cas d’une restauration, de même que pour les autres solutions cloud, le snapshot sera nécessairement restauré sur une nouvelle instance RDS, le terme restauration est un peu usurpé… Il faudra donc prendre le soin de renommer l’ancienne instance avant de restaurer en réutilisant son nom:
$ aws rds modify-db-instance --db-instance-identifier my57 \ --new-db-instance-identifier my57old --apply-immediately
Il faut aussi penser qu’en changeant le nom, un certain nombre d’identifiants vont aussi changer comme l’ARN de la ressource, et l’endpoint. Lorsque le renommage est effectué, les applications ne pourront plus se connecter tant que la nouvelle instance n’est pas recréée à partir du snapshot de l’ancienne.
La bonne nouvelle c’est que le Security Group et le Parameter Group seront tous les deux immédiatement réutilisables dans la commande de restauration:
$ aws rds restore-db-instance-from-db-snapshot \ --db-instance-identifier my57 \ --db-snapshot-identifier "my57-20190404-1456-bak" \ --availability-zone "eu-west-3a" \ --db-parameter-group-name "my57pg" \ --vpc-security-group-ids "sg-xxxxxxxxxxxxxxxx"
Pour la restauration point-intime, une propriété accessible via describe-db-instances permet de donner l’heure la plus récente à laquelle il sera possible de restaurer:
$ aws rds describe-db-instances --db-instance-identifier my57old (...) "LatestRestorableTime": "2019-04-04T13:55:00Z", (...) $ aws rds restore-db-instance-to-point-in-time \ --source-db-instance-identifier my57old \ --target-db-instance-identifier my57 \ --restore-time "2019-04-04T13:55:00Z" \ --db-parameter-group-name "my57pg" \ --vpc-security-group-ids "sg-xxxxxxxxxxxxxxxx"
Enfin, le snapshot peut aussi servir en règle générale outre restaurer des données, à déplacer une instance d’une AZ vers une autre, d’une région vers une autre ou d’un compte vers un autre.
Fenêtres de maintenance:
AWS effectue régulièrement des mises à jour du matériel et des OSes qui supportent l’infrastructure de RDS. Ces maintenances peuvent nécessiter une mise hors-ligne de l’instance, donc une indisponibilité.
Il est possible de choisir à la création de l’instance la fenêtre de maintenance désirée…
… ou de la modifier plus tard via la console, l’API ou le CLI:
$ aws rds modify-db-instance --db-instance-identifier my57 \ --preferred-maintenance-window "sun:01:00-sun:01:30" \ --apply-immediately
Attention, l’heure de passage des maintenances est en heure UTC, donc gare aux surprises lors des passages en heures d’été / hiver en France …
Pour vérifier si une maintenance est prévue:
$ aws rds describe-pending-maintenance-actions \
--resource-identifier "arn:aws:rds:eu-west-3:xxxxxxxxxxxxx:db:my57"
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "Performance improvements and security updates",
"CurrentApplyDate": "2019-04-22T03:04:00Z",
"AutoAppliedAfterDate": "2019-04-26T19:41:22Z",
"OptInStatus": "next-maintenance"
}
],
On peut egalement choisir d’appliquer une mise à jour en la forçant sans attendre la prochaine fenêtre de maintenance:
$ aws rds apply-pending-maintenance-action \
--resource-identifier "arn:aws:rds:eu-west-3:xxxxxxxxxxxxx:db:my57" \
--apply-action system-update \
--opt-in-type immediate
Note sur –apply-immediately: certaines modifications de l’instance peuvent être effectuées à chaud, mais nous conservons le choix de l’appliquer immédiatement en utilisant –apply-immediately ou non. Lorsque l’option est omise, la modification sera appliquée lors de la prochaine maintenance prévue. Ce détail de l’administration des instances RDS est mis en valeur dans la console :
Mises à jour mineures / majeures MySQL:
Parmi les intérêts à migrer dans le PaaS, figure bien entendu la prise en charge des passages de patches. Mais là, et contrairement à Azure ou GCP, il est possible de tout bonnement les activer ou désactiver via la console à la création de l’instance ou une fois que l’instance est déployée:
$ aws rds modify-db-instance --db-instance-identifier my57 \
--no-auto-minor-version-upgrade
La fenêtre utilisée pour passer ces patches mineurs sera la même que celle déjà employée pour les maintenances AWS.
Il sera même possible d’automatiser une montée de version majeure, par exemple 5.6 vers 5.7 en combinant les options –allow-major-version-upgrade et –engine-version mais cela n’est pas tellement conseillé. A noter qu’il aura au préalable fallu créer un Parameter Group compatible avec la version cible avant de migrer, et de recopier les modifications de paramètres de l’ancien vers le nouveau en utilisant la fonctionnalité de comparaison de PG comme vu dans l’article 1/2 précédent.
Arrêt et démarrage:
Trois commandes pour gérer l’arrêt / redémarrage:
$ aws rds stop-db-instance --db-instance-identifier my57 $ aws rds start-db-instance --db-instance-identifier my57 $ aws rds reboot-db-instance --db-instance-identifier my57
Deux petites remarques concernant l’arrêt:
– Si l’instance est un master de réplication, vers un ou plusieurs read replicas RDS, il ne pourra être supprimé. Il faudra supprimer les read replicas (voir plus bas Réplication…) ou les promouvoir en instances standalone avant de pouvoir stopper l’instance source.
– Si l’instance reste stoppée pendant plus de 7 jours, elle redémarrera … automatiquement au bout de 7 jours !
Si vous aviez en tête de couper une instance avant un départ en congés tout en pensant faire des économies, vous risquez d’avoir des surprises à votre retour 🙂
Les options qui restent sont soit de générer un snapshot et de supprimer l’instance si elle doit être coupée plus de 7 jours, soit bricoler une fonction Lambda qui vérifie son état et force un arrêt toutes les heures, ou toutes les 10 minutes…
Supervision et outils de diagnostics:
Toute instance RDS à sa création publie des métriques de fonctionnement qui seront capturées au niveau de l’hyperviseur et donc ne donneront qu’une vision globale de la performance. Il est possible d’augmenter le niveau de détail de cette supervision en activant la surveillance ‘améliorée’ ou enhanced monitoring:
Cette surveillance ‘améliorée’ donne de nouveau compteurs pris au niveau de l’instance cette fois et avec une granularité plus fine. Evidemment c’est une option payante qui sera facturée sur la base à la fois des instances concernées et du nombre de compteurs échantillonnés si la valeur dépasse ce qu’autorise le free-tier (soit compteurs samplés toutes les 5 minutes , soit 10 compteurs samplés toutes les minutes…, source ici).
Dans la console principale RDS, l’onglet Surveillance permet de visualiser les premiers métriques…
La surveillance améliorée peut aussi renvoyer la liste des processus actifs avec les valeurs d’utilisation CPU et mémoire sur l’hôte, mais je n’y vois que peu d’intérêt pour MySQL dans la mesure où le processus mysqld est multithreadé, contrairement aux backends PostgreSQL:
Les métriques capturés dans le cadre d’une surveillance ‘améliorée’ sont publiés sur Cloudwatch, la brique de supervision globale d’AWS, ils seront donc aussi accessibles ici, et conservés 30 jours. Cette valeur est modifiable depuis la console Cloudwatch (groupe de journaux RDSOSMetrics):
Dans la partie Métriques de Cloudwatch, les graphes peuvent alors être affichés sur tous les compteurs disponibles:
Dans l’exemple ci-dessous, une montée en charge des connexions est plafonnée par l’épuisement des crédits CPU et on voit la CPU bridée à 20% entre 09h45 et 11h15, comme déjà expliqué dans l’article 1/2 concernant le fonctionnement des Burstable Instances:
Déjà la surveillance ‘améliorée’ donne un certain nombre d’outils sur lequel il est possible de travailler, d’autant que cloudwatch est aussi accessible via aws cli et donc les métriques sont exportables. Mais si on veut aller encore plus loin, l’outil Performance Insights vient parachever le travail.
Performance Insights est une suite qui vient compléter l’offre de monitoring d’AWS pour les tiers RDS (hors sous classes micro et small), en permettant de combiner:
– Une soixantaine de compteurs OS .
– Une quarantaine de compteurs MySQL issus des variables de statut ou de compteurs dérivés calculés par RDS.
– Une intégration avec Performance Schema qui donne une visibilité sur les attentes, les statements, etc…
Pour activer Performance Insights et Performance Schema:
$ aws rds modify-db-instance --db-instance-identifier my57 \
--enable-performance-insights \
--performance-insights-retention-period 7
$ aws rds modify-db-parameter-group --db-parameter-group my57pg \
--parameters {"ParameterName=performance_schema,ParameterValue=1,
ApplyMethod=pending-reboot"
{
"DBParameterGroupName": "my57pg"
}
$ aws rds reboot-db-instance --db-instance-identifier my57
A partir de là, on va pouvoir depuis le tableau de bord de RDS analyser les requêtes triées par poste d’attente sachant que Performance Insights utilise la vue events_statements_summary_by_digest:
Enfin, il reste encore une dernière fonction pour faire de la collecte de compteurs de performance: le collecteur Global Status History.
On l’a dit les variables de status (SHOW GLOBAL STATUS) sont toutes disponibles pour être recueillies par des outils tiers type pt-mext. C’est le cas aussi pour GCP et Azure, mais là où AWS va encore plus loin, c’est dans l’implémentation d’un collecteur intégré à l’instance RDS qui s’appuie sur l’event scheduler interne de MySQL.
Ce collecteur va aller récupérer les valeurs de chaque variable de statut et stocker un différentiel ou une valeur brute selon le compteur, dans une table de la base mysql : rds_global_status_history. Ce Collecteur est complètement ‘gratuit’ au sens où on ne payera pas son utilisation. Par contre il y aura bien évidemment un coût pour la rétention des données au niveau du stockage.
Pour l’activer il faut d’abord activer event scheduler, et si vous êtes en 5.7 aussi show_compatibility_56 car il s’appuie toujours sur le fait que la vue global_history soit localisée dans information_schema (ce qui n’est plus le cas depuis la 5.7):
$ aws rds modify-db-parameter-group --db-parameter-group-name my57pg \ --parameters "ParameterName=event_scheduler,ParameterValue=ON, ParameterName=show_compatibility_56,ParameterValue=ON, ApplyMethod=immediate"
Ensuite, un jeu de procédures stockées rds% permettent de gérer la rétention et de démarrer le collecteur:
mysql> call mysql.rds_set_gsh_collector(30) \G *************************** 1. row *************************** Success: Collector Enabled every 30 Minutes, Scheduler is Active mysql> call mysql.rds_set_gsh_rotation(1) \G *************************** 1. row *************************** Success: Table Rotation Enabled every 1 Days, Scheduler is Active
Et il ne suffit plus que d’aller récupérer les valeur samplées pour les grapher avec votre outil favori:
mysql> select collection_end, variable_delta -> from mysql.rds_global_status_history -> where variable_name = 'CREATED_TMP_DISK_TABLES' -> and collection_end >= '2019-04-15 11:40:57'; +---------------------+----------------+ | collection_end | variable_delta | +---------------------+----------------+ | 2019-04-15 11:40:57 | 27 | | 2019-04-15 12:10:57 | 1341 | | 2019-04-15 12:40:57 | 1449 | | 2019-04-15 13:10:57 | 1595 | +---------------------+----------------+
Donc si on résume sur le même format que vu précédemment avec GCP et Azure, en termes d’outils d’aide au diagnostic:
| Analyse de performance générale | Disponibilité dans RDS |
|---|---|
| PERFORMANCE_SCHEMA | OK et interfacé avec Performance Insights |
| VARIABLES DE STATUT | OK et interfacé avec le collecteur GoSH |
| SHOW ENGINE INNODB STATUS | OK |
| PARAMETRES ORIENTES PERFORMANCES | Tous les paramètres sont disponibles. |
| Analyse de requêtes | Disponibilité dans RDS |
|---|---|
| EXPLAIN | OK |
| @@optimizer_switch | Mêmes remarques que pour GCP, BKA est à OFF par défaut, le paramètre n’est pas modifiable en GLOBAL |
| SET OPTIMIZER TRACE=1 | OK (dans la session) |
| Paramètres requêtes lentes | Tous les paramètres sont disponibles |
| SET PROFILING=1 | OK |
Alarmes Cloudwatch
Avant de refermer le sujet supervision, nous pouvons aussi évoquer les alarmes cloudwatch, qui s’appuient aussi sur la brique SNS pour la partie notification (email, SMS).
Dans le cas d’une instance MySQL / MariaDB sur RDS, il peut être intéressant de placer des alertes sur les critères suivants:
– CPUCreditBalance
– CPUUtilization
– FreeStorageSpace
– DatabaseConnections
Mais dans l’absolu tous les métriques en surveillance ‘améliorée’ peuvent servir de seuil d’alerte. Par exemple si je souhaite créer une alerte cloudwatch sur les crédits CPU restants d’une de mes instances t2 ou t3, et être notifié par email lorsque il ne reste plus que 10 crédits (soit 10 vCPUS à 100% pendant une minute):
1) D’abord créer le ‘topic’ SNS qui va porter la notification, nous en aurons besoin plus loin lors de la création de l’alerte:
$ aws sns create-topic --name "my57-topic"
{
"TopicArn": "arn:aws:sns:eu-west-3:XXXXXXXXXXXX:my57-topic"
}
2) Ensuite il faut souscrire à ce topic, c’est à dire s’abonner à la notification. Il y a 2 types d’abonnements email ou SMS, mais ce dernier n’est pas encore disponible en France, nous resterons donc sur une notification par email classique:
$ aws sns subscribe \
--topic-arn "arn:aws:sns:eu-west-3:XXXXXXXXXXXX:my57-topic" \
--protocol "email" \
--notification-endpoint "dbaffaleuf@capdata-osmozium.com"
{
"SubscriptionArn": "pending confirmation"
}
3) La souscription au topic va envoyer une demande confirmation à l’adresse indiquée, qu’il suffit de valider:
4) Enfin, créer l’alerte cloudwatch avec l’ARN du topic en réaction au déclenchement de l’alarme:
$ aws cloudwatch put-metric-alarm \ --alarm-name "my57creditBalance" \ --namespace "AWS/RDS" --metric-name "CPUCreditBalance" \ --statistic Average --period 300 --threshold 10 \ --comparison-operator LessThanOrEqualToThreshold \ --dimensions "Name=InstanceId,Value=my57" \ --alarm-actions "arn:aws:cloudwatch:eu-west-3:XXXXXXXXXXXX:alarm:my57-topic" --evaluation-periods 1
Lorsqu’elle sera déclenchée, elle sera notifiée par mail …
…et indiquée sur le tableau de bord de cloudwatch:
Haute disponibilité:
Si l’instance a été déployée en mode Mutli-AZ comme vu dans l’article précédent, elle dispose d’une instance standby prête à reprendre l’activité automatiquement dans plusieurs cas de figure:
1) une AZ entière est indisponible
2) l’instance primaire est inaccessible
3) le tier de l’instance primaire est modifié
4) une maintenance est en cours
5) ou un failover manuel est effectué :
$ aws rds reboot-db-instance --db-instance-identifier my57 \ --force-failover
Lors de la bascule, AWS modifie le DNS pour que la connexion pointe vers la standby. Les connexions existantes sont fermées et les transactions rollbackées. Le suivi des failovers peut se faire soit via notification SNS, soit describe-db-instance, soit via la publication des évènements AWS:
$ aws rds describe-events --source-identifier "my57" \ --source-type "db-instance" --event-categories "failover" (...) "Message": "Multi-AZ instance failover started. ", (...) "Message": "Multi-AZ instance failover completed",
Il est aussi possible de modifier le mode de déploiement à tout moment (Mono-AZ vers Multi-AZ):
$ aws rds modify-db-instance --db-instance-identifier my57 --multi-az --apply-immediately
Dans ce cas, il faut toutefois noter qu’un snapshot sera exécuté sur l’instance principale, copié dans une autre AZ et une instance standby sera déployée à partir de ce snapshot. Les instances seront maintenues en synchronisation grâce à un système de réplication synchrone au niveau du stockage, c’est pourquoi il est conseillé de privilégier des disques IO1 à IOPS provisionnés plutôt que des disques GP2 pour limiter l’impact sur les performances.
Réplication et read replicas:
3 possibilités pour faire de la réplication MySQL avec RDS:
– Soit depuis un master externe. Le master est on-premise ou sur EC2, et le slave est une instance RDS. Scénario de migration avec interruption faible typiquement.
– Soit vers un slave externe. Le master est une instance RDS, et le slave est on-premise ou sur EC2.
– Soit utilisation de read replicas.
Dans la mesure où la fonction de haute disponibilité est déjà assurée par RDS, ce besoin peut être écarté. Rien ne vous empêche de le faire quand même, mais je n’y vois pas un grand intérêt. Réplication logique asynchrone contre réplication du stockage synchrone, je pense qu’il vaut mieux laisser AWS gérer cette partie d’autant que la bascule de l’endpoint est géré avec.
RDS supporte la réplication asynchrone classique en binlog / position ou en GTID (semi-synchrone non supportée), à partir de la version 5.7.23+. Jusqu’à 5 read replicas peuvent être créés pour effectuer un scale-out en lecture:
$ aws rds create-db-instance-read-replica \ --db-instance-identifier "rr57" \ --source-db-instance-identifier "my57"
Ensuite la réplication peut être suivie via SHOW SLAVE STATUS, describe-db-instance sur le slave ou via le métrique ReplicaLag sur CloudWatch. On rappelle qu’un master ou un read replica ne peut plus être stoppé ensuite. Les read replicas doivent être supprimés avant de pouvoir stopper le master.
Coûts:
Comme chez les concurrents, il existe une calculette pour estimer les coûts d’un déploiement. Pour reprendre le même dimensionnement que ceux utilisés lors des articles précédents sur GCP et Azure:
– Tier db.m5.4xlarge, 16 vCPUs, 64Gb RAM, Multi-AZ, eu-west-3 (Paris)
– 200Gb io1 provisionnés à 5000 IOPS.
– 1Tb backup
La grosse différence dans le cas de RDS est que l’on aura provisionné des IOPS plutôt que des Gb et cela se ressent immédiatement sur la facture mensuelle:
Près de 3530€ par mois, et ne seront pas comptés le réseau, les métriques, alertes, etc… Si on prend juste le prix des instances master et standby, on est déjà au dessus des autres en termes de prix. La facture peut être réduite en utilisant des disques GP2 mais encore une fois en Multi-AZ et en production pour un dimensionnement tel que celui-là, ce ne sera pas trop conseillé… L’autre approche consiste à réserver l’instance sur 1 ou 3 ans: la même configuration coûterait 78228,95 euros en paiement all upfront contre 128590,74 euros en pay as you go sur trois ans, soit une économie de presque 40%.
GCP vs Azure vs RDS : le (re) match:
Sur le tableau final, et même s’il manque encore Aurora, si l’on cherche le meilleur compromis vis à vis du prix, on peut se tourner vers GCP qui offre déjà quelques fonctionnalités pour les instances qui sont faiblement à moyennement critiques. Je ne recommande pas Azure pour des questions de manageabilité.
Pour les instances plus critiques, avec des besoins en performances, souplesse et en outillage, clairement la solution sur AWS est la plus aboutie. Il faudra jouer avec le cost management pour tenter d’optimiser les coûts, mais du point de vue technique, si nous devions partir sur un PaaS pour une base MySQL critique, ce serait sur RDS sans l’ombre d’un doute.
Conclusion
J’espère que jusqu’ici cette série d’articles vous permet d’y voir plus clair sur les différences de fonctionnalités, et de mieux apprécier les différences de tarifs et ce qui conviendrait le mieux à votre activité.
Pour ma part, je trouve que l’offre d’Amazon est bien plus avancée que les 2 autres, même si l’addition est lourde à la fin du mois. Encore une fois on paye pour davantage de souplesse, et force est de constater que la limite entre ce que l’on peut faire on-prem et ce qui est possible dans le PaaS ici est nettement plus mince dans le cas de RDS, à tel point qu’on peut avoir du mal à réaliser parfois que c’est un service PaaS et pas une machine physique.
Il reste encore un gros morceau avant de refermer la boite MySQL dans le PaaS, la partie sur Aurora, pour une prochaine fois !
A bientôt pour la suite !
David.
Continuez votre lecture sur le blog :
- Comparatif MySQL dans le PaaS, épisode 3 : Amazon RDS (1/2) (David Baffaleuf) [AWSMySQL]
- Comparatif MySQL dans le PaaS, épisode 2 : Azure (David Baffaleuf) [AzureMySQL]
- Réplication MySQL : Resynchronisation d’un Slave MySQL (Capdata team) [MySQL]
- MySQL dans le PaaS : le radar de notation des solutions (David Baffaleuf) [AWSAzureGCPMySQL]
- Comparatif MySQL dans le PaaS, épisode 1 : Google Cloud SQL (David Baffaleuf) [GCPMySQL]