![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>A peine fini de dig\u00e9rer la premi\u00e8re partie<\/a>… Dans l’article pr\u00e9c\u00e9dent 1\/2 nous avions vu le contexte technique dans lequel les bases RDS \u00e9voluent, ainsi que les premiers \u00e9l\u00e9ments de d\u00e9couverte d’une instance MySQL ou MariaDB sur le cloud Amazon : limitations, connexion, configuration, etc…<\/p>\n Dans cette suite et fin, nous allons poursuivre notre exploration des fonctionnalit\u00e9s et terminer par un match comparatif entre les offres Azure, GCP et RDS. <\/p>\n Une fois allou\u00e9, que ce soit en GP2 ou en IO1, les caract\u00e9ristiques du stockage peuvent \u00eatre modifi\u00e9es \u00e0 chaud: – Son type peut \u00eatre modifi\u00e9:<\/p>\n – Ses IOPS provisionn\u00e9s peuvent \u00eatre modifi\u00e9s:<\/p>\n La transition peut s’\u00e9taler sur une p\u00e9riode plus ou moins longue en fonction du type de modification, mais pendant cette p\u00e9riode transitoire, l’instance va entrer dans un mode ‘storage optimization’<\/em> …<\/p>\n … durant lequel elle n’accepte plus d’autre changement au niveau stockage. On ne pourra donc pas modifier une caract\u00e9ristique puis une autre dans la foul\u00e9e, il faudra bien r\u00e9fl\u00e9chir \u00e0 la s\u00e9quence des modifications \u00e0 r\u00e9aliser avant de se lancer:<\/p>\n Autre remarque,contrairement \u00e0 GCP, il n’y a pas d’auto scaling du stockage sur AWS, ce qui veut dire que des alarmes sur seuil doivent \u00eatre mises en place pour \u00e9viter un remplissage intempestif. Ces alarmes sont g\u00e9r\u00e9es par les briques de supervision Cloudwatch et SNS:<\/p>\n Nous verrons un autre exemple d’utilisation de cloudwatch et SNS un peu plus loin dans la section Supervision et outils de diagnostics<\/em>. <\/p>\n Comme sur Azure, il existe un m\u00e9canisme de protection contre la suppression d’instance activ\u00e9 par d\u00e9faut: …de sorte qu’une suppression par erreur est impossible:<\/p>\n Par d\u00e9faut les logs binaires au format MIXED sont activ\u00e9s, pour permettre d’assurer une restauration point-in-time en \u00e9tant coupl\u00e9s avec des snapshots au niveau stockage. En sachant que les 2 autres formats (STATEMENT, ROW) sont aussi support\u00e9s \u00e0 partir de la 5.6+. <\/p>\n L\u00e0 encore un gros avantage en termes de manageabilit\u00e9, la possibilit\u00e9 offerte de d\u00e9coder les logs binaires \u00e0 distance via le client mysqlbinlog et l’option –read-from-remote-server<\/em> :<\/p>\n Encore une fonctionnalit\u00e9 qui ferait presque oublier qu’on a affaire \u00e0 une instance en PaaS \ud83d\ude42<\/p>\n 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 \u00e0 la r\u00e9tention, qui peut \u00eatre g\u00e9r\u00e9e via des proc\u00e9dures stock\u00e9es :<\/p>\n Enfin, et hors cas de r\u00e9plication, il est aussi possible de d\u00e9sactiver les logs binaires bien que ce ne soit pas conseill\u00e9 car plus de possibilit\u00e9 de restaurer \u00e0 un point pr\u00e9cis dans le temps, en passant la valeur de backup-retention-period de l’instance \u00e0 0<\/a>.<\/p>\n 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\u00e9n\u00e9ficie de COPY via S3 depuis le 24 avril<\/a>, \u00e7a viendra peut \u00eatre plus t\u00f4t qu’on ne le pense…<\/p>\n En dehors de cela, pas trouv\u00e9 grand chose \u00e0 se mettre sous la dent pour l’export de donn\u00e9es, en dehors de mysqldump ou du bricolage via un SELECT CONCAT pour produire du CSV en sortie…<\/p>\n Pas mieux. <\/p>\n Sinon l’autre alternative serait d’utiliser AWS Data Pipeline<\/a> mais l\u00e0 on touche \u00e0 un ETL d\u00e9di\u00e9 et potentiellement un sujet \u00e0 part enti\u00e8re, qui ferait sans doute un bon candidat pour un prochain article … en deux parties \ud83d\ude42 je n’ai donc pas creus\u00e9 le sujet plus loin que \u00e7a pour l’instant. <\/p>\n Pour les volum\u00e9tries importantes, il est possible de passer par un backup physique<\/a> g\u00e9n\u00e9r\u00e9 par Percona Xtrabackup <\/a>dont l’archive serait \u00e0 copier sur S3, et \u00e0 int\u00e9grer ensuite dans une nouvelle instance RDS en utilisant aws rds restore-db-instance-from-s3. <\/p>\n Ce qui nous am\u00e8ne \u00e0 la question de sauvegarde et restauration. <\/p>\n Dans le PaaS Amazon, comme dans les autres PaaS, les backups sont pris en charge automatiquement. Les logs binaires \u00e9tant activ\u00e9s par d\u00e9faut, l’ensemble fournit une solution robuste de restauration point-in-time pour peu que toutes les tables soient cr\u00e9\u00e9es en InnoDB. <\/p>\n Le premier snapshot est pris \u00e0 la cr\u00e9ation de l’instance, il contient l’int\u00e9gralit\u00e9 du stockage utilis\u00e9, de sorte que les snapshots suivants se contenteront de capturer un incr\u00e9mental de l’activit\u00e9. <\/p>\n La plage de sauvegarde est param\u00e9trable ainsi que la r\u00e9tention (0-35 jours, 7 jours par d\u00e9faut via la console, 1 jour via API\/aws cli):<\/p>\n Comme sur Azure, l’espace de backup sur RDS reste hors charges tant qu’il ne d\u00e9passe pas la valeur de ce qui a \u00e9t\u00e9 provisionn\u00e9 en stockage de donn\u00e9es. Par ailleurs, cet espace de backup est partag\u00e9 par toutes les instances d’un m\u00eame compte et d’une m\u00eame r\u00e9gion. Donc il faut estimer l’espace global de backup par rapport \u00e0 l’espace global provisionn\u00e9 pour toutes les instances RDS m\u00eame compte \/ m\u00eame r\u00e9gion, et pas uniquement instance par instance. <\/p>\n Sur les d\u00e9ploiements Multi-AZ, le backup est effectu\u00e9 sur l’instance standby pour ne pas p\u00e9naliser les IO sur l’instance nominale. <\/p>\n Autre avantage par rapport \u00e0 la concurrence, \u00e0 la suppression de l’instance, il est possible de conserver les snapshots automatiques, et\/ou d’en cr\u00e9er un suppl\u00e9mentaire avant de supprimer d\u00e9finitivement l’instance :<\/p>\n En plus des backups automatiques, des backups additionnels en plus des backups automatiques peuvent \u00eatre effectu\u00e9s (50 maximum par r\u00e9gion): <\/p>\n Dans le cas d’une restauration, de m\u00eame que pour les autres solutions cloud, le snapshot sera n\u00e9cessairement restaur\u00e9 sur une nouvelle instance RDS<\/strong>, le terme restauration est un peu usurp\u00e9… Il faudra donc prendre le soin de renommer l’ancienne instance avant de restaurer en r\u00e9utilisant son nom:<\/p>\n Il faut aussi penser qu’en changeant le nom, un certain nombre d’identifiants vont aussi changer comme l’ARN<\/a> de la ressource, et l’endpoint. Lorsque le renommage est effectu\u00e9, les applications ne pourront plus se connecter tant que la nouvelle instance n’est pas recr\u00e9\u00e9e \u00e0 partir du snapshot de l’ancienne. <\/p>\n La bonne nouvelle c’est que le Security Group<\/em> et le Parameter Group<\/em> seront tous les deux imm\u00e9diatement r\u00e9utilisables dans la commande de restauration:<\/p>\n Pour la restauration point-intime, une propri\u00e9t\u00e9 accessible via describe-db-instances<\/em> permet de donner l’heure la plus r\u00e9cente \u00e0 laquelle il sera possible de restaurer:<\/p>\n Enfin, le snapshot peut aussi servir en r\u00e8gle g\u00e9n\u00e9rale outre restaurer des donn\u00e9es, \u00e0 d\u00e9placer une instance d’une AZ vers une autre, d’une r\u00e9gion vers une autre ou d’un compte vers un autre. <\/p>\n AWS effectue r\u00e9guli\u00e8rement des mises \u00e0 jour du mat\u00e9riel et des OSes qui supportent l’infrastructure de RDS. Ces maintenances peuvent n\u00e9cessiter une mise hors-ligne de l’instance, donc une indisponibilit\u00e9. <\/p>\n Il est possible de choisir \u00e0 la cr\u00e9ation de l’instance la fen\u00eatre de maintenance d\u00e9sir\u00e9e… Attention, l’heure de passage des maintenances est en heure UTC, donc gare aux surprises lors des passages en heures d’\u00e9t\u00e9 \/ hiver en France …<\/p>\n Pour v\u00e9rifier si une maintenance est pr\u00e9vue:<\/p>\n On peut egalement choisir d’appliquer une mise \u00e0 jour en la for\u00e7ant sans attendre la prochaine fen\u00eatre de maintenance:<\/p>\n Note sur –apply-immediately<\/strong>: certaines modifications de l’instance peuvent \u00eatre effectu\u00e9es \u00e0 chaud, mais nous conservons le choix de l’appliquer imm\u00e9diatement en utilisant –apply-immediately<\/em> ou non. Lorsque l’option est omise, la modification sera appliqu\u00e9e lors de la prochaine maintenance pr\u00e9vue. Ce d\u00e9tail de l’administration des instances RDS est mis en valeur dans la console : <\/p>\n Parmi les int\u00e9r\u00eats \u00e0 migrer dans le PaaS, figure bien entendu la prise en charge des passages de patches. Mais l\u00e0, et contrairement \u00e0 Azure ou GCP, il est possible de tout bonnement les activer ou d\u00e9sactiver via la console \u00e0 la cr\u00e9ation de l’instance ou une fois que l’instance est d\u00e9ploy\u00e9e:<\/p>\n La fen\u00eatre utilis\u00e9e pour passer ces patches mineurs sera la m\u00eame que celle d\u00e9j\u00e0 employ\u00e9e pour les maintenances AWS. <\/p>\n Il sera m\u00eame possible d’automatiser une mont\u00e9e 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\u00e9. A noter qu’il aura au pr\u00e9alable fallu cr\u00e9er un Parameter Group<\/em> compatible avec la version cible avant de migrer, et de recopier les modifications de param\u00e8tres de l’ancien vers le nouveau en utilisant la fonctionnalit\u00e9 de comparaison de PG comme vu dans l’article 1\/2 pr\u00e9c\u00e9dent<\/a>. <\/p>\n Trois commandes pour g\u00e9rer l’arr\u00eat \/ red\u00e9marrage:<\/p>\n Deux petites remarques concernant l’arr\u00eat: Si vous aviez en t\u00eate de couper une instance avant un d\u00e9part en cong\u00e9s tout en pensant faire des \u00e9conomies, vous risquez d’avoir des surprises \u00e0 votre retour \ud83d\ude42 <\/p>\n Les options qui restent sont soit de g\u00e9n\u00e9rer un snapshot et de supprimer l’instance si elle doit \u00eatre coup\u00e9e plus de 7 jours, soit bricoler une fonction Lambda<\/a> qui v\u00e9rifie son \u00e9tat et force un arr\u00eat toutes les heures, ou toutes les 10 minutes… <\/p>\n Toute instance RDS \u00e0 sa cr\u00e9ation publie des m\u00e9triques de fonctionnement qui seront captur\u00e9es 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\u00e9tail de cette supervision en activant la surveillance ‘am\u00e9lior\u00e9e’ ou enhanced monitoring<\/em>: <\/p>\n Cette surveillance ‘am\u00e9lior\u00e9e’ donne de nouveau compteurs pris au niveau de l’instance cette fois et avec une granularit\u00e9 plus fine. Evidemment c’est une option payante qui sera factur\u00e9e sur la base \u00e0 la fois des instances concern\u00e9es et du nombre de compteurs \u00e9chantillonn\u00e9s si la valeur d\u00e9passe ce qu’autorise le free-tier (soit compteurs sampl\u00e9s toutes les 5 minutes , soit 10 compteurs sampl\u00e9s toutes les minutes…, source ici<\/a>). <\/p>\n Dans la console principale RDS, l’onglet Surveillance permet de visualiser les premiers m\u00e9triques…<\/p>\n La surveillance am\u00e9lior\u00e9e peut aussi renvoyer la liste des processus actifs avec les valeurs d’utilisation CPU et m\u00e9moire sur l’h\u00f4te, mais je n’y vois que peu d’int\u00e9r\u00eat pour MySQL dans la mesure o\u00f9 le processus mysqld est multithread\u00e9, contrairement aux backends PostgreSQL:<\/p>\n Les m\u00e9triques captur\u00e9s dans le cadre d’une surveillance ‘am\u00e9lior\u00e9e’ sont publi\u00e9s sur Cloudwatch<\/a>, la brique de supervision globale d’AWS, ils seront donc aussi accessibles ici, et conserv\u00e9s 30 jours. Cette valeur est modifiable depuis la console Cloudwatch (groupe de journaux RDSOSMetrics): Dans l’exemple ci-dessous, une mont\u00e9e en charge des connexions est plafonn\u00e9e par l’\u00e9puisement des cr\u00e9dits CPU et on voit la CPU brid\u00e9e \u00e0 20% entre 09h45 et 11h15, comme d\u00e9j\u00e0 expliqu\u00e9 dans l’article 1\/2<\/a> concernant le fonctionnement des Burstable Instances<\/em>: D\u00e9j\u00e0 la surveillance ‘am\u00e9lior\u00e9e’ 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\u00e9triques sont exportables. Mais si on veut aller encore plus loin, l’outil Performance Insights<\/a> vient parachever le travail. <\/p>\n Performance Insights est une suite qui vient compl\u00e9ter l’offre de monitoring d’AWS pour les tiers RDS (hors sous classes micro et small), en permettant de combiner: Pour activer Performance Insights et Performance Schema:<\/p>\n A partir de l\u00e0, on va pouvoir depuis le tableau de bord de RDS analyser les requ\u00eates tri\u00e9es par poste d’attente sachant que Performance Insights utilise la vue events_statements_summary_by_digest<\/a>:<\/p>\n Enfin, il reste encore une derni\u00e8re fonction pour faire de la collecte de compteurs de performance: le collecteur Global Status History<\/a>. <\/p>\n On l’a dit les variables de status (SHOW GLOBAL STATUS) sont toutes disponibles pour \u00eatre recueillies par des outils tiers type pt-mext<\/a>. C’est le cas aussi pour GCP et Azure, mais l\u00e0 o\u00f9 AWS va encore plus loin, c’est dans l’impl\u00e9mentation d’un collecteur int\u00e9gr\u00e9 \u00e0 l’instance RDS qui s’appuie sur l’event scheduler interne de MySQL. <\/p>\n Ce collecteur va aller r\u00e9cup\u00e9rer les valeurs de chaque variable de statut et stocker un diff\u00e9rentiel ou une valeur brute selon le compteur, dans une table de la base mysql : rds_global_status_history<\/em>. Ce Collecteur est compl\u00e8tement ‘gratuit’ au sens o\u00f9 on ne payera pas son utilisation. Par contre il y aura bien \u00e9videmment un co\u00fbt pour la r\u00e9tention des donn\u00e9es au niveau du stockage.<\/p>\n Pour l’activer il faut d’abord activer event scheduler<\/em>, et si vous \u00eates en 5.7 aussi show_compatibility_56<\/em> car il s’appuie toujours sur le fait que la vue global_history <\/em>soit localis\u00e9e dans information_schema (ce qui n’est plus le cas depuis la 5.7):<\/p>\n Ensuite, un jeu de proc\u00e9dures stock\u00e9es rds% permettent de g\u00e9rer la r\u00e9tention et de d\u00e9marrer le collecteur:<\/p>\n Et il ne suffit plus que d’aller r\u00e9cup\u00e9rer les valeur sampl\u00e9es pour les grapher avec votre outil favori:<\/p>\n Donc si on r\u00e9sume sur le m\u00eame format que vu pr\u00e9c\u00e9demment avec GCP et Azure, en termes d’outils d’aide au diagnostic:<\/p>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/mysqlRDS_part2.png\")
\nRappel des \u00e9pisodes pr\u00e9c\u00e9dents :
\n– \u00e9pisode 1 : MySQL sur Google Cloud platform<\/a>.
\n– \u00e9pisode 2 : MySQL et MariaDB sur Microsoft Azure<\/a>.
\n– \u00e9pisode 3 1\/2 : MySQL et MariaDB dans Amazon RDS 1\/2<\/a><\/p>\nMySQL et MariaDB sur RDS (suite)<\/h2>\n
Gestion du stockage:<\/h3>\n
\n– Sa capacit\u00e9 peut \u00eatre augment\u00e9e (mais pas r\u00e9duite):<\/p>\n\r\n$ aws rds modify-db-instance --db-instance-identifier my57 \\\r\n\t--allocated-storage 30 --apply-immediately\r\n<\/pre>\n
\r\n$ aws rds modify-db-instance --db-instance-identifier my57 \\\r\n\t--storage-type io1 --apply-immediately\r\n<\/pre>\n
\r\n$ aws rds modify-db-instance --db-instance-identifier my57 \\\r\n\t--storage-type io1 --allocated-storage 200 \\\r\n\t--iops 3000 --apply-immediately\r\n<\/pre>\n
\r\n$ aws rds describe-db-instances --db-instance-identifier my57\r\n(...)\r\n\t"DBInstanceStatus": "storage-optimization",\r\n(...)\r\n<\/pre>\n
\r\n$ aws rds modify-db-instance --db-instance-identifier my57 \\\r\n\t--allocated-storage 40 --apply-immediately\r\nAn error occurred (InvalidParameterCombination) when calling the \r\nModifyDBInstance operation: You can't currently modify the storage \r\nof this DB instance because the previous storage change is being \r\noptimized.\r\n<\/pre>\n
\r\n$ aws cloudwatch put-metric-alarm --alarm-name "err-low-storage" \\\r\n\t--metric-name "FreeStorageSpace" --namespace "AWS\/RDS" \\\r\n\t--statistic "Average" --period 600 --evaluation-periods 1 \\\r\n\t--threshold 10 --unit Percent \\\r\n\t--comparison-operator "LessThanOrEqualToThreshold" \\\r\n\t--dimensions "Name=DBInstanceIdentifier,Value=my57" \\\r\n\t--alarm-actions "arn:aws:sns:eu-west-3:XXXXXXXXXXX:my-sns-target"\r\n<\/pre>\n
Protection contre la suppression:<\/h3>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS13.png\")
\nLa propri\u00e9t\u00e9 est expos\u00e9e par describe-db-instances<\/em>…<\/p>\n\r\n$ aws rds modify-db-instance --db-instance-identifier my57 \\\r\n\t--deletion-protection \r\n\r\n$ aws rds describe-db-instances --db-instance-identifier my57 \r\n(...) "DeletionProtection": true, (...)\r\n<\/pre>\n
\r\n$ aws rds delete-db-instance --db-instance-identifier my57 \\\r\n\t--skip-final-snapshot\r\nAn error occurred (InvalidParameterCombination) when calling \r\nthe DeleteDBInstance operation: Cannot delete protected DB Instance,\r\n please disable deletion protection and try again.\r\n<\/pre>\n
Gestion des logs binaires:<\/h3>\n
\r\n$ mysqlbinlog --read-from-remote-server \\\r\n\t--host=my57.xxxxxxxxx.eu-west-3.rds.amazonaws.com \\\r\n\t--port=3306 --user=my57_user \\\r\n\t--base64-output=DECODE-ROWS --verbose --password \\\r\n\tmysql-bin-changelog.000359 \r\nEnter password: ************\r\n\/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*\/;\r\n\/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*\/;\r\nDELIMITER \/*!*\/;\r\n# at 4\r\n#190404 11:45:00 server id 556576755 end_log_pos 123 CRC32 0x27f680cd \r\nStart: binlog v 4, server v 5.7.25-log created 190404 11:45:00\r\n(...)\r\n<\/pre>\n
\r\nmysql> call mysql.rds_show_configuration() ;\r\n+------------------------+-------+------------------------------------...\r\n| name | value | description\t\t\t ...\r\n+------------------------+-------+------------------------------------...\r\n| binlog retention hours | NULL | binlog retention hours specifies th...\r\n| source delay | 0 | source delay specifies replication...\r\n| target delay | 0 | target delay specifies replication...\r\n+------------------------+-------+------------------------------------...\r\n\r\nmysql> call mysql.rds_set_configuration("binlog retention hours", 96) ;\r\nQuery OK, 0 rows affected (0.02 sec)\r\n<\/pre>\nExport \/ import de donn\u00e9es:<\/h3>\n
\r\n$ mysql --login-path=rds57 --batch \\\r\n--execute="SELECT CONCAT(actor_id,',\\"',first_name,'\\",\\"',last_name,'\\",\\"', last_update,'\\"') FROM sakila.actor;" > ~\/actor.csv\r\n<\/pre>\n
Sauvegarde et restauration:<\/h3>\n
\r\n$ aws rds describe-db-instances --db-instance-identifier my57\r\n(...)"PreferredBackupWindow": "23:00-23:30",\r\n"BackupRetentionPeriod": 7, (...)\r\n<\/pre>\n
\r\n$ aws rds delete-db-instances --db-instance-identifier my57 \\\r\n\t--no-delete-automated-backups --no-skip-final-snapshot \\\r\n\t--final-db-snapshot-identifier "my57.KEEP.bak"\r\n<\/pre>\n
\r\n$ aws rds create-db-snapshot --db-instance-identifier my57 \\\t\r\n\t--db-snapshot-identifier "my57-20190404-1456-BAK" \\\r\n\t--tags "Key=DateCr,Value=20190404-1456"\r\n<\/pre>\n
\r\n$ aws rds modify-db-instance --db-instance-identifier my57 \\\r\n\t--new-db-instance-identifier my57old --apply-immediately\r\n<\/pre>\n
\r\n$ aws rds restore-db-instance-from-db-snapshot \\\r\n\t--db-instance-identifier my57 \\\r\n\t--db-snapshot-identifier "my57-20190404-1456-bak" \\\r\n\t--availability-zone "eu-west-3a" \\\r\n\t--db-parameter-group-name "my57pg" \\\r\n\t--vpc-security-group-ids "sg-xxxxxxxxxxxxxxxx"\r\n<\/pre>\n
\r\n$ aws rds describe-db-instances --db-instance-identifier my57old\r\n(...) "LatestRestorableTime": "2019-04-04T13:55:00Z", (...)\r\n\r\n$ aws rds restore-db-instance-to-point-in-time \\\r\n\t--source-db-instance-identifier my57old \\\r\n\t--target-db-instance-identifier my57 \\\r\n\t--restore-time "2019-04-04T13:55:00Z" \\\r\n\t--db-parameter-group-name "my57pg" \\\r\n\t--vpc-security-group-ids "sg-xxxxxxxxxxxxxxxx"\r\n<\/pre>\n
Fen\u00eatres de maintenance:<\/h3>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS14.png\")
\n… ou de la modifier plus tard via la console, l’API ou le CLI:<\/p>\n\r\n$ aws rds modify-db-instance --db-instance-identifier my57 \\\r\n\t--preferred-maintenance-window "sun:01:00-sun:01:30" \\\r\n\t--apply-immediately\r\n<\/pre>\n
\r\n$ aws rds describe-pending-maintenance-actions \\\r\n\t--resource-identifier "arn:aws:rds:eu-west-3:xxxxxxxxxxxxx:db:my57"\r\n"PendingMaintenanceActionDetails": [\r\n {\r\n "Action": "system-update",\r\n "Description": "Performance improvements and security updates",\r\n "CurrentApplyDate": "2019-04-22T03:04:00Z",\r\n "AutoAppliedAfterDate": "2019-04-26T19:41:22Z",\r\n "OptInStatus": "next-maintenance"\r\n }\r\n],\r\n<\/pre>\n\r\n$ aws rds apply-pending-maintenance-action \\\r\n --resource-identifier "arn:aws:rds:eu-west-3:xxxxxxxxxxxxx:db:my57" \\\r\n --apply-action system-update \\\r\n --opt-in-type immediate\r\n<\/pre>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS15.png\")
<\/p>\nMises \u00e0 jour mineures \/ majeures MySQL:<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS16.png\")
<\/p>\n\r\n$ aws rds modify-db-instance --db-instance-identifier my57 \\\r\n --no-auto-minor-version-upgrade\r\n<\/pre>\n
Arr\u00eat et d\u00e9marrage:<\/h3>\n
\r\n$ aws rds stop-db-instance --db-instance-identifier my57\r\n$ aws rds start-db-instance --db-instance-identifier my57\r\n$ aws rds reboot-db-instance --db-instance-identifier my57\r\n<\/pre>\n
\n– Si l’instance est un master de r\u00e9plication, vers un ou plusieurs read replicas RDS, il ne pourra \u00eatre supprim\u00e9. Il faudra supprimer les read replicas (voir plus bas R\u00e9plication<\/em>…) ou les promouvoir en instances standalone avant de pouvoir stopper l’instance source.
\n– Si l’instance reste stopp\u00e9e pendant plus de 7 jours, elle red\u00e9marrera … automatiquement au bout de 7 jours !<\/strong><\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS17.png\")
<\/p>\nSupervision et outils de diagnostics:<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS18.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS19.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS20-1024x214.png\")
<\/p>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS21.png\")
\nDans la partie M\u00e9triques <\/em>de Cloudwatch, les graphes peuvent alors \u00eatre affich\u00e9s sur tous les compteurs disponibles:<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS23.png\")
<\/p>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS22-1024x386.png\")
<\/p>\n
\n– Une soixantaine de compteurs OS<\/a> .
\n– Une quarantaine de compteurs MySQL<\/a> issus des variables de statut ou de compteurs d\u00e9riv\u00e9s calcul\u00e9s par RDS.
\n– Une int\u00e9gration avec Performance Schema qui donne une visibilit\u00e9 sur les attentes, les statements, etc…<\/p>\n\r\n$ aws rds modify-db-instance --db-instance-identifier my57 \\\r\n\t--enable-performance-insights \\\r\n\t--performance-insights-retention-period 7\r\n\r\n$ aws rds modify-db-parameter-group --db-parameter-group my57pg \\\r\n\t--parameters {"ParameterName=performance_schema,ParameterValue=1,\r\n ApplyMethod=pending-reboot"\r\n{\r\n "DBParameterGroupName": "my57pg"\r\n}\r\n\r\n$ aws rds reboot-db-instance --db-instance-identifier my57\r\n<\/pre>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS24-1024x425.png\")
<\/a><\/p>\n\r\n$ aws rds modify-db-parameter-group --db-parameter-group-name my57pg \\\r\n --parameters "ParameterName=event_scheduler,ParameterValue=ON, \t\r\n\tParameterName=show_compatibility_56,ParameterValue=ON, \t\r\n\tApplyMethod=immediate"\r\n<\/pre>\n
\r\nmysql> call mysql.rds_set_gsh_collector(30) \\G\r\n*************************** 1. row ***************************\r\nSuccess: Collector Enabled every 30 Minutes, Scheduler is Active\r\n\r\nmysql> call mysql.rds_set_gsh_rotation(1) \\G\r\n*************************** 1. row ***************************\r\nSuccess: Table Rotation Enabled every 1 Days, Scheduler is Active\r\n<\/pre>\n
\r\nmysql> select collection_end, variable_delta\r\n-> from mysql.rds_global_status_history\r\n-> where variable_name = 'CREATED_TMP_DISK_TABLES'\r\n-> and collection_end >= '2019-04-15 11:40:57';\r\n+---------------------+----------------+\r\n| collection_end | variable_delta |\r\n+---------------------+----------------+\r\n| 2019-04-15 11:40:57 | 27 |\r\n| 2019-04-15 12:10:57 | 1341 |\r\n| 2019-04-15 12:40:57 | 1449 |\r\n| 2019-04-15 13:10:57 | 1595 |\r\n+---------------------+----------------+\r\n<\/pre>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS25-2.png\")
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS26.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS27.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS28-1024x261.png\")
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS29-1024x593.png\")