{"id":6755,"date":"2019-01-22T09:14:35","date_gmt":"2019-01-22T08:14:35","guid":{"rendered":"http:\/\/blog.capdata.fr\/?p=6755"},"modified":"2022-11-21T16:50:40","modified_gmt":"2022-11-21T15:50:40","slug":"comparatif-mysql-dans-le-paas-episode-2-azure","status":"publish","type":"post","link":"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/","title":{"rendered":"Comparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure"},"content":{"rendered":"\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>

Dans l’\u00e9pisode pr\u00e9c\u00e9dent, nous avions parl\u00e9 de MySQL sur Google Cloud Platform<\/a>, aujourd’hui nous allons comparer avec la solution propos\u00e9e par Microsoft sur Azure. <\/p>\n

MySQL et MariaDB dans le PaaS Azure<\/h2>\n

Si on rassemble toutes les bases de donn\u00e9es dans le PaaS Azure pour une photo de famille, on obtient ceci : <\/p>\n

\"\"<\/p>\n

– La partie de gauche regroupe les solutions bas\u00e9es sur le moteur maison<\/i> SQL Server. Nous ne manquerons pas de vous parler en d\u00e9tail de ces solutions lors de prochains posts.
\n– En bas \u00e0 droite, les bases non relationnelles type MongoDB \/ CosmosDB, dont on parlera aussi plus tard.
\n– Et enfin en haut \u00e0 droite, ce qui nous int\u00e9resse, les solutions open-source<\/i>, avec MySQL et PostgreSQL, mais aussi MariaDB qui fait son entr\u00e9e dans la liste et qui est en public preview depuis octobre 2018<\/a>. <\/p>\n

Cette offre MySQL \/ MariaDB reste encore tr\u00e8s jeune, MySQL n’\u00e9tant disponible en General Availability que depuis mars 2018, et MariaDB en preview donc depuis cet automne. Elle couvre les versions 5.6 et 5.7, ainsi que la version 10.2 pour MariaDB. <\/p>\n

Les deux solutions sont tr\u00e8s similaires sur le plan des fonctionnalit\u00e9s cloud donc je ne ferai pas d’\u00e9tude s\u00e9par\u00e9e. Il reste bien s\u00fbr les diff\u00e9rences intrins\u00e8ques : par exemple les histogrammes de stats sur MariaDB qui n’existent pas dans la version communautaire, etc… <\/p>\n

MySQL comme MariaDB ne sont pas d\u00e9ployables dans toutes les r\u00e9gions actuellement, notamment en France o\u00f9 seule la r\u00e9gion France Central<\/i> dispose d’Availability Zones, France South<\/i> n’\u00e9tant utilis\u00e9e qu’en disaster recovery<\/a> et pour des demandes clientes sp\u00e9cifiques :<\/p>\n

\"\"<\/p>\n

Caract\u00e9ristiques<\/h3>\n

– Versions 5.6, 5.7, MariaDB 10.2 comme d\u00e9j\u00e0 \u00e9voqu\u00e9
\n– Moteurs InnoDB et MEMORY support\u00e9s.
\n– Mise \u00e0 jour des releases mineures appliqu\u00e9es en automatique.
\n– Backups automatiques et restauration \u00e0 un point dans le temps.
\n– 4×9% de disponibilit\u00e9 (99.99%) annonc\u00e9e.
\n– Scaling dans les 2 sens mais avec des limitations. <\/p>\n

Les tiers disponibles<\/h3>\n

\"\"<\/p>\n

Quelques explications concernant les g\u00e9n\u00e9rations 4 et 5 de processeurs:
\n– CPU g\u00e9n\u00e9ration 4 : Intel E5-2673 v3 (Haswell) 2.4 GHz
\n– CPU g\u00e9n\u00e9ration 5 : Intel E5-2673 v4 (Broadwell) 2.3 GHz
\nSachant que seuls les gen 5 sont disponible en France. <\/p>\n

Attention plusieurs fonctionnalit\u00e9s ne seront disponibles qu’en General Purpose (GP) ou Memory Optimized (MO):
\n– La g\u00e9o redondance des backups et la possibilit\u00e9 de repartir sur une autre r\u00e9gion en cas de blackout r\u00e9gional.
\n– Le scale-down : on ne peut pas redescendre en Basic une fois pass\u00e9 en GP ou MO.
\n– R\u00e9plication avec master externe seulement en GP ou MO.
\n– Des read replicas peuvent \u00eatre cr\u00e9\u00e9s seulement en GP ou MO. <\/p>\n

On comprend donc que la survivabilit\u00e9 d’une instance en Basic sera tr\u00e8s limit\u00e9e, restreinte \u00e0 la r\u00e9gion dans laquelle elle aura \u00e9t\u00e9 cr\u00e9\u00e9e, et d\u00e9pendra essentiellement des backups automatiques et la capacit\u00e9 \u00e0 restaurer \u00e0 un point dans le temps. Si la criticit\u00e9 est \u00e9lev\u00e9e , ce ne sera pas le tier \u00e0 choisir dans le cas d’un d\u00e9ploiement en production. <\/p>\n

Le stockage<\/h3>\n

\"\"<\/p>\n

L\u00e0 encore, la performance disque va d\u00e9pendre de la volum\u00e9trie choisie, on retrouve la m\u00eame probl\u00e9matique de sur-dimensionnement du stockage qu’avec GCP. <\/p>\n

Le stockage de type Standard ne garantit rien en termes d’IOPS, et quant au stockage Premium, 3 IOPS\/Gb sont garantis avec un plafond \u00e0 6000 IOPS atteint avec 2Tb de stockage, ce qui reste tr\u00e8s en dessous de ce que propose GCP (les 6000 IOPS sont possibles avec seulement 200Gb provisionn\u00e9s). Mais l\u00e0 encore, en fonction du workload, cela peut suffire. Le probl\u00e8me est que si le plafond est atteint vous n’aurez pas d’autre choix que de travailler \u00e0 l’optimisation de vos requ\u00eates car il n’y aura plus de levier en termes de stockage. <\/p>\n

Autre diff\u00e9rence par rapport \u00e0 GCP, pas d’autoscaling du stockage en cas de d\u00e9passement de capacit\u00e9. En gros si le stockage arrive \u00e0 5% d’espace libre restant, l’instance va passer en lecture-seule et plus aucune transaction ne sera accept\u00e9e. D’o\u00f9 l’importance de bien mettre en place des alertes pour le suivi de cette partie volum\u00e9trie. <\/p>\n

Enfin, comme sur GCP le stockage peut \u00eatre augment\u00e9 mais jamais r\u00e9duit. <\/p>\n

Autres limitations<\/h3>\n

– 5000 connexions simultan\u00e9es maximum en fonction du tier choisi.
\n– Privil\u00e8ge SUPER indisponible, sans surprise.
\n– Chargements via LOAD DATA INFILE ou extraction via SELECT INTO OUTFILE non support\u00e9. Seul LOAD DATA LOCAL INFILE via un chemin UNC Azure est support\u00e9.
\n– Pas possible de redescendre de tier vers Basic.
\n– Pas possible de r\u00e9server une instance : par exemple 1 an ou 3 ans avec paiement upfront \u00e0 l’avance. Tout est en pay-as-you-go avec MySQL \/ MariaDB. Comme la r\u00e9servation est possible depuis ao\u00fbt<\/a> avec Azure SQL Databases (SQL Server monobase), on peut toujours esp\u00e9rer que \u00e7a arrive un jour pour les bases open source …
\n– Autre surprise en testant MariaDB, pas possible de cr\u00e9er des fonctions ou triggers car les instances sont toutes cr\u00e9\u00e9es avec le log binaire activ\u00e9 pour assurer la restauration PITR, et cela n\u00e9cessite d’activer le param\u00e8tre log_bin_trust_function_creators<\/a><\/i> qui est disponible pour Azure MySQL mais pas Azure MariaDB. Un oubli ? En tous cas un feedback a \u00e9t\u00e9 cr\u00e9\u00e9 esp\u00e9rons qu’il soit pris en compte par les \u00e9quipes de dev, merci de voter pour appuyer cette demande<\/a>. <\/p>\n

Les co\u00fbts<\/h3>\n

Si on reprend la m\u00eame configuration quelle celle utilis\u00e9e lors du premier test sur GCP<\/a>, on obtient en utilisant la calculette Azure<\/a> le r\u00e9sultat suivant:
\n– R\u00e9gion France Central
\n– General Purpose 16vCores Gen 5 d\u00e9marr\u00e9e 24\/7
\n– 80Gb de RAM (5Gb\/vCore)
\n– 200Gb stockage Premium (SSD 600 IOPS …)
\n– Volume snapshot de 1Tb (backups)
\n– Redondance G\u00e9ographique du stockage (GRS, 16×9’s de durabilit\u00e9)<\/p>\n

\"\"<\/p>\n

Le prix pour GCP \u00e9tait de 1670\u20ac \/ mois pour une config \u00e0 peu pr\u00e8s similaire en dehors de la RAM qui dans le cas d’Azure a un format impos\u00e9, et on peut \u00eatre tent\u00e9 de se dire que finalement Azure est moins cher de presque 4400\u20ac\/an…<\/p>\n

Mais je vous arr\u00eate tout de suite:
\n– Dans le cas de GCP, il est inclus un failover replica qui est factur\u00e9 au m\u00eame prix que l’instance principale. Dans Azure, il n’y a pas de failover replica, comme on va le voir un peu plus loin… Et sans le failover replica, la facture GCP s’\u00e9l\u00e8verait \u00e0 … 870\u20ac\/mois.
\n– 3 IOPS pour 200Gb \u00e7a fait 600 IOPS maximum, contre 4500 IOPS dans le cas de GCP.
\n– Et bien d’autres inconv\u00e9nients mais je ne veux pas spoiler, il va falloir lire la suite \ud83d\ude42<\/p>\n

Connectivit\u00e9 et outils d’administration<\/h3>\n

Le d\u00e9ploiement ne prend que quelques minutes. Ensuite pour se connecter il va falloir ouvrir des r\u00e8gles dans le pare-feu, notamment une qui autorise l’acc\u00e8s au port 3306 \u00e0 l’IP du client. Si le client se trouve sur votre PC, vous pouvez ouvrir votre IP publique en cliquant sur Securit\u00e9 de la connexion -> Ajouter une adresse IP cliente<\/i>:
\n\"\"<\/p>\n

Il est aussi possible de mettre des ranges d’adresses. <\/p>\n

Ensuite il faudra \u00e9valuer l’activation ou non de SSL pour encrypter la connexion, ce qui est \u00e9videmment recommand\u00e9 et activ\u00e9 par d\u00e9faut:
\n\"\"
\nPour pouvoir vous connecter il faudra alors r\u00e9cup\u00e9rer un certificat<\/a> et le d\u00e9ployer sur le ou les postes clients. <\/p>\n

\r\n$ mysql --host=mariadb-azr.mariadb.database.azure.com --port=3306 \\\r\n    --user="capdata@mariadb-azr" --password="********" \\\r\n    --ssl-ca=c:\\ssh\\BaltimoreCyberTrustRoot.crt.pem --execute="select version() ;"\r\n\r\n+---------------------+\r\n| version()           |\r\n+---------------------+\r\n| 10.2.17-MariaDB-log |\r\n+---------------------+\r\n<\/pre>\n
L’acc\u00e8s \u00e0 l’instance peut donc se faire soit via les outils de commande en ligne (mysql, mysqladmin, etc…) soit via les GUI type SQLYOG<\/a> ou MySQL Workbench<\/a>, mais aussi via les API disponibles dans plusieurs langages : ADO.NET, JDBC, Node.js, ODBC, PHP, Python, Ruby, Go, Java….<\/p>\n
Quant aux outils d’administration, comme pour GCP, il y a le portal azure bien s\u00fbr mais aussi le CLI Az<\/a><\/i> d\u00e9j\u00e0 utilis\u00e9 pour toutes les autres ressources dans Azure. Az<\/i> permet de piloter les ressources Azure mais pas de s’y connecter \u00e0 la diff\u00e9rence de gcloud. Les 3 branches principales permettent de g\u00e9rer le niveau instance (server<\/i>), base (base<\/i>) et de pouvoir t\u00e9l\u00e9charger les logs de requ\u00eates lentes (server-logs<\/i>):<\/p>\n
\"\"<\/p>\n
\r\nPS > az mysql server configuration show --name='tx_isolation' \r\n    --resource-group='ResGroup_Test' \r\n    --server='mysql-azr' \r\n    --query='{TXISOL:value}' \r\n    --output=table\r\nTXISOL\r\n---------------\r\nREPEATABLE-READ\r\n<\/pre>\n
Acc\u00e8s aux journaux<\/h3>\n
Seul le log de requ\u00eates lentes est accessible au format fichier. Il est conserv\u00e9 7 jours et renouvel\u00e9 chaque jour ou lorsqu’il atteint 7Gb. Le fichier est ensuite t\u00e9l\u00e9chargeable via la console :<\/p>\n
\"\"<\/p>\n
Ou via Azure CLI : <\/p>\n
\r\nPS> az mysql server-logs download \r\n    --name=mysql-slow-mysql-azr-2018122007.log \r\n    --resource-group=ResGroup_Test\r\n    --server-name=mysql-azr\r\n<\/pre>\n
Ensuite il sera possible de passer le fichier \u00e0 la moulinette mysqldumpslow ou pt-query-digest<\/a> pour avoir une version agr\u00e9g\u00e9e. Sachant que le param\u00e8tre @@performance_schema<\/i> est \u00e0 1 par d\u00e9faut sur Azure quel que soit le tier, les requ\u00eates pourront aussi \u00eatre agr\u00e9g\u00e9es manuellement \u00e0 partir de performance_schema. <\/p>\n
Configuration de l’instance MySQL<\/h3>\n
On trouve en tout 105 param\u00e8tres modifiables depuis la console ou Az CLI, contre 54 param\u00e8tres sur GCP. <\/p>\n
\r\nPS > az mariadb server configuration show --name='innodb_adaptive_hash_index' \r\n    --resource-group='ResGroup_Test' --server='mariadb-azr' \r\n    --query='{VALUE:value}'\r\n{\r\n  "VALUE": "ON"\r\n}\r\n<\/pre>\n
L\u00e0 c’est plut\u00f4t une bonne surprise, d’autant que l’event_scheduler est disponible et que performance_schema, certes inaccessible, est bloqu\u00e9 \u00e0 1 par d\u00e9faut. Les param\u00e8tres m\u00e9moire eux sont sans surprise inaccessibles<\/a> puisque d\u00e9pendants du tier choisi. <\/p>\n
Parmi les param\u00e8tres int\u00e9ressants on peut noter event_scheduler, histogram_size et histogram_type sur MariaDB, innodb_change_buffering, innodb_fill_factor, join_buffer_size, sort_buffer_size … query_cache_size n’est pas disponible mais il est coinc\u00e9 \u00e0 0 donc pas de query cache sur Azure MySQL ou MariaDB, ce qui n’est pas forc\u00e9ment un probl\u00e8me on le sait d\u00e9j\u00e0<\/a>. <\/p>\n
Sauvegarde et Restauration<\/h3>\n
Les sauvegardes sont g\u00e9r\u00e9es en automatique sur Azure, elles ne sont m\u00eame pas visibles, et on ne peut pas en faire manuellement, ni via la console ni via Az CLI. La politique est la suivante :
\n– Un backup complet par semaine.
\n– Un backup diff\u00e9rentiel deux fois par jour
\n– Des backups de logs binaires toutes les 5 minutes. <\/p>\n
La r\u00e9tention des backups est param\u00e9trable de 7 \u00e0 35 jours, et le co\u00fbt du stockage des backups est nul tant qu’il reste \u00e9gal au volume disque provisionn\u00e9.<\/p>\n
Par exemple si je provisionne 500Gb de stockage, je pourrai utiliser jusqu’\u00e0 500Gb d’espace de sauvegarde sans frais additionnels, mais l’allongement de la r\u00e9tention des sauvegardes utilisera davantage de stockage et donc potentiellement peut ajouter des frais suppl\u00e9mentaires. <\/p>\n
Avec un tier General Purpose \/ Memory Optimized, les backups peuvent \u00eatre stock\u00e9s dans plusieurs r\u00e9gions diff\u00e9rentes. Mais il faut le sp\u00e9cifier \u00e0 la cr\u00e9ation de l’instance, on ne pourra plus revenir dessus ensuite:<\/p>\n
\"\"<\/p>\n
Ce backup redond\u00e9 g\u00e9ographiquement va ensuite pouvoir \u00eatre utilis\u00e9 pour remonter une instance dans une autre r\u00e9gion en cas de perte de la r\u00e9gion nominale. Le tier Basic lui n’a pas le choix et conserve ses backups dans la r\u00e9gion d’origine. Si la r\u00e9gion est perdue, les backups Azure ne peuvent pas servir \u00e0 remonter l’instance ailleurs. Donc il faudra pr\u00e9voir des backups externes via mysqldump ou mysqlpump <\/a>\u00e0 partir de la 5.7.8.  <\/p>\n
Concernant la restauration, le bouton Restaurer<\/i> ou la commande az [ mysql | mariadb ] server [ restore | georestore ]<\/i> permettront de ramener l’instance (et donc toutes les bases) \u00e0 un point ant\u00e9rieur. Par contre on ne pourra pas restaurer sur la m\u00eame instance, la restauration va cr\u00e9er une nouvelle instance<\/b> avec un nouveau nom<\/b>:<\/p>\n
\"\"<\/p>\n
Ce qui n’est pas sans complications dans la mesure o\u00f9 une ressource ne peut pas \u00eatre renomm\u00e9e dans Azure. Cela implique donc qu’il ne faut jamais utiliser le nom de la ressource dans les cha\u00eenes de connexion<\/b> mais plut\u00f4t passer par un alias DNS. <\/p>\n
Dans le cas de backups locaux, le nouveau serveur cible sera n\u00e9cessairement dans la m\u00eame r\u00e9gion que le serveur origine. Dans le cas de backups g\u00e9ographiques, le nouveau serveur cible peut se trouver dans une r\u00e9gion diff\u00e9rente. <\/p>\n
Autre probl\u00e8me, une restauration ne remonte ni la configuration, ni les r\u00e8gles firewalls, ni les alertes. Pour l’instant on ne peut pas facilement utiliser le JSON de d\u00e9finition de ces objets pour industrialiser leur recr\u00e9ation, on attend donc que MS les int\u00e8gre pleinement dans la sauvegarde et la restauration … <\/p>\n
Enfin on rappelle un param\u00e8tre important qui est une constante sur Azure m\u00eame pour les autres bases dans le PaaS (SQL Database, PostgreSQL, etc…) : Lorsqu’une instance est supprim\u00e9e, elle ne pourra plus \u00eatre restaur\u00e9e car les backups sont supprim\u00e9s avec <\/b>. Pour \u00e9viter de tout perdre sur un malentendu, il est possible de mettre en place des verrous<\/i> logiques :<\/p>\n
– Un verrou en suppression<\/b>…
\n\"\"<\/p>\n
…qui emp\u00eachera un utilisateur de supprimer une instance :<\/p>\n
\r\nPS > az mariadb server delete --resource-group='ResGroup_Test' --name='mariadb-azr'\r\nAre you sure you want to perform this operation? (y\/n): y\r\nThe scope '\/subscriptions\/6a7dad37-ff9e-4f13-b63d-428d116b139c\/resourceGroups\/\r\nResGroup_Test\/providers\/Microsoft.DBforMariaDB\/servers\/mariadb-azr' \r\n\r\ncannot perform delete operation because following scope(s) are locked: \r\n'\/subscriptions\/6a7dad37-ff9e-4f13-b63d-428d116b139c\/resourceGroups\/\r\nResGroup_Test\/providers\/Microsoft.DBforMariaDB\/servers\/mariadb-azr'. \r\n\r\nPlease remove the lock and try again.\r\n<\/pre>\n
– Et un verrou en modification<\/b>…
\n\"\"
\n…qui emp\u00eachera un utilisateur de modifier les caract\u00e9ristiques d’une instance :<\/p>\n
\r\nPS > az mariadb server configuration set \r\n    --name='innodb_adaptive_hash_index' --resource-group='ResGroup_Test' \r\n    --server='mariadb-azr' --value='OFF'\r\n\r\nThe scope '\/subscriptions\/6a7dad37-ff9e-4f13-b63d-428d116b139c\/resourceGroups\/\r\nResGroup_Test\/providers\/Microsoft.DBforMariaDB\/servers\/mariadb-azr\/\r\nconfigurations\/innodb_adaptive_hash_index' \r\n\r\ncannot perform write operation because following scope(s) are locked: \r\n'\/subscriptions\/6a7dad37-ff9e-4f13-b63d-428d116b139c\/resourceGroups\/\r\nResGroup_Test\/providers\/Microsoft.DBforMariaDB\/servers\/mariadb-azr'. \r\n\r\nPlease remove the lock and try again.\r\n<\/pre>\n
Haute disponibilit\u00e9<\/h3>\n
Attention il n’y a pas de failover replica<\/strong> sur Azure MySQL ou Azure MariaDB. Donc il n’y a rien par d\u00e9faut qui permet de basculer automatiquement vers un replica pr\u00e9provisionn\u00e9 en cas de perte de la zone de disponibilit\u00e9 (AZ). C’est une diff\u00e9rence importante avec GCP. <\/p>\n
Il y a globalement deux cas de figure : un probl\u00e8me \u00e0 l’int\u00e9rieur d’une r\u00e9gion (probl\u00e8me mat\u00e9riel dans l’AZ, perte de l’AZ toute enti\u00e8re), ou un probl\u00e8me r\u00e9gional (perte de toute la r\u00e9gion). <\/p>\n
1) Concernant une perte mat\u00e9rielle locale \u00e0 l’AZ <\/b>, la doc indique <\/a> que la remont\u00e9e du service se fait automatiquement:<\/p>\n\n\n
\n“If a node-level interruption occurs, the database server automatically creates a new node and attaches data storage to the new node<\/strong>. Any active connections are dropped and any inflight transactions are not committed.”<\/em>\n<\/td>\n<\/tr>\n<\/table>\n
2) En revanche en cas de perte d’une r\u00e9gion<\/b>, l’issue va d\u00e9pendre du tier choisi: <\/p>\n
\"\"<\/p>\n
– Si vous \u00eates en Basic (et vous ne devriez pas, mais admettons), il vous faudra avoir pris soin de lancer des backups externes via un client soit sur Azure VM ou on-premise chez vous, en plus des backups automatiques, car ces derniers sont confin\u00e9s \u00e0 la r\u00e9gion dans laquelle se trouve l’instance. <\/p>\n
– Si vous \u00eates en General Purpose \/ Memory Optimized, et que vous avez choisi \u00e0 la cr\u00e9ation de l’instance un stockage g\u00e9ographique des backups<\/u>, alors vous pourrez remonter une instance dans une autre r\u00e9gion en utilisant ces backups. L’offre garantit un temps de restauration de 12 heures maximum et un RPO de 1hr, le temps de recopier le dernier backup disponible. Test\u00e9 sur une instance General Purpose et effectivement on peut bien remonter une instance dans une autre r\u00e9gion avec un backup \u00e0 moins d’une heure. <\/p>\n
Par s\u00e9curit\u00e9 c’est bien aussi de faire des backups via mysqldump de temps en temps et les conserver par exemple sur un storage Azure dans une autre r\u00e9gion. <\/p>\n
Conclusion : la notion de haute-disponibilit\u00e9 (99.99%)  est donc juste valide dans le cas d’un incident local \u00e0 l’AZ, pas dans le cas d’un incident au niveau r\u00e9gional. On se rappelle que dans le cas de GCP, le failover replica se trouvera dans une autre zone de la m\u00eame r\u00e9gion, donc couvre la perte de l’AZ. <\/p>\n
Fen\u00eatres de maintenance<\/h3>\n
L\u00e0 aussi il y a une diff\u00e9rence importante avec GCP, il n’y a pas sur Azure de fen\u00eatre de maintenance personnalisable par l’utilisateur. On en conclue donc que les instances peuvent \u00eatre coup\u00e9es \u00e0 n’importe quel moment sans pr\u00e9avis<\/strong>. <\/p>\n
Seuls les patches mineurs seront appliqu\u00e9s, donc pas de migration automatique de 5.6 en 5.7, et pas non plus de support de MySQL 8.0 ou MariaDB 10.3 ou 10.4 annonc\u00e9 pour l’instant. <\/p>\n
Arr\u00eat et d\u00e9marrage<\/h3>\n
Pour moi c’est le plus gros point noir de la solution: on ne peut pas arr\u00eater une instance, si on ne veut plus la payer on est oblig\u00e9 de la … supprimer.<\/b> Rien que de le dire d\u00e9j\u00e0, on pense \u00e0 une grosse blague…<\/p>\n
\"\"<\/p>\n
Donc si je r\u00e9sume, on est sur un service en pay-as-you-go<\/i>, pas possible de r\u00e9server de la capacit\u00e9 ni de payer un mois ou un an upfront en esp\u00e9rant avoir une r\u00e9duction, et on ne peut pas stopper le service si on ne l’utilise pas. On est oblig\u00e9 de le supprimer … et le recr\u00e9er … plus tard ? Sachant qu’on perd ses backups si on supprime une instance… <\/p>\n
Donc l’id\u00e9e d’avoir des environnements hors-prod, ou les environnements qui peuvent \u00eatre coup\u00e9s la nuit parce qu’il n’y a pas d’activit\u00e9, d\u00e9j\u00e0 vous pouvez l’\u00e9vacuer, \u00e7a c’est fait. Pas de r\u00e9duction possible des co\u00fbts dans le PaaS de cette mani\u00e8re. La seule fa\u00e7on qui reste est de r\u00e9duire le dimensionnement des machines: passer de 16 \u00e0 2 vCPUs pendant la nuit, pour remonter \u00e0 16 vCPUs le matin, etc… <\/p>\n
Et ce probl\u00e8me concerne la plupart des services dans le PaaS Azure, aussi bien les bases open-source que les bases SQL Server. Il y a eu \u00e9videmment des demandes de modification<\/a> de la part des utilisateurs, mais pour l’instant c’est closed by design<\/i> merci au revoir.<\/p>\n
\"\"<\/p>\n
C’est moche.<\/p>\n
Supervision<\/h3>\n
C\u00f4t\u00e9 m\u00e9trologie, Azure propose 15 compteurs pour MySQL \/ MariaDB, essentiellement orient\u00e9s PaaS et pas particuli\u00e8rement MySQL: Active Connections, Failed Connections, Backup Storage Used, CPU Percent, IO Percent, Storage Percent, etc… Plusieurs compteurs sont affichables dans le m\u00eame graphe ou dans des graphes s\u00e9par\u00e9s. Les graphes peuvent \u00eatre export\u00e9s sous forme de tableau de valeurs au format excel:<\/p>\n
\"\"<\/p>\n
Chaque compteur peut \u00eatre la source d’une alerte de m\u00e9trologie, ce qui est particuli\u00e8rement pratique pour le stockage dans la mesure o\u00f9 il ne s’\u00e9tend pas tout seul et bloque les mises \u00e0 jour \u00e0 95% de remplissage. Une alerte peut traiter des emails ou SMS en destination, avec un co\u00fbt annonc\u00e9 de 0.10 USD par alerte \u00e9mise (bien que les tarifs pour la France ne soient pas affich\u00e9s dans la doc<\/a>). Egalement une alerte sur la limite de connexions autoris\u00e9es (5000) peut \u00eatre int\u00e9ressante. <\/p>\n
Pour faire du scale-down de ressources, puisque c’est le seul moyen d’optimiser ses co\u00fbts, on peut aussi mettre des alertes sur des seuils de CPU et de m\u00e9moire, par exemple moins de 20% sur 16 vCPUs, ou moins de 5Gb de m\u00e9moire utilis\u00e9e, pour savoir quand r\u00e9duire. Le mettre sur les I\/Os ne sert \u00e0 rien puisqu’on ne peut pas r\u00e9duire le stockage une fois provisionn\u00e9. <\/p>\n
Pour ce qui est du monitoring des m\u00e9triques propres \u00e0 MySQL, on peut reprendre l’inventaire d\u00e9j\u00e0 fait pour GCP dans l’\u00e9pisode pr\u00e9c\u00e9dent:<\/p>\n\n\n\n\n\n
Analyse de performance g\u00e9n\u00e9rale<\/th>\nDisponibilit\u00e9 dans Cloud SQL<\/th>\n
PERFORMANCE_SCHEMA<\/td>\nLe param\u00e8tre est bien activ\u00e9 m\u00eame s’il n’est pas modifiable.<\/td>\n<\/tr>\n
VARIABLES DE STATUT<\/td>\nOK<\/td>\n<\/tr>\n
SHOW ENGINE INNODB STATUS<\/td>\nOK<\/td>\n<\/tr>\n
PARAMETRES ORIENTES PERFORMANCES<\/td>\nplus de param\u00e8tres disponibles par rapport \u00e0 GCP, par exemple join_buffer_size ou sort_buffer_size.<\/td>\n<\/tr>\n<\/table>\n
<\/p>\n\n\n\n\n\n\n
Analyse de requ\u00eates<\/th>\nDisponibilit\u00e9 dans Cloud SQL<\/th>\n
EXPLAIN<\/td>\nOK<\/td>\n<\/tr>\n
@@optimizer_switch<\/td>\nM\u00eames remarques que pour GCP, BKA est \u00e0 OFF par d\u00e9faut, le param\u00e8tre n’est pas modifiable en GLOBAL<\/td>\n<\/tr>\n
SET OPTIMIZER TRACE=1<\/td>\nOK (dans la session)<\/td>\n<\/tr>\n
Param\u00e8tres requ\u00eates lentes<\/td>\nlog_queries_not_using_indexes, log_slow_admin_statements, log_slow_slave_statements, et long_query_time sont param\u00e9trables. Le fichier est ensuite disponible au t\u00e9l\u00e9chargement via le portal ou Az CLI pour retraitement<\/td>\n<\/tr>\n
SET PROFILING=1<\/td>\nOK<\/td>\n<\/tr>\n<\/table>\n
Replication<\/h3>\n
\"\"
\nDeux types de r\u00e9plication sont possibles:
\n– Soit configurer une instance MySQL dans le PaaS comme un slave, \u00e0 partir d’un master externe, ce qui est plut\u00f4t une bonne nouvelle pour les aspects migration notamment.
\n– Soit configurer des read replicas \u00e0 partir d’une instance MySQL dans le PaaS. La limite est fix\u00e9e \u00e0 5 read replicas maximum.<\/p>\n
Les deux solutions ne sont accessibles que pour les tiers General Purpose et Memory Optimized. <\/p>\n
Il y a quelques restrictions par exemple le master on-premise et le slave dans le PaaS doivent tous les deux avoir la m\u00eame version majeure (tous les deux en 5.6, ou tous les deux en 5.7), le seul moteur autoris\u00e9 c\u00f4t\u00e9 master reste InnoDB, les journaux binaires doivent \u00eatre activ\u00e9s sur le master, mais bon rien de particulier en soi. Comme c’est une r\u00e9plication asynchrone classique \u00e0 base de binlog \/ positions et pas une GTID, il n’y a pas de restriction sur la version du master comme pour GCP. <\/p>\n
C\u00f4t\u00e9 read replicas, il y a aussi quelques diff\u00e9rences annonc\u00e9es, notamment le fait que le master peut \u00eatre supprim\u00e9 ind\u00e9pendamment des read replicas, qui restent en tant qu’instances standalone ensuite. Au d\u00e9part le replica poss\u00e8de les m\u00eames caract\u00e9ristiques que le master en termes de dimensionnement, param\u00e9trage, etc… mais cela peut \u00eatre chang\u00e9 ensuite. <\/p>\n
Enfin, comme pour GCP, le privil\u00e8ge SUPER \u00e9tant verrouill\u00e9 il existe un lot de proc\u00e9dures stock\u00e9es dans le sch\u00e9ma syst\u00e8me mysql pour g\u00e9rer les aspects r\u00e9plication : CHANGE MASTER TO par exemple est remplac\u00e9 par la proc\u00e9dure mysql.az_replication_change_master<\/i>. <\/p>\n
Migrer sur Azure MySQL \/ MariaDB<\/h3>\n
Dans le cas d’Azure, les possibilit\u00e9s sont \u00e9quivalentes \u00e0 ce que propose GCP :
\n– Soit une migration via mysqldump et restauration dans le PaaS si le temps d’interruption le permet.
\n– Sinon via une r\u00e9plication avec un master externe, si les contraintes de version notamment le permettent.
\n– Il existe enfin un outil sur le portal sp\u00e9cialis\u00e9 pour la migration de bases on-prem vers le cloud Azure : Azure database Migration Service<\/a>. Mais le sujet est vaste est m\u00e9rite un article complet. <\/p>\n
Attention on rappelle que pour l’instant MariaDB ne supporte pas les fonctions \/ triggers, peut \u00eatre que ce sera adopt\u00e9 avec le passage en GA. <\/p>\n
Azure vs GCP, le match<\/h2>\n
D\u00e9j\u00e0 si on compare les deux configurations du point de vue du co\u00fbt:
\n\"\"<\/p>\n
Le simple fait que la solution GCP int\u00e8gre un failover replica pr\u00e9-provisionn\u00e9 pour g\u00e9rer la bascule automatique en cas de perte d’une r\u00e9gion, \u00e7a change tout au niveau du prix. L’\u00e9quivalent n’existe pas sur Azure, et si vous ne voulez pas de failover replica dans GCP, il suffit de ne pas cocher la case et l’addition retombe \u00e0 870\u20ac\/mois. <\/p>\n
Si on compare au niveau des fonctionnalit\u00e9s principales:<\/p>\n
\"\"<\/p>\n
Les avantages d’Azure par rapport \u00e0 GCP:<\/strong>
\n– D\u00e9j\u00e0 le fait de proposer MariaDB en plus de la version communautaire. Il y a beaucoup de fonctions sophistiqu\u00e9es dans MariaDB qui n’existent pas chez les autres fournisseurs MySQL \u00e0 l’heure actuelle.
\n– Les 35 jours de r\u00e9tention des backups
\n– Le nombre de param\u00e8tres modifiables plus important que sur GCP.
\n– Le moteur MEMORY support\u00e9 pour les tables temporaires (attention toutefois en cas de r\u00e9plication)<\/p>\n
Les points faibles d’Azure par rapport \u00e0 GCP:<\/strong>
\n– Pas de vraie solution de haute disponibilit\u00e9. Il n’est pas du tout pr\u00e9vu un failover replica m\u00eame d\u00e9j\u00e0 dans une AZ diff\u00e9rente et dans la m\u00eame r\u00e9gion. Les 99.99% ne s’appliquent que sur un incident \u00e0 l’int\u00e9rieur d’une zone (incident mat\u00e9riel sur un noeud par exemple), pas en cas de perte de la zone toute enti\u00e8re (coupure datacenter), ou de la r\u00e9gion (incident r\u00e9seau g\u00e9n\u00e9ral). Dans ce cas seuls les backups g\u00e9or\u00e9pliqu\u00e9s sur les tiers General Purpose et Memory Optimized peuvent \u00eatre utilis\u00e9s.
\n– Pas de choix sur les fen\u00eatres d’application des patches. Les mises \u00e0 jour peuvent donc se faire sans pr\u00e9avis.
\n– Pas de possibilit\u00e9 de couper un service qui ne serait pas utilis\u00e9. On est oblig\u00e9 de r\u00e9duire le dimensionnement du tier ou heuuu … supprimer les donn\u00e9es et les backups qui vont avec.
\n– Pas de possibilit\u00e9 de restaurer un backup sur l’instance source. La restauration cr\u00e9\u00e9 une nouvelle instance avec un nouveau nom, avec la complication de gestion des noms de ressource dans les cha\u00eenes de connexion ou dans les annuaires DNS. <\/p>\n
En conclusion<\/h2>\n
L’offre PaaS d’Azure pour MySQL ou MariaDB est encore tr\u00e8s jeune. Au vu du nombre de suggestions dans le feedback azure (37 en cours pour MySQL et seulement 4 pour MariaDB au 4 janvier 2019), on peut supposer que l’adoption reste pour l’instant tr\u00e8s faible. Certaines suggestions<\/a> expliquent aussi pourquoi les clients pr\u00e9f\u00e8rent rester chez le concurrent : l’offre manque de maturit\u00e9 et de souplesse, notamment le fait de ne pas pouvoir stopper le service pour arr\u00eater de le payer. Erreurs de jeunesse, quoi. Il faudra refaire le match dans un an !<\/p>\n
D’autant que la course n’est pas termin\u00e9e, mais il faut reconna\u00eetre que jusqu’\u00e0 aujourd’hui, Cloud SQL sur GCP semble une option bien plus viable pour faire tourner une production MySQL dans le PaaS. <\/p>\n
Il nous reste encore \u00e0 voir un autre concurrent tr\u00e8s s\u00e9rieux : Amazon avec ses solutions RDS MySQL et Aurora MySQL. La suite au prochain \u00e9pisode !<\/p>\n
A bient\u00f4t !<\/p>\n
David B.<\/p>\n\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>","protected":false},"excerpt":{"rendered":"
Dans l’\u00e9pisode pr\u00e9c\u00e9dent, nous avions parl\u00e9 de MySQL sur Google Cloud Platform, aujourd’hui nous allons comparer avec la solution propos\u00e9e par Microsoft sur Azure. MySQL et MariaDB dans le PaaS Azure Si on rassemble toutes les bases de donn\u00e9es dans… Continuer la lecture →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":6931,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[282,4],"tags":[297],"class_list":["post-6755","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","category-mysql","tag-cloud"],"yoast_head":"\nComparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure - Capdata TECH BLOG<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Comparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure - Capdata TECH BLOG\" \/>\n<meta property=\"og:description\" content=\"Dans l’\u00e9pisode pr\u00e9c\u00e9dent, nous avions parl\u00e9 de MySQL sur Google Cloud Platform, aujourd’hui nous allons comparer avec la solution propos\u00e9e par Microsoft sur Azure. MySQL et MariaDB dans le PaaS Azure Si on rassemble toutes les bases de donn\u00e9es dans… Continuer la lecture →\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/\" \/>\n<meta property=\"og:site_name\" content=\"Capdata TECH BLOG\" \/>\n<meta property=\"article:published_time\" content=\"2019-01-22T08:14:35+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-11-21T15:50:40+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/01\/paas_azure.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1311\" \/>\n\t<meta property=\"og:image:height\" content=\"739\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"David Baffaleuf\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"\u00c9crit par\" \/>\n\t<meta name=\"twitter:data1\" content=\"David Baffaleuf\" \/>\n\t<meta name=\"twitter:label2\" content=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\n\t<meta name=\"twitter:data2\" content=\"22 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/\"},\"author\":{\"name\":\"David Baffaleuf\",\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf\"},\"headline\":\"Comparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure\",\"datePublished\":\"2019-01-22T08:14:35+00:00\",\"dateModified\":\"2022-11-21T15:50:40+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/\"},\"wordCount\":4390,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/blog.capdata.fr\/#organization\"},\"keywords\":[\"cloud\"],\"articleSection\":[\"Azure\",\"MySQL\"],\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/\",\"url\":\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/\",\"name\":\"Comparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure - Capdata TECH BLOG\",\"isPartOf\":{\"@id\":\"https:\/\/blog.capdata.fr\/#website\"},\"datePublished\":\"2019-01-22T08:14:35+00:00\",\"dateModified\":\"2022-11-21T15:50:40+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/blog.capdata.fr\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Comparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.capdata.fr\/#website\",\"url\":\"https:\/\/blog.capdata.fr\/\",\"name\":\"Capdata TECH BLOG\",\"description\":\"Le blog technique sur les bases de donn\u00e9es de CAP DATA Consulting\",\"publisher\":{\"@id\":\"https:\/\/blog.capdata.fr\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.capdata.fr\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/blog.capdata.fr\/#organization\",\"name\":\"Capdata TECH BLOG\",\"url\":\"https:\/\/blog.capdata.fr\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp\",\"contentUrl\":\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp\",\"width\":800,\"height\":254,\"caption\":\"Capdata TECH BLOG\"},\"image\":{\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.linkedin.com\/company\/cap-data-consulting\/mycompany\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf\",\"name\":\"David Baffaleuf\",\"sameAs\":[\"http:\/\/www.capdata.fr\"],\"url\":\"https:\/\/blog.capdata.fr\/index.php\/author\/dbaffaleuf\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Comparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure - Capdata TECH BLOG","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/","og_locale":"fr_FR","og_type":"article","og_title":"Comparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure - Capdata TECH BLOG","og_description":"Dans l’\u00e9pisode pr\u00e9c\u00e9dent, nous avions parl\u00e9 de MySQL sur Google Cloud Platform, aujourd’hui nous allons comparer avec la solution propos\u00e9e par Microsoft sur Azure. MySQL et MariaDB dans le PaaS Azure Si on rassemble toutes les bases de donn\u00e9es dans… Continuer la lecture →","og_url":"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/","og_site_name":"Capdata TECH BLOG","article_published_time":"2019-01-22T08:14:35+00:00","article_modified_time":"2022-11-21T15:50:40+00:00","og_image":[{"width":1311,"height":739,"url":"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/01\/paas_azure.png","type":"image\/png"}],"author":"David Baffaleuf","twitter_card":"summary_large_image","twitter_misc":{"\u00c9crit par":"David Baffaleuf","Dur\u00e9e de lecture estim\u00e9e":"22 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/#article","isPartOf":{"@id":"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/"},"author":{"name":"David Baffaleuf","@id":"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf"},"headline":"Comparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure","datePublished":"2019-01-22T08:14:35+00:00","dateModified":"2022-11-21T15:50:40+00:00","mainEntityOfPage":{"@id":"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/"},"wordCount":4390,"commentCount":0,"publisher":{"@id":"https:\/\/blog.capdata.fr\/#organization"},"keywords":["cloud"],"articleSection":["Azure","MySQL"],"inLanguage":"fr-FR","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/","url":"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/","name":"Comparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure - Capdata TECH BLOG","isPartOf":{"@id":"https:\/\/blog.capdata.fr\/#website"},"datePublished":"2019-01-22T08:14:35+00:00","dateModified":"2022-11-21T15:50:40+00:00","breadcrumb":{"@id":"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/blog.capdata.fr\/index.php\/comparatif-mysql-dans-le-paas-episode-2-azure\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/blog.capdata.fr\/"},{"@type":"ListItem","position":2,"name":"Comparatif MySQL dans le PaaS, \u00e9pisode 2 : Azure"}]},{"@type":"WebSite","@id":"https:\/\/blog.capdata.fr\/#website","url":"https:\/\/blog.capdata.fr\/","name":"Capdata TECH BLOG","description":"Le blog technique sur les bases de donn\u00e9es de CAP DATA Consulting","publisher":{"@id":"https:\/\/blog.capdata.fr\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.capdata.fr\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"fr-FR"},{"@type":"Organization","@id":"https:\/\/blog.capdata.fr\/#organization","name":"Capdata TECH BLOG","url":"https:\/\/blog.capdata.fr\/","logo":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/","url":"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp","contentUrl":"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp","width":800,"height":254,"caption":"Capdata TECH BLOG"},"image":{"@id":"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.linkedin.com\/company\/cap-data-consulting\/mycompany\/"]},{"@type":"Person","@id":"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf","name":"David Baffaleuf","sameAs":["http:\/\/www.capdata.fr"],"url":"https:\/\/blog.capdata.fr\/index.php\/author\/dbaffaleuf\/"}]}},"_links":{"self":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts\/6755","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/comments?post=6755"}],"version-history":[{"count":43,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts\/6755\/revisions"}],"predecessor-version":[{"id":9507,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts\/6755\/revisions\/9507"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/media\/6931"}],"wp:attachment":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/media?parent=6755"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/categories?post=6755"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/tags?post=6755"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}