![\"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>Je vous propose de d\u00e9couvrir ensemble de quelle mani\u00e8re MySQL est impl\u00e9ment\u00e9 dans le PaaS, chez les 3 principaux fournisseurs de ce type de service : Google, Microsoft et Amazon, au rythme d’un \u00e9pisode par plateforme. <\/p>\n
Dans chaque \u00e9pisode nous passerons en revue les diff\u00e9rentes caract\u00e9ristiques techniques de l’offre, nous verrons les diff\u00e9rences avec une distribution classique en termes de fonctionnalit\u00e9s, tout \u00e7a avec notre oeil de DBA, en insistant sur la maintenabilit\u00e9 et le diagnostic avant tout. Parce que ne vous y trompez pas, vous aurez toujours des probl\u00e8mes de performance dans le cloud, et il vous faudra toujours des m\u00e9thodes et des outils pour pouvoir les analyser. <\/p>\n
Egalement nous verrons comment il est possible de migrer des bases on-premise vers l’\u00e9quivalent cloud, en essayant \u00e0 chaque fois de minimiser l’indisponibilit\u00e9 lors de la bascule. <\/p>\n
Rappels:<\/b> dans le cas du PaaS<\/i> (Platform as a Service<\/i>), la base de donn\u00e9es est un service h\u00e9berg\u00e9 et accessible \u00e0 distance, pour laquelle l’infrastructure est manag\u00e9e et donc invisible c\u00f4t\u00e9 utilisateur. A la diff\u00e9rence du IaaS<\/i> (Infrastructure as a Service<\/i>), o\u00f9 l’infrastructure est visible et accessible \u00e0 l’utilisateur ( = machines virtuelles). <\/p>\n
Dans cette s\u00e9rie, nous ne parlerons que du PaaS<\/i>. L’int\u00e9r\u00eat principal du PaaS<\/i> sur le IaaS<\/i> est que l’infrastructure est manag\u00e9e: on ne s’occupe plus de g\u00e9rer des serveurs, des syst\u00e8mes d’exploitation, des patches, des sauvegardes, etc… On se concentre sur le service. <\/p>\n
A noter \u00e9galement que le monde du cloud est un monde qui bouge tr\u00e8s vite donc les informations qui sont pr\u00e9sent\u00e9es ici sont susceptibles d’\u00e9voluer dans le futur. <\/p>\n
Sur GCP, le d\u00e9coupage des briques de service est le suivant : <\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/11\/google-cloud-platform-services.jpg\")
<\/p>\n
– Compute<\/b> regroupe l’App Engine (runtimes, ex\u00e9cution serverless), une brique Kubernetes, et le Compute Engine qui h\u00e9berge le IaaS, les machines virtuelles, donc l’\u00e9quivalent d’EC2 sur AWS. <\/p>\n
– Big Data<\/b> propose une brique base de donn\u00e9es bas\u00e9e sur un moteur de stockage et d’interrogation en colonne (BigQuery) et une suite d’outils orient\u00e9s datawarehouse. <\/p>\n
– Storage<\/b> : il faudra aller chercher nos bases de donn\u00e9es relationnelles au rayon du stockage au milieu des briques NoSQL (BigTable, DataStore, et r\u00e9cemment MemoryStore) et stockage pur type S3 (Cloud Storage), sous la d\u00e9nomination Cloud SQL<\/b>. Derri\u00e8re ce titre se cache en r\u00e9alit\u00e9 deux offres : une sur MySQL, une sur PostgreSQL. <\/p>\n
Il existe d’autres briques techniques comme la partie r\u00e9seau\/VPC, et StackDriver qui propose des outils de logging, m\u00e9trologie et diagnostic, que nous verrons un peu plus loin.<\/p>\n
Ces briques sont d\u00e9ployables de mani\u00e8re globale sur une ou plusieurs r\u00e9gions chacune comportant au moins 3 zones distinctes proches g\u00e9ographiquement (datacenters). Actuellement il existe 18 r\u00e9gions op\u00e9rationnelles et 2 r\u00e9gions en cours de d\u00e9ploiement:<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/11\/GCP_geo.png\")
<\/p>\n
Chaque r\u00e9gion propose une gamme de plateformes techniques pour l’ex\u00e9cution des services : types et nombre de CPU, etc… <\/p>\n
Dans l’exemple de la r\u00e9gion europe-west4 (Pays-Bas), nous avons trois zones -a, -b et -c, dans lesquelles nous pouvons d\u00e9ployer des tiers jusqu’\u00e0 96vCPUs Skylake ou Broadwell, nous pouvons utiliser l’option Local SSD<\/a><\/i> (SSD en attachement direct sur l’hyperviseur, meilleures performances, meilleur prix mais aucune redondance) ainsi que le mode Sole Tenant nodes<\/a><\/i> qui permet de d\u00e9dier un hyperviseur pour un compte. Pour plus de d\u00e9tails, je vous invite \u00e0 consulter la doc en ligne de GCP.<\/p>\n Certaines ressources comme les identit\u00e9s, les images, etc… peuvent \u00eatre globales, alors que d’autres comme des sous r\u00e9seau, des adresses IP, des instances ou du stockage peuvent \u00eatre confin\u00e9s \u00e0 une r\u00e9gion voire une seule zone. <\/p>\n Pour repr\u00e9senter une application globale, il existe la notion de projet<\/b>: c’est un peu l’espace de nom global du d\u00e9ploiement d’une application. Chaque ressource est unique dans un projet, chaque projet est unique dans GCP. C’est sur la base du projet qu’est \u00e9tablie la facturation. <\/p>\n Enfin, l’acc\u00e8s aux ressources peut se faire de trois mani\u00e8res diff\u00e9rentes : <\/p>\n – Via la console web<\/a> : dans un navigateur, on acc\u00e8de aux diff\u00e9rents services, param\u00e9trage, ex\u00e9cution ou arr\u00eat, duplication, sauvegarde, etc… ainsi qu’au monitoring de ces services. <\/p>\n – Via un CLI<\/a> (Command Line Interface) : tout ce qui se fait dans la console retrouve un \u00e9quivalent dans la commande gcloud<\/b>. Il suffit de l’installer sur un linux<\/a> ou windows<\/a> client et de piloter le projet \u00e0 partir de la ligne de commande:<\/p>\n – Via les API<\/a> en fonction du langage choisi, il en existe pour tous les go\u00fbts : Python, Go, Ruby, PHP, Java, Node.js, C#, etc…<\/p>\n Alors que PostgreSQL est une offre relativement r\u00e9cente (2016) et assez peu mature par rapport \u00e0 ce que produit Amazon notamment (RDS \/ Aurora), l’offre MySQL en est \u00e0 sa deuxi\u00e8me g\u00e9n\u00e9ration, s’est enrichie au fil des ann\u00e9es et b\u00e9n\u00e9ficie d’un peu plus de recul sur les fonctionnalit\u00e9s. Aujourd’hui il est toujours possible de provisionner des instances MySQL de premi\u00e8re g\u00e9n\u00e9ration mais elles sont propos\u00e9es seulement pour compatibilit\u00e9 et seront retir\u00e9es probablement dans les mois \u00e0 venir. <\/p>\n Avant de passer \u00e0 la pratique, regardons sur le papier les principales caract\u00e9ristiques techniques d’une instance MySQL gen II: Lors de la cr\u00e9ation d’une instance Cloud SQL MySQL de g\u00e9n\u00e9ration II, il est possible pour dimensionner la plateforme d’ex\u00e9cution de choisir entre les mod\u00e8les suivants: On peut choisir entre un stockage de type SSD (par d\u00e9faut) ou magn\u00e9tique. Pour les SSD, la taille du volume et le nombre de vCPUs vont affecter le nombre d’IOPS et le d\u00e9bit en Mb\/s :<\/p>\n Pour un tier \u00e0 15 vCPUs ou moins, il faudra provisionner \u00e0 500Gb pour obtenir 15000 IOPS et 240Mb\/s qui sont les maximums. C’est un travers que l’on va retrouver chez les concurrents : le fait de toujours surprovisionner la capacit\u00e9 des disques pour pouvoir obtenir de meilleures performances<\/b>. Si pour un besoin de moins de 100Gb on alloue 500Gb parce qu’il nous faut des IOPS et du d\u00e9bit, on ne se pr\u00e9occupera plus de l’espace disque, d’autant qu’il augmentera tout seul par d\u00e9faut (sans jamais pouvoir \u00eatre r\u00e9duit): <\/p>\n Principal danger de cette philosophie : on risque de perdre de vue la ma\u00eetrise de l’espace disque du point de vue des performances : un index fragment\u00e9 ne va pas co\u00fbter plus cher en stockage, par contre il va co\u00fbter plus cher en temps d’ex\u00e9cution, en temps vCPU, en verrous maintenus plus longtemps, etc… <\/p>\n Le co\u00fbt du stockage (novembre 2018 pour la r\u00e9gion europe-west4 – Pays-Bas): Un exemple de configuration: 1 instance db-n1-standard-16<\/b> : En utilisant la calculette<\/a> on obtient:<\/p>\n Plus de d\u00e9tails sur les tiers disponibles et sur les co\u00fbts : https:\/\/cloud.google.com\/sql\/pricing#2nd-gen-pricing<\/a>. L’id\u00e9e est de garder ce chiffre en t\u00eate pour pouvoir le comparer ensuite \u00e0 ce que peut donner un \u00e9quivalent sur AWS ou Azure dans les articles suivants. <\/p>\n 1) Pas de LOAD DATA INFILE<\/b> dans le PaaS. Ca para\u00eet logique. A noter que sur Cloud Compute, LOAD DATA LOCAL INFILE<\/b> est lui support\u00e9. <\/p>\n 2) Dans la m\u00eame veine, pas de SELECT … INTO OUTFILE \/ DUMPFILE<\/b>. <\/p>\n 3) Pas de CREATE FUNCTION … SONAME<\/b> pour le code externe (.so)<\/p>\n 4) Tout ce qui est li\u00e9 au privil\u00e8ge SUPER<\/b> : par exemple pas moyen de modifier des param\u00e8tres globaux, pas de GRANT ALL<\/b>, pas de CHANGE MASTER TO<\/b>, etc… <\/p>\n 5) Peut \u00eatre le plus impactant : dans la mesure o\u00f9 la r\u00e9plication GTID sert de cadre technique \u00e0 toute la redondance, les param\u00e8tres GTID doivent \u00eatre activ\u00e9s et donc pas de CREATE TABLE AS SELECT<\/b> ni de CREATE TEMPORARY TABLE<\/b> dans les transactions. <\/p>\n 6) Attention ! Performance_schema<\/b> n’est accessible que pour les tiers sup\u00e9rieurs \u00e0 db-n1-standard-8<\/b> ou db-n1-highmem-4<\/b>. <\/p>\n Deux mani\u00e8res de se connecter : soit utiliser un client classique (mysql, SQLYOG, MySQL Workbench), soit utiliser l’outil Cloud SQL Proxy<\/a>. <\/p>\n Cloud SQL proxy s’installe sur le client et une fois associ\u00e9 au compte et au projet, permet de g\u00e9rer les connexions de mani\u00e8re plus simple et plus s\u00e9curis\u00e9e:<\/p>\n Passer par le client natif sera g\u00e9n\u00e9ralement un peu plus rapide que passer par le proxy, mais si la connexion doit \u00eatre port\u00e9e par SSL il faudra g\u00e9rer les certificats soit-m\u00eame:<\/p>\n Cela dit, l’outil reste assez vaste et n\u00e9cessitera un approfondissement via un article d\u00e9di\u00e9. A titre personnel, j’utiliserai plut\u00f4t le client natif mysql<\/i> d’autant que le login-path fonctionne sans probl\u00e8me avec une instance dans le cloud. <\/p>\n Nous avons vu plus haut que le failover peut \u00eatre automatis\u00e9. Attention il n’est pas actif par d\u00e9faut, le plus simple est de provisionner une instance de secours au moment du d\u00e9ploiement de l’instance principale :<\/p>\n A noter qu’il est toujours possible de rajouter <\/a>une instance de secours plus tard via la console, gcloud ou une API dans le langage de votre choix. <\/p>\n Cette instance de secours sera appel\u00e9e failover replica<\/i>. Il ne peut y en avoir qu’une seule par instance master, elle doit se trouver dans une autre zone mais n\u00e9cessairement dans la m\u00eame r\u00e9gion, et ce sera une exacte copie en termes de configuration. La synchronisation sera assur\u00e9e par la r\u00e9plication semi-synchrone<\/a> MySQL en mode GTID. Ce qui implique que les binlogs seront activ\u00e9s sur le master, donc co\u00fbt de stockage suppl\u00e9mentaire. <\/p>\n Enfin, ce failover replica fera \u00e9videmment l’objet d’une facturation suppl\u00e9mentaire. La mauvaise nouvelle c’est qu’il sera factur\u00e9 au m\u00eame prix<\/a> que l’instance master. A noter que le prix \u00e9voqu\u00e9 un peu plus haut inclut d\u00e9j\u00e0 le co\u00fbt du failover replica, mais je trouve dommage de facturer une instance dormante au m\u00eame prix qu’une instance active. <\/p>\n Pour assurer le failover automatique, outre le failover replica, plusieurs m\u00e9canismes sont en place: Un syst\u00e8me externe monitore l’arriv\u00e9e des lignes de heartbeat et si aucune nouvelle ligne n’est lisible au del\u00e0 de 60 secondes et si le failover replica est disponible, un failover sera initi\u00e9: Au del\u00e0 de la partie failover, il est aussi possible de cr\u00e9er d’autres slaves en lecture seule, des read replicas<\/i>. Dans ce cas, il est possible de cr\u00e9er plusieurs read replicas pour un m\u00eame master, et dans le cas d’un failover ils seront automatiquement recr\u00e9\u00e9s \u00e9galement. <\/p>\n Plusieurs choses \u00e0 noter pour les read replicas : D\u00e9j\u00e0 il existe 2 types de backups : les backups automatis\u00e9s<\/b> et les backups \u00e0 la demande<\/b>. Associ\u00e9s \u00e0 l’activation des logs binaires, ils fournissent une solution de restauration \u00e0 un point dans le temps, ce qui est tr\u00e8s important vis \u00e0 vis de votre RPO<\/a>. <\/p>\n Les backups automatis\u00e9s seront lanc\u00e9s dans une fen\u00eatre de 4 heures que l’on peut d\u00e9finir \u00e0 la cr\u00e9ation de l’instance ou plus tard : Il est ensuite possible de lancer des backups \u00e0 la demande. Ces backups ne suivront pas la politique de r\u00e9tention des backups automatiques, ils resteront donc sur un bucket disque tant qu’ils ne seront pas supprim\u00e9s:<\/p>\n La question de la coh\u00e9rence de ces backups est \u00e9vacu\u00e9e par le postulat de n’avoir qu’InnoDB en moteur de stockage pour les g\u00e9n\u00e9ration II, ce qui revient \u00e0 faire un mysqldump en –single-transaction. Pas besoin de faire un FLUSH TABLE WITH READ LOCK donc, toutefois comme sur les distributions traditionnelles, il vaut mieux \u00e9viter de lancer des op\u00e9rations DDL<\/a> pendant la sauvegarde. <\/p>\n La liste des backups est consultable traditionnellement via la console, gcloud ou une API:<\/p>\n Je n’ai pas trouv\u00e9 le moyen de voir la taille par backup, dommage car la cha\u00eene est \u00e0 base de backup complet (le plus ancien) et ensuite de backups incr\u00e9mentaux, donc on devrait pouvoir voir le gain d’espace disque sur les backups additionnels.<\/p>\n Une restauration peut se faire sur l’instance source mais aussi d’une instance \u00e0 une autre en pr\u00e9cisant –backup-instance et –restore-instance :<\/p>\n ou<\/p>\n Le backup source sera identifi\u00e9 par la cl\u00e9 1543505077704<\/i> qui reprend le BACKUP_ID renvoy\u00e9 par la commande de listing vue plus haut. Pendant la dur\u00e9e de la restauration, toute la cible est \u00e9videmment inaccessible:<\/p>\n Enfin, si des r\u00e9plicas failover ou read existent, il faudra les supprimer et les reprovisionner une fois la restauration effectu\u00e9e. <\/p>\n Au del\u00e0 de la solution via –backup-instance et –restore-instance, il existera une solution pour cloner une instance existante et en cr\u00e9er une nouvelle :<\/p>\n Pour clore le chapitre sur les backups, on peut dire qu’ils ne peuvent \u00eatre utilis\u00e9s qu’au sein du m\u00eame projet. On ne peut pas restaurer vers une instance d’un autre projet, ou sur une instance de premi\u00e8re g\u00e9n\u00e9ration, etc…<\/p>\n Cloud SQL est un service factur\u00e9 \u00e0 l’utilisation: lorsque l’instance est coup\u00e9e, seul le stockage est factur\u00e9. Donc si vous n’avez pas besoin d’avoir une instance d\u00e9marr\u00e9e en permanence (par exemple vos environnements hors prod), vous allez faire des \u00e9conomies, mais cela implique d’utiliser un m\u00e9canisme sp\u00e9cifique pour g\u00e9rer les arr\u00eat et d\u00e9marrages. <\/p>\n Tout est contr\u00f4l\u00e9 \u00e0 partir du param\u00e8tre du service ACTIVATION_POLICY<\/b>. Attention ce n’est pas un param\u00e8tre MySQL mais bien un param\u00e8tre Cloud SQL. <\/p>\n Globalement ce param\u00e8tre peut \u00eatre positionn\u00e9 soit \u00e0 :<\/p>\n – ALWAYS<\/b> : le service est d\u00e9marr\u00e9 et factur\u00e9.<\/p>\n – NEVER<\/b> : le service est stopp\u00e9 et non factur\u00e9.<\/p>\n Pour les instances de g\u00e9n\u00e9ration I, il existe un param\u00e8tre ON_DEMAND<\/b> qui implique que la derni\u00e8re d\u00e9connexion coupe le service et la premi\u00e8re connexion le red\u00e9marre, mais pour une instance de g\u00e9n\u00e9ration II cette option n’est pas disponible et devrait dispara\u00eetre \u00e0 terme. <\/p>\n Il existe \u00e9videmment l’\u00e9quivalent c\u00f4t\u00e9 console et API mais si vous souhaitez automatiser une mise en sommeil de vos instances de dev \/ recette par exemple, le plus efficace sera de piloter ACTIVATION_POLICY via un client distant, qui peut \u00eatre chez vous on-premise ou dans une VM Cloud Compute. <\/p>\n Si un arr\u00eat suivi d’un red\u00e9marrage imm\u00e9diat est souhait\u00e9, il existe une troisi\u00e8me solution mais dans ce cas il n’y a pas d’arr\u00eat de la facturation:<\/p>\n A noter que par d\u00e9faut si vous utilisez mysqladmin shutdown l’instance s’arr\u00eate et red\u00e9marre imm\u00e9diatement, ce n’est donc pas une option… <\/p>\n Remarque : La valeur de @@server-id est g\u00e9n\u00e9r\u00e9e al\u00e9atoirement, elle est notamment r\u00e9g\u00e9n\u00e9r\u00e9e \u00e0 chaque changement de ACTIVATION_POLICY ou red\u00e9marrage via gcloud sql instances restart…<\/i>. \u00c7a surprend un peu au d\u00e9but mais \u00e0 la r\u00e9flexion ce n’est pas vraiment un probl\u00e8me dans la mesure o\u00f9 on n’utilisera que la r\u00e9plication GTID et la valeur de @@server-uuid, elle, ne change jamais. <\/p>\n A partir de la g\u00e9n\u00e9ration II, on peut choisir sa fen\u00eatre de maintenance, pendant laquelle les mises \u00e0 jour n\u00e9cessitant les arr\u00eat \/ red\u00e9marrages de l’instances peuvent survenir:<\/p>\n Les failover replicas<\/i> suivront la m\u00eame politique donc il n’est pas possible de basculer pendant cette p\u00e9riode. Il y a risque donc de downtime, sans garantie (les dates de mise \u00e0 jour ne sont pas annonc\u00e9es \u00e0 l’avance). C’est donc une partie assez d\u00e9licate pour 2 raisons principales:<\/p>\n 1) Si vous avez \u00e0 la fois vos environnements hors prod et production dans Cloud SQL, il sera compliqu\u00e9 de pouvoir patcher le hors prod et le laisser tourner suffisamment longtemps pour d\u00e9tecter un probl\u00e8me suite \u00e0 une mise \u00e0 jour. Les instances de g\u00e9n\u00e9ration II disposent d’un second param\u00e8tre maintenance timing<\/a><\/i> qui permet d’indiquer quelles instances sont patch\u00e9es en avance et quelle instances sont patch\u00e9es plus tard, mais cela reste tr\u00e8s vague on ne peut pas vraiment d\u00e9terminer un \u00e9cart de temps pr\u00e9cis entre les instances patch\u00e9es en Earlier<\/i> et les instances patch\u00e9es en Later<\/i>:<\/p>\n 2) Ensuite, il y a bien downtime<\/b> c’est une infrastructure manag\u00e9e et vous ne pourrez rien y faire. Si votre application n\u00e9cessite d’\u00eatre disponible 24\/7 sans interruption programm\u00e9e, il risque d’y avoir un os. Vous n’avez qu’un contr\u00f4le marginal sur l’application de ces patches, statistiquement il y a environ 1 \u00e0 2 patches par mois, votre instance est coup\u00e9e environ 5 minutes \u00e0 chaque fois. On se souvient que le SLO (Service Level Objective) de GCP est en 4×9 (99.99%) seulement, ceci explique donc cela, il faudra garder cet argument en t\u00eate lorsque nous comparerons avec les petits camarades AWS et Azure. <\/p>\n De notre point de vue de technicien, c’est l\u00e0 que l’on rentre vraiment dans le brouillard, si vous voulez bien me passer l’expression \ud83d\ude42 <\/p>\n Car si du point de vue du m\u00e9tier et des \u00e9tudes, globalement Cloud SQL pour MySQL est une r\u00e9ussite du point de vue compatibilit\u00e9 et co\u00fbt, du point de vue de la production c’est une autre paire de manches. Ce qui n’est pas surprenant, un service qui propose une infrastructure manag\u00e9e est cens\u00e9 s’affranchir des probl\u00e9matiques de production. Notre m\u00e9tier change, on le sait. <\/p>\n La question que l’on doit se poser toutefois, c’est quoi faire en cas de d\u00e9gradation de performance. Le clouder<\/i> vous dira avec le sourire que le plus simple reste de pousser le curseur \u00e0 droite, partir sur un tier plus costaud, mais aussi une facture disons, plus cons\u00e9quente<\/i>. <\/p>\n Maintenant, votre int\u00e9r\u00eat sera de voir ce que vous pouvez optimiser avant de commencer \u00e0 payer plus cher votre service. En mettant plus de ressources face \u00e0 un probl\u00e8me de performance, on ne s’attaque pas \u00e0 la cause racine, m\u00eame dans le cloud. <\/p>\n Pour y arriver, il faut des outils pour pouvoir investiguer comme on pourrait le faire sur une installation traditionnelle. Et comme ce n’est pas dans l’int\u00e9r\u00eat du clouder<\/i>, ces outils que l’on avait l’habitude manipuler vont commencer \u00e0 se rar\u00e9fier. <\/p>\n Faisons un tour de ce qui est disponible et ce qui ne l’est pas pour MySQL sur GCP: <\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/11\/gcp_projet.png\")
<\/p>\n\r\n$ gcloud sql instances list\r\nNAME DATABASE_VERSION LOCATION TIER PRIMARY_ADDRESS PRIVATE_ADDRESS STATUS\r\nmysql56-src MYSQL_5_6 europe-west4 - -\r\nmysql-cap-cloud MYSQL_5_7 europe-west4-a db-n1-standard-1 35.204.174.228 - STOPPED\r\nmysql5-slv MYSQL_5_6 europe-west4-b db-n1-standard-1 35.204.147.252 - FAILED\r\n<\/pre>\n
Cloud SQL pour MySQL:<\/h2>\n
\n– Seules les versions 5.6 et 5.7 sont support\u00e9es.
\n– InnoDB est le seul moteur de stockage support\u00e9.
\n– Pour le choix du tier, 64 vCPUs, 416 Gb de RAM et 10Tb de disque au maximum.
\n– Concernant le maintien en conditions op\u00e9rationnelles, les sauvegardes sont automatiques et les restaurations possibles \u00e0 un point dans le temps, \u00e9galement les patches mineurs sont appliqu\u00e9s en pr\u00e9cisant une fen\u00eatre de maintenance de pr\u00e9f\u00e9rence.
\n– Concernant la disponibilit\u00e9, les donn\u00e9es sont dupliqu\u00e9es sur 2 autres r\u00e9gions id\u00e9alement proches g\u00e9ographiquement, le failover d’une zone \u00e0 l’autre est automatis\u00e9 avec une VIP. <\/p>\nLes tiers disponibles :<\/h3>\n
\n– db-f1-micro \/ db-g1-small<\/b> : vCPU partag\u00e9s avec d’autres machines micro \/ small, 1.6Gb de m\u00e9moire et 3Tb de donn\u00e9es maximum, 1000 connexions simultan\u00e9es.
\n– db-n1-standard-1 \u00e0 -64<\/b> : de 1 \u00e0 64 vCPUs, de 3 \u00e0 240Gb de RAM, 10Tb de stockage et 4000 connexions simultan\u00e9es.
\n– db-n1-highmem-2 \u00e0 -64<\/b> : de 2 \u00e0 64 vCPUs, de 13 \u00e0 416Gb de RAM, 10Tb de stockage et 4000 connexions simultan\u00e9es. <\/p>\nLe stockage disponible :<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/11\/gcp_storage_2.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/11\/gcp_storage_1.png\")
<\/p>\nLes co\u00fbts<\/h3>\n
\n– $0.187\/Gb\/mois pour les SSD
\n– $0.099\/BG\/mois pour les disques magn\u00e9tiques. <\/p>\n
\n– Fonctionnement en 24\/7
\n– Avec un failover replica
\n– 16 vCPUs d\u00e9di\u00e9s
\n– 60Gb de RAM
\n– 200 Gb de stockage SSD
\n– 1Tb de stockage pour les sauvegardes<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/11\/gcp_cost1.png\")
<\/p>\nLes limitations par rapport \u00e0 une distribution classique:<\/h3>\n
La connexion<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/12\/gcp_cloud_proxy.png\")
<\/p>\n\r\n$ .\/cloud_sql_proxy -instances=durable-epoch-220407:europe-west4:mysql-cap-cloud=tcp:3306 &\r\n[1] 10131\r\n2018\/12\/03 10:39:37 Listening on 127.0.0.1:3306 for durable-epoch-220407:europe-west4:mysql-cap-cloud\r\n2018\/12\/03 10:39:37 Ready for new connections\r\n\r\n$ time mysql --login-path=mygcpsql --execute="select count(1) from sakila.payment;"\r\n+----------+\r\n| count(1) |\r\n+----------+\r\n| 16049 |\r\n+----------+\r\n\r\nreal\t0m0.128s\r\nuser\t0m0.000s\r\nsys\t0m0.004s\r\n\r\n$ time mysql --user=root --host=127.0.0.1 --port=3306 --password=****** --execute="select count(1) from sakila.payment;"\r\nWarning: Using a password on the command line interface can be insecure.\r\n2018\/12\/03 10:32:00 New connection for "durable-epoch-220407:europe-west4:mysql-cap-cloud"\r\n+----------+\r\n| count(1) |\r\n+----------+\r\n| 16049 |\r\n+----------+\r\n\r\nreal\t0m0.162s\r\nuser\t0m0.004s\r\nsys\t0m0.000s\r\n$ 2018\/12\/03 10:32:00 Client closed local connection on 127.0.0.1:3306\r\n\r\n\r\n<\/pre>\n
La haute disponibilit\u00e9 et les possibilit\u00e9s de r\u00e9plication:<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/11\/gcp_ha1-1.png\")
\n<\/p>\n
\n– L’\u00e9criture d’une ligne de ‘heartbeat’ dans une table syst\u00e8me mysql.heartbeat de l’instance master, chaque seconde.
\n– Une VIP<\/i> pour permettre de raccrocher les applications sur la nouvelle instance promue principale suite \u00e0 la bascule.<\/p>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/11\/gcp_ha_failover.gif\")
\n1) On attend que le failover replica ait termin\u00e9 de rejouer toutes les transactions en attente.
\n2) La VIP et le nom de l’instance master basculent sur le failover replica qui est promu nouveau master.
\n3) En arri\u00e8re plan, un nouveau failover replica est recr\u00e9\u00e9 dans une autre zone, c’est la raison pour laquelle il y a au moins 3 zones par r\u00e9gion. Si une zone compl\u00e8te est en \u00e9chec il en reste toujours deux pour assurer la disponibilit\u00e9. <\/p>\n
\n– Ils seront synchronis\u00e9s avec le master en utilisant la r\u00e9plication GTID asynchrone classique.
\n– Il n’est pas possible de faire des sauvegardes ou recr\u00e9er d’autres slaves \u00e0 partir d’un read replica.
\n– Ils peuvent \u00eatre externes \u00e0 GCP, de la m\u00eame mani\u00e8re un master peut \u00eatre externe aussi, ce qui va \u00eatre int\u00e9ressant dans le cas d’une migration:
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/11\/gcp_ha6.png\")
<\/p>\nBackup & restauration:<\/h3>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/11\/gcp_backup1.png\")
\n7 backups en ligne seront conserv\u00e9s, dans le marbre, pour un co\u00fbt du stockage \u00e0 $0.088\/mois\/GB (novembre 2018, R\u00e9gion europe-west4).<\/p>\n\r\n$ time gcloud sql backups create --instance=mysql-cap-cloud\r\nBacking up Cloud SQL instance...done. \r\n[https:\/\/www.googleapis.com\/sql\/v1beta4\/projects\/durable-epoch-220407\/instances\/mysql-cap-cloud] backed up.\r\n\r\nreal\t0m34.714s\r\nuser\t0m0.204s\r\nsys\t0m0.144s\r\n<\/pre>\n
\r\n$ gcloud sql backups list --instance=mysql-cap-cloud --sort-by=WINDOW_START_TIME\r\nID WINDOW_START_TIME ERROR STATUS\r\n1542664800648 2018-11-19T22:00:00.648+00:00 - SUCCESSFUL\r\n1543505077704 2018-11-29T15:24:37.704+00:00 - SUCCESSFUL\r\n1543505836176 2018-11-29T15:37:16.176+00:00 - SUCCESSFUL\r\n<\/pre>\n
\r\n$ gcloud sql backups restore 1543505077704 --restore-instance=mysql-cap-cloud --quiet\r\nRestoring Cloud SQL instance...done. \r\nRestored [https:\/\/www.googleapis.com\/sql\/v1beta4\/projects\/durable-epoch-220407\/instances\/mysql-cap-cloud].\r\n<\/pre>\n
\r\n$ gcloud sql backups restore 1543505077704 --backup-instance=mysql-cap-cloud --restore-instance=mysql-cap-cloud-2 --quiet\r\nRestoring Cloud SQL instance...done. \r\nRestored [https:\/\/www.googleapis.com\/sql\/v1beta4\/projects\/durable-epoch-220407\/instances\/mysql-cap-cloud-2].\r\n<\/pre>\n
\r\n$ gcloud sql instances describe mysql-cap-cloud | grep '^state'\r\nstate: MAINTENANCE\r\n<\/pre>\n
\r\ngcloud sql instances clone mysql-cap-cloud mysql-cap-cloud2\r\n<\/pre>\n
Arr\u00eat & red\u00e9marrage:<\/h3>\n
\r\n$ gcloud sql instances patch mysql-cap-cloud \\\r\n\t--activation-policy=ALWAYS\r\nPatching Cloud SQL instance...done. \r\nUpdated [https:\/\/www.googleapis.com\/sql\/v1beta4\/projects\/durable-epoch-220407\/instances\/mysql-cap-cloud].\r\n<\/pre>\n
\r\n$ gcloud sql instances patch mysql-cap-cloud \\\r\n\t--activation-policy=NEVER \r\nPatching Cloud SQL instance...done. \r\nUpdated [https:\/\/www.googleapis.com\/sql\/v1beta4\/projects\/durable-epoch-220407\/instances\/mysql-cap-cloud].\r\n<\/pre>\n
\r\n$ gcloud sql instances restart mysql-cap-cloud\r\nThe instance will shut down and start up again immediately if its \r\nactivation policy is "always." If "on demand," the instance will start\r\n up again when a new connection request is made.\r\n\r\nDo you want to continue (Y\/n)? Y\r\n\r\nRestarting Cloud SQL instance...done. \r\nRestarted [https:\/\/www.googleapis.com\/sql\/v1beta4\/projects\/durable-epoch-220407\/instances\/mysql-cap-cloud].\r\n<\/pre>\n
Fen\u00eatres de maintenance:<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/12\/gcp_maintenance.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/12\/gcp_maintenance2.png\")
<\/p>\nSupervision:<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/12\/gcp_metrics1.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/12\/stackdriver_perfcntr1.png\")
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2018\/12\/gcp_external_master.png\")
<\/p>\n