![\"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>Rappel des \u00e9pisodes pr\u00e9c\u00e9dents : Bon alors l\u00e0 \u00e7a devient compliqu\u00e9. Volet 1\/2 de l’\u00e9pisode 3 \u00e7a commence \u00e0 ressembler au code civil cette affaire…<\/p>\n Il faut r\u00e9aliser \u00e0 quel point l’offre PaaS d’Amazon est nettement plus avanc\u00e9e que les autres : \u00e0 th\u00e8me \u00e9gal (limitations, connectivit\u00e9, configuration, performance, MCO, haute dispo, r\u00e9plication, co\u00fbts, etc…) il y a – beaucoup <\/strong>– plus de choses \u00e0 dire sur RDS. Et si on veut que cela reste lisible, il faut d\u00e9couper en deux parties. <\/p>\n Quand je repense qu’au d\u00e9part il ne devait y avoir que 3 \u00e9pisodes avec MySQL et Aurora dans le m\u00eame article, j’\u00e9tais optimiste… Il y aura donc encore un \u00e9pisode 4 en deux articles au moins juste pour parler d’Aurora. <\/p>\n Bref dans cet \u00e9pisode 3 partie 1\/2, nous allons d\u00e9couvrir le contexte technique dans lequel une base RDS peut \u00e9voluer : r\u00e9gions, AZ, tiers, stockage, etc… Ce que je vais dire ici s’applique aussi aux autres bases de donn\u00e9es dans RDS, c’est d’ailleurs un atout important pour Amazon, l’homog\u00e9n\u00e9it\u00e9 des fonctions et des m\u00e9thodes, de sorte que l’on s’y retrouve en passant d’un SGBD \u00e0 un autre. <\/p>\n On entrera un peu dans le sujet MySQL sur les questions initiales de limitations, d\u00e9ploiement, configuration, acc\u00e8s aux logs, etc… Puis nous verrons la suite et le comparatif final dans le volet 2\/2. <\/p>\n 1\/2, clap, c’est parti.<\/p>\n D\u00e9j\u00e0 quelques \u00e9l\u00e9ments de contexte. RDS est une des principales briques historiques du cloud d’Amazon avec S3 et EC2. Ce cloud s’appuie sur une infrastructure d\u00e9ploy\u00e9e sur 4 et bient\u00f4t 5 continents. Rien qu’en Europe nous avons 5 r\u00e9gions ou pays dans lesquels des infrastructures sont d\u00e9ploy\u00e9es: Irlande, Londres, Francfort, Stockholm et Paris. Milan sera la 6i\u00e8me r\u00e9gion d\u00e9ploy\u00e9e. <\/p>\n Chaque r\u00e9gion compte 3 zones de disponibilit\u00e9 ou AZ, et si vous avez suivi les \u00e9pisodes pr\u00e9c\u00e9dents rien n’est vraiment diff\u00e9rent de GCP ou Azure. Une AZ peut \u00eatre vue comme un datacenter mettant \u00e0 disposition des ressources de calcul, stockage, d’interconnexion r\u00e9seau, ainsi que des briques applicatives. Dans le monde AWS, on parle de Mono-AZ <\/em>ou de Multi-AZ<\/em> pour \u00e9voquer le niveau de distribution d’une brique comme RDS:<\/p>\n En mode Mono-AZ \u00e0 gauche sur le sch\u00e9ma, notre instance RDS serait isol\u00e9e dans une seule AZ. Les \u00e9quipements confin\u00e9s \u00e0 l’AZ sont redond\u00e9s comme les hyperviseurs, le stockage, etc… mais il n’y a pas de secours en cas de perte de l’AZ compl\u00e8te. A droite en revanche, une instance en d\u00e9ploiement Multi-AZ est secourue par une seconde instance de standby dans une autre zone de disponibilit\u00e9, l’\u00e9quivalent du failover replica sur GCP, et donc sans \u00e9quivalence sur Azure. <\/p>\n Le mode de d\u00e9ploiement est choisi lors de la cr\u00e9ation de l’instance mais peut aussi \u00eatre modifi\u00e9 plus tard. Evidemment Multi-AZ signifie aussi surco\u00fbt, nous verrons ces aspects un peu plus loin. <\/p>\n Deux modes disponibles: Si on compare le co\u00fbt d’une instance de type db.m5.xlarge sur 1 an en pay-as-you-go ou en r\u00e9servation:<\/p>\n On voit que l’\u00e9conomie est d\u00e9j\u00e0 substantielle par rapport au prix de l’instance:<\/p>\n Sur les plus grosses configurations et sur un engagement de 3 ans, l’\u00e9conomie peut \u00eatre encore plus importante (50K$ sur 3 ans pour une instance de type db.r5.4xlarge \u00e0 5000$ par mois en pay-as-you-go). Cela va donc d\u00e9pendre des capacit\u00e9s de financement et des objectifs \u00e0 moyen terme. Mais c’est d\u00e9j\u00e0 une premi\u00e8re avance sur les concurrents qui n’offrent pas de capacit\u00e9 de r\u00e9servation sur toute leur gamme de bases en mode PaaS. <\/p>\n Deux grandes classes de tiers sont disponibles: La tarification \u00e9tant susceptible de changer, il vaut mieux se r\u00e9f\u00e9rer \u00e0 la source officielle<\/a> pour un pricing pr\u00e9cis.<\/p>\n Le stockage utilisable sur RDS est bas\u00e9 sur la brique EBS : Elastic Block Storage, qui est l’autre grosse brique stockage d’Amazon avec S3. Si S3 est orient\u00e9e fichiers, EBS est un peu comme un block storage sous st\u00e9roides : encryption, snapshots, r\u00e9plication intra-AZ, scalabilit\u00e9 en capacit\u00e9 et en IOPS provisionn\u00e9s… <\/p>\n 2 types de stockage seront disponibles :<\/strong><\/p>\n – General Purpose ou GP2<\/strong>: c’est un stockage SSD classique pour lequel on provisionne une capacit\u00e9 pour obtenir des IOPS, comme cela se fait chez GCP ou Azure. <\/p>\n Le syst\u00e8me est calibr\u00e9 pour donner 3 IOPS\/Gb avec un plafond \u00e0 16000 IOPS atteint \u00e0 5Tb. La diff\u00e9rence est que pour des volumes inf\u00e9rieurs \u00e0 1Tb (aire ‘A’ sur le sch\u00e9ma ci-dessous), le syst\u00e8me peut solliciter des pics au del\u00e0 de ses 3 IOPS \/Gb en utilisant des cr\u00e9dits d’IOPS<\/a>. Tant que le syst\u00e8me est idle, il accumule des cr\u00e9dits d’IOPS qui lui permettent ensuite de pouvoir effectuer des pics \u00e0 3000 IOPS jusqu’\u00e0 \u00e9puisement de ses cr\u00e9dits:<\/p>\n Au del\u00e0 de 1Tb, les IOPS sont fixes de 3000 jusqu’\u00e0 16000 en fonction de la volum\u00e9trie. <\/p>\n – Le deuxi\u00e8me type de stockage est Provisionned SSD ou IO1<\/strong> : aussi bas\u00e9 sur des disques SSD, plus performants, mais surtout dans ce cas, on ne provisionne plus une capacit\u00e9 disque mais un nombre d’IOPS. Ce qui veut dire que l’on peut provisionner seulement 200Gb de disque tout en garantissant 5000 IOPS par exemple. C\u00f4t\u00e9 Amazon, cela signifie que notre petite LUN de 200Gb doit \u00eatre probablement stripp\u00e9e sur plusieurs disques, ce qui revient suppos\u00e9ment assez cher et complexe \u00e0 maintenir pour Amazon, et donc le prix sur la facture est aussi non n\u00e9gligeable. <\/p>\n Evidemment on ne va pas pouvoir allouer 50 Gb et demander 10000 IOPS non plus, il y a donc des r\u00e8gles de capacit\u00e9 minimale en fonction des IOPS provisionn\u00e9s:<\/p>\n Par exemple, si on veut 5000 IOPS on ne pourra pas descendre sous les 100Gb de capacit\u00e9 (pour tout de m\u00eame 330$ par mois). <\/p>\n On en a un peu parl\u00e9, les tiers de type t2 et t3 sont de type burstable<\/em>. Comme pour les disques gp2 sous 1Tb, les instances burstable <\/em> ont la possibilit\u00e9 d’accumuler des cr\u00e9dits CPU pour pouvoir d\u00e9passer leur capacit\u00e9 CPU th\u00e9orique momentan\u00e9ment lors de pics de charge. <\/p>\n En fonction du dimensionnement du tier, il est \u00e9tabli une CPU baseline (par exemple 16.9% pour un t2.2xlarge, ou 30% pour une t3.large) au dessous de laquelle la machine va accumuler des cr\u00e9dits CPU. En gros un cr\u00e9dit CPU revient \u00e0 pouvoir monter \u00e0 100% sur un CPU pendant 1 minute. Lorsqu’elle a passe au dessus de sa CPU baseline, la machine va commencer \u00e0 d\u00e9penser ses cr\u00e9dits jusqu’\u00e0 \u00e9puisement de ceux-ci, auquel cas elle sera brid\u00e9e \u00e0 20% jusqu’\u00e0 recapitaliser de nouveaux cr\u00e9dits. Le but de la manoeuvre \u00e9tant de permettre \u00e0 une machine de faible dimensionnement de pouvoir d\u00e9passer sa capacit\u00e9 CPU sans pour autant saturer la CPU pour les autres tiers mutualis\u00e9s sur la m\u00eame infrastructure physique. <\/p>\n Par exemple:<\/p>\n Dans ce cas de figure la CPU baseline est \u00e0 30% (en bleu), et on distingue 4 phases: Vous l’aurez compris, une burstable instance utilise ses cr\u00e9dits au besoin et au fil de l’eau. Mais elle peut aussi obtenir d’AWS une ‘avance’ sur ses cr\u00e9dits, et la possibilit\u00e9 de pouvoir les d\u00e9penser imm\u00e9diatement sans avoir besoin d’attendre de les cumuler. Ce mode est appel\u00e9 unlimited<\/em>:<\/p>\n Dans cet exemple, l’instance obtient la totalit\u00e9 de ses 288 cr\u00e9dits imm\u00e9diatement et peut les d\u00e9penser jusqu’\u00e0 \u00e9puisement. En revanche, lorsqu’ils sont \u00e9puis\u00e9s, la machine sera plafonn\u00e9e \u00e0 20% CPU jusqu’au lendemain. <\/p>\n Maintenant que l’on a pos\u00e9 le d\u00e9cor, on va pouvoir commencer \u00e0 parler vraiment de MySQL sur RDS. <\/p>\n En r\u00e9alit\u00e9 RDS n’est qu’une facette du PaaS bases de donn\u00e9es sur AWS, dans la mesure o\u00f9 il regroupe simplement les bases de donn\u00e9es dites relationnelles. Mais il existe aussi d’autres solutions non relationnelles (DynamoDB, DocumentDB), p\u00e9riph\u00e9riques (Elasticache) ou orient\u00e9es gros volumes (Neptune, Redshift) pour compl\u00e9ter l’offre. <\/p>\n On retrouvera donc dans RDS les bases de donn\u00e9es que l’on conna\u00eet d\u00e9j\u00e0, plus le moteur maison, Aurora, que l’on verra dans un prochain \u00e9pisode:<\/p>\n A noter qu’AWS est la seule plateforme en dehors d’Oracle Cloud \u00e0 proposer du PaaS sur Oracle, et supporte depuis peu<\/a> la 12.2… <\/p>\n – Pour les versions \u00e0 ce jour, RDS supporte de MySQL 5.5.46 \u00e0 8.0.15 , et MariaDB de 10.0.24 \u00e0 10.3.13. C’est le seul PaaS \u00e0 supporter MySQL 8.0, depuis le 23 octobre dernier<\/a>. Lors de la cr\u00e9ation de l’instance, il ne sera \u00e9videmment pas propos\u00e9 par d\u00e9faut d’associer l’endpoint \u00e0 une IP publique :<\/p>\n Un VPC d\u00e9di\u00e9 sera cr\u00e9\u00e9 avec tout ce qui va avec (NACL<\/a>, Security Group<\/a>), la bonne pratique \u00e9tant de placer l’instance sur un subnet priv\u00e9 et de g\u00e9rer les ouvertures via le Security Group et \u00e9ventuellement une NAT Gateway<\/a>, et les filtrages avec le Network ACL. <\/p>\n Ensuite la connexion \u00e0 l’instance peut se faire de 2 mani\u00e8res : – Soit en utilisant l’authentification via le compte IAM utilisateur. Dans ce cas, une demande de token pr\u00e9alable permettra de se connecter sans fournir de mot de passe. Le token est valable 15 minutes, ensuite il devra \u00eatre renouvel\u00e9. <\/p>\n Comme chez les concurrents, AWS propose en plus de la console un utilitaire CLI de management des ressources, l’aws cli. Il est bas\u00e9 sur Python, peut s’installer sur Windows ou Linux, et il est directement pr\u00e9packag\u00e9 sur les AMI Amazon Linux. Toutes les briques principales sont accessibles avec une syntaxe type par service (service = { s3, ec2, rds, cloudwatch, lambda, etc…} ):<\/p>\n aws [service] [fonction] [parametres …]<\/em><\/p>\n Par exemple obtenir les caract\u00e9ristiques d’une instance RDS:<\/p>\n Tout ce que nous allons voir par la suite sera port\u00e9 par aws cli. Il est important de bien comprendre sa syntaxe et sa grammaire, car c’est un outil indispensable \u00e0 tout bon devops aws qui se respecte… <\/p>\n On l’a dit un peu plus haut, lors de la cr\u00e9ation de l’instance, l’assistant proposera de cr\u00e9er un nouveau VPC et donc un nouveau security group. Juste pour information, un security group va jouer le r\u00f4le du firewall et permettre d’ouvrir les ports n\u00e9cessaires \u00e0 la connexion vers l’instance RDS. L’avantage dans le cas d’AWS est qu’il est d\u00e9tach\u00e9 du reste de l’instance, de sorte que si l’instance est supprim\u00e9e ou restaur\u00e9e \u00e0 partir d’un snapshot, les informations de filtrage r\u00e9seau peuvent \u00eatre r\u00e9utilis\u00e9es. Il est m\u00eame possible de pr\u00e9parer un groupe de s\u00e9curit\u00e9 avant m\u00eame de cr\u00e9er l’instance et le rattacher \u00e0 la cr\u00e9ation: Que des bonnes nouvelles : d\u00e9j\u00e0 tous les param\u00e8tres MySQL ou MariaDB sont accessibles sur RDS. <\/p>\n Ensuite, les param\u00e8tres de configuration sont g\u00e9r\u00e9s via des parameter groups<\/em> (PG). Comme le Security Group, le PG est un conteneur ind\u00e9pendant de l’instance et peut m\u00eame s’appliquer \u00e0 plusieurs instances RDS. Avec le m\u00eame b\u00e9n\u00e9fice, lorsque l’on supprime ou que l’on restaure une instance, le PG est imm\u00e9diatement r\u00e9utilisable. <\/p>\n A chaque instance est associ\u00e9 un PG par d\u00e9faut, qui peut \u00eatre modifi\u00e9, mais la bonne pratique reste de cr\u00e9er un PG customis\u00e9 en dupliquant le PG par d\u00e9faut. Comme pour les Security Groups, un custom PG peut m\u00eame \u00eatre cr\u00e9\u00e9 avant de cr\u00e9er l’instance RDS et \u00eatre pr\u00e9cis\u00e9 lors de sa cr\u00e9ation: Une des premi\u00e8res actions \u00e0 effectuer post ou pr\u00e9-cr\u00e9ation selon le cas sera donc de dupliquer le PG par d\u00e9faut et de cr\u00e9er un PG customis\u00e9 pour pouvoir ensuite l’appliquer \u00e0 l’instance. Ci-dessous, le PG par d\u00e9faut pour MYSQL 5.7 est dupliqu\u00e9 pour cr\u00e9er un PG customis\u00e9 baptis\u00e9 “my57PG”, puis le nouveau PG est rattach\u00e9 \u00e0 l’instance RDS (on peut utiliser au choix create-db-parameter-group<\/em> \u00e0 partir d’un mod\u00e8le ou copy-db-parameter-group<\/em>)<\/p>\n Le rattachement d’un PG \u00e0 une instance n\u00e9cessite un red\u00e9marrage de celle-ci. On peut ensuite v\u00e9rifier via la fonction g\u00e9n\u00e9rale aws rds describe-db-instance<\/em> que le nouveau groupe de param\u00e8tres est bien actif:<\/p>\n Comme dans le cas d’une instance on-prem, certains param\u00e8tres seront dynamiques et d’autres seront statiques et n\u00e9cessiteront un red\u00e9marrage de l’instance pour \u00eatre effectifs : <\/p>\n Sans privil\u00e8ge SUPER, il ne sera pas possible d’appliquer un param\u00e8tre via SET GLOBAL. La fonction aws rds modify-db-parameter-group<\/em> permettra donc de pallier \u00e0 ce probl\u00e8me :<\/p>\n Si le param\u00e8tre est dynamique comme c’est le cas ici, il est imm\u00e9diatement pris en compte au niveau de l’instance :<\/p>\n Trois types de journaux sont disponibles pour MySQL Par d\u00e9faut, seul l’acc\u00e8s au log d’erreur est configur\u00e9. Les autres peuvent \u00eatre activ\u00e9 via leurs param\u00e8tres respectifs (general_log, slow_query_log + long_query_time). La liste des journaux disponibles peut \u00eatre obtenue et chaque journal peut \u00eatre t\u00e9l\u00e9charg\u00e9 pour \u00eatre inspect\u00e9 localement:<\/p>\n Par d\u00e9faut, un \u00e9quivalant de FLUSH LOGS est effectu\u00e9 toutes les 5 minutes sur les fichiers. Si la destination pour le log g\u00e9n\u00e9ral ou le log de requ\u00eates lentes est une table, alors les tables peuvent \u00eatre recycl\u00e9es manuellement en utilisant les proc\u00e9dures stock\u00e9es mysql.rds_rotate_general_log<\/a> et mysql.rds_rotate_slow_log<\/a>. <\/p>\n La r\u00e9tention quant \u00e0 elle peut se g\u00e9rer via la console, dommage qu’on ne puisse pas le faire via aws cli ou une proc\u00e9dure stock\u00e9e:<\/p>\n Il est aussi possible d’activer des fonctionnalit\u00e9s externes pour les instances RDS MySQL et MariaDB, comme le plugin d’audit de MariaDB<\/a> ou le support de memcached<\/a>. Ces fonctionnalit\u00e9s seront int\u00e9gr\u00e9es sous la forme d’options groups<\/em>. <\/p>\n Par exemple pour activer l’audit MariaDB:<\/p>\n Et le fichier d’audit nouvellement activ\u00e9 appara\u00eet dans la liste des logs consultables et peut \u00eatre t\u00e9l\u00e9charg\u00e9 \u00e0 son tour:<\/p>\n Bon, dans cette premi\u00e8re partie nous avons d\u00e9couvert l’environnement technique qui entoure RDS : les r\u00e9gions, AZ, tiers, types de stockage… et quelques caract\u00e9ristiques de l’offre PaaS pour MySQL sur AWS. Restez connect\u00e9s pour la suite : le reste des fonctionnalit\u00e9s et le comparatif final GCP \/ Azure \/ AWS. <\/p>\n A bient\u00f4t !<\/p>\n David.<\/p>\n Rappel des \u00e9pisodes pr\u00e9c\u00e9dents : – \u00e9pisode 1 : MySQL sur Google Cloud platform. – \u00e9pisode 2 : MySQL et MariaDB sur Microsoft Azure. Bon alors l\u00e0 \u00e7a devient compliqu\u00e9. Volet 1\/2 de l’\u00e9pisode 3 \u00e7a commence \u00e0 ressembler au… Continuer la lecture
\n– \u00e9pisode 1 : MySQL sur Google Cloud platform<\/a>.
\n– \u00e9pisode 2 : MySQL et MariaDB sur Microsoft Azure<\/a>. <\/p>\nAWS Global<\/h2>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/04\/RDS1-1024x580.png\")
<\/p>\nMono-AZ , Multi-AZ:<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/04\/RDS2-1024x432.png\")
<\/p>\nLes modes de facturation:<\/h3>\n
\n– Le Pay-as-you-go<\/strong> : paiement \u00e0 la seconde d’utilisation depuis peu<\/a>, le tarif par instance varie en fonction de sa classe, de son d\u00e9ploiement dans la r\u00e9gion (Mono vs multi-AZ) et du stockage employ\u00e9.
\n– La r\u00e9servation d’instances<\/strong> : engagement sur 1 ou 3 ans avec paiement tout en avance (all upfront<\/em>) ou partiellement en avance (partial upfront<\/em>). Attention seul le prix de l’instance est payable en avance, les autres co\u00fbts (stockage, IOPS provisionn\u00e9s, backup, support) restent des co\u00fbts mensuels. <\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS1.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS2.png\")
<\/p>\nLes tiers disponibles pour RDS:<\/h3>\n
\n– La classe Standard<\/strong>: db.m5 pour les configurations standard, et db.t2 et db.t3 pour les petites configurations (hors prod, test, etc…). On note que ces instances t2 et t3 sont de type ‘Burstable’, on va voir un peu plus loin de quoi il s’agit…
\n– La classe Memory Optimized<\/strong>: db.r4 et db.r5 pour aller jusqu’\u00e0 96vCPUs et 768Gb de m\u00e9moire. Il existe d’autres tiers db.x1 et db.x1e en Memory Optimized mais ils ne sont pas disponibles dans toutes les r\u00e9gions, et notamment pas encore en France. <\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS3-1024x429.png\")
<\/p>\nLe stockage disponible pour RDS:<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS4.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS5-1024x437.png\")
<\/p>\nBurstable instances:<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS6-1024x541.png\")
<\/p>\n
\n– Une premi\u00e8re phase o\u00f9 la charge reste sous 30% et les cr\u00e9dits sont accumul\u00e9s.
\n– Une deuxi\u00e8me phase o\u00f9 la charge passe au dessus des 30% et les cr\u00e9dits sont peu \u00e0 peu d\u00e9pens\u00e9s.
\n– Une troisi\u00e8me phase o\u00f9 les cr\u00e9dits sont \u00e9puis\u00e9s, et la charge CPU sera brid\u00e9e \u00e0 20%.
\n– Et enfin une quatri\u00e8me o\u00f9 la charge retombe et les cr\u00e9dits peuvent \u00eatre cumul\u00e9s \u00e0 nouveau. <\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS7-1024x544.png\")
<\/p>\nMySQL et MariaDB sur RDS<\/h2>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/AWS_1.png\")
<\/p>\nSupport et limitations:<\/h3>\n
\n– Sur le plan des storage engines, il est annonc\u00e9 le support de InnoDB et MyISAM, avec toutefois les r\u00e9serves de rigueur quant \u00e0 la garantie de restaurabilit\u00e9 point-in-time lorsque les tables sont en MyISAM ou que les moteurs sont mix\u00e9s. Federated n’est pas support\u00e9.
\n– Memcached et le plugin d’audit MariaDB sont disponibles via les options groups que nous allons d\u00e9tailler plus loin.
\n– Support GTIDs \u00e0 partir de la 5.7.23+
\n– Support du pr\u00e9chargement du buffer pool innodb \u00e0 partir de la version 5.6.
\n– Pas de privil\u00e8ge SUPER, comme pour les autres PaaS MySQL, mais la plupart des commandes son disponibles via des proc\u00e9dures stock\u00e9es dans la base mysql : rds_% (KILL, KILL QUERY, CHANGE MASTER TO, RESET MASTER, START SLAVE, etc…)
\n– Pas de support de SET PERSIST<\/a> en 8.0 pour l’instant, le param\u00e9trage passe par des Parameter Groups que l’on va aussi voir en d\u00e9tail plus loin…
\n– Pas de support pour la r\u00e9plication semi-synchrone. <\/p>\nConnectivit\u00e9:<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS8.png\")
<\/p>\n
\n– Soit en utilisant un client classique (mysql ou GUI) depuis un bastion ou une autre machine on-prem \/ EC2. Par exemple ici en pr\u00e9configurant un login-path<\/a> vers une instance RDS 5.7:<\/p>\n\r\n$ mysql_config_editor set --login-path=my57fromlocalPC \\ \r\n--host=my57.xxxxxxxxxxx.eu-west-3.rds.amazonaws.com --port=3306 \\\r\n--user=my57_user --password\r\nEnter password: ************\r\n$ mysql --login-path=my57fromlocalPC --execute="select version();"\r\n+------------+\r\n| version() |\r\n+------------+\r\n| 5.7.25-log |\r\n+------------+\r\n<\/pre>\n
\r\n$ TOKEN="$(aws rds generate-db-auth-token \\\r\n--hostname my57.xxxxxxxxxxx.eu-west-3.rds.amazonaws.com \\\r\n--port=3306 --region eu-west-3 --username my57_user)"\r\n\r\n$ mysql --host=my57.xxxxxxxxxxx.eu-west-3.rds.amazonaws.com --port=3306 \\\r\n--user=my57_user --ssl-ca=~\/rds-combined-ca-bundle.pem \\\r\n--ssl-mode=VERIFY_IDENTITY --enable-cleartext-plugin --password=${TOKEN} \\\r\n--execute="select version();"\r\n+------------+\r\n| version() |\r\n+------------+\r\n| 5.7.25-log |\r\n+------------+\r\n<\/pre>\nAWS cli:<\/h3>\n
\r\n$ aws rds describe-db-instances --db-instance-identifier my57\r\n{\r\n "DBInstances": [\r\n {\r\n "DBInstanceIdentifier": "my57",\r\n "DBInstanceClass": "db.t2.micro",\r\n "Engine": "mysql",\r\n "DBInstanceStatus": "available",\r\n "MasterUsername": "my57_user",\r\n "DBName": "mysql_user",\r\n "Endpoint": {\r\n "Address": "my57.xxxxxxxxxxx.eu-west-3.rds.amazonaws.com",\r\n "Port": 3306,\r\n "HostedZoneId": "ZMESEXB7ZGGQ3"\r\n(...)\r\n<\/pre>\nSecurity groups:<\/h3>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS9.png\")
\nPar d\u00e9faut, chaque r\u00e8gle ajout\u00e9e dans un groupe de s\u00e9curit\u00e9 l’est dans les 2 sens: inbound et outbound. Donc on ouvrira seulement le port MySQL (3306 par d\u00e9faut) soit sur l’IP publique soit sur la NAT gateway pour permettre un acc\u00e8s depuis l’ext\u00e9rieur. <\/p>\nParameter Groups:<\/h3>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/rds10.png\")
\nUn des int\u00e9r\u00eats est aussi de pouvoir assurer une forme d’homog\u00e9n\u00e9it\u00e9 du param\u00e9trage sur une flotte d’instances. A travers la console, il est par exemple possible de comparer le contenu de 2 PG pour voir s’il existe des diff\u00e9rences:
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS11.png\")
<\/p>\n\r\n$ aws rds create-db-parameter-group \\\r\n\t--db-parameter-group-name my57PG \\\r\n\t--db-parameter-group-family mysql5.7 \\\r\n\t--description "My Private 5.7 PG"\r\n\r\n$ aws rds modify-db-instance \\\r\n\t--db-instance-identifier my57 \\\r\n\t--db-parameter-group-name my57PG\r\n<\/pre>\n
\r\n$ aws rds reboot-db-instance --db-instance-identifier my57\r\n$ aws rds describe-db-instances --db-instance-identifier my57\r\n(...)\t"DBParameterGroupName": "my57pg",\r\n\t"ParameterApplyStatus": "in-sync"\r\n<\/pre>\n
\r\n$ aws rds describe-db-parameters \\ \r\n\t--db-parameter-group-name my57PG \\\r\n\t--query "Parameters[*][ParameterName,ParameterValue,ApplyType]" \\\r\n\t--output text\r\nallow-suspicious-udfs\t\tNone static\r\nautocommit\t\t\tNone dynamic\r\nauto_generate_certs\t\tNone static\r\nauto_increment_increment\tNone dynamic\r\nauto_increment_offset\t\tNone dynamic\r\n(...)\r\n<\/pre>\n
\r\n$ aws rds modify-db-parameter-group \\\r\n\t--db-parameter-group-name my57PG \\\r\n\t--parameters "ParameterName=max_connections, ParameterValue=200,ApplyMethod=immediate"\r\n<\/pre>\n
\r\n$ mysql --login-path=my57fromlocalPC --execute="select @@max_connections;"\r\n+--------------------+\r\n| @@max_connections |\r\n+--------------------+\r\n| 200 |\r\n+--------------------+\r\n<\/pre>\n
Acc\u00e8s aux journaux:<\/h3>\n
\n– Le log d’erreur.
\n– Le log g\u00e9n\u00e9ral
\n– Le log de requ\u00eates lentes. <\/p>\n\r\n$ aws rds describe-db-log-files --db-instance-identifier my57\r\n(...) {\r\n "LogFileName": "error\/mysql-error.log",\r\n "LastWritten": 1554363300000,\r\n "Size": 0\r\n }, (...)\r\n\r\n$ aws rds download-db-log-file-portion --db-instance-identifier my57 \\\r\n\t--starting-token 0 --output text \\\r\n\t--log-file-name "error\/mysql-error.log"\r\n2019-04-01T15:23:12.123344Z 0 [Note] Giving 1 client threads a chance to die gracefully\r\n2019-04-01T15:23:12.124334Z 0 [Note] Shutting down slave threads\r\n2019-04-01T15:23:14.124539Z 0 [Note] Forcefully disconnecting 0 remaining clients (...)\r\n<\/pre>\n\r\nmysql> call mysql.rds_rotate_slow_log ;\r\nQuery OK, 0 rows affected (0.03 sec)\r\n<\/pre>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/RDS12.png\")
<\/p>\nOption groups:<\/h3>\n
\r\n$ aws rds create-option-group --option-group-name "mariadbaudit" \\\r\n\t--engine-name mysql --major-engine-version 5.7 \\\r\n\t--option-group-description "test MariaDB audit plugin"\r\n\r\n$ aws rds add-option-to-option-group --option-group-name "mariadbaudit" \\\r\n\t--options "OptionName=MARIADB_AUDIT_PLUGIN" \\\r\n\t--apply-immediately\r\n\r\n$ aws rds modify-db-instance --db-instance-identifier "my57" \\ \r\n\t--option-group-name "mariadbaudit" \\ \r\n\t--apply-immediately\r\n<\/pre>\n
\r\n$ aws rds describe-db-log-files --db-instance-identifier my57\r\n{\r\n\t"DescribeDBLogFiles": [\r\n\t{\r\n\t\t"LogFileName": "audit\/server_audit.log",\r\n\t\t"LastWritten": 1554360583000,\r\n\t\t"Size": 24815\r\n}, (...)\r\n\r\n$ aws rds download-db-log-file-portion --db-instance-identifier my57 \\\r\n\t--starting-token 0 --output text \\\r\n\t--log-file-name "audit\/server_audit.log"\r\n20190404 06:46:17,ip-10-22-1-227,rdsadmin,localhost,3,1,QUERY,,'install plugin server_audit soname \\'server_audit.so\\'',0\r\n20190404 06:46:17,ip-10-22-1-227,rdsadmin,localhost,3,2,QUERY,,'SELECT 1',0\r\n20190404 06:46:17,ip-10-22-1-227,rdsadmin,localhost,3,3,QUERY,,'SET GLOBAL server_audit_file_path=\\'\/rdsdbdata\/log\/audit\/server_audit.log\\'',0\r\n20190404 06:46:17,ip-10-22-1-227,rdsadmin,localhost,3,3,QUERY,,'SET GLOBAL server_audit_file_path=\\'\/rdsdbdata\/log\/audit\/server_audit.log\\'',0\r\n20190404 06:46:17,ip-10-22-1-227,rdsadmin,localhost,3,4,QUERY,,'SELECT 1',0\r\n20190404 06:46:17,ip-10-22-1-227,rdsadmin,localhost,3,5,QUERY,,'SET GLOBAL server_audit_query_log_limit = 1024',0\r\n (...)\r\n<\/pre>\nConclusion partie 1\/2<\/h2>\n
<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"