Chapitre 912 minIntermédiaire
Base de données managée : Azure Database for MySQL
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- dire ce qu'une base managée prend en charge à ta place ;
- créer un serveur MySQL flexible et ouvrir son pare-feu au strict nécessaire ;
- importer une base et s'y connecter en TLS ;
- restaurer la base à un instant précis.
4 exercices corrigés
Une base de données managée est un serveur de bases de données fourni en PaaS : le fournisseur l'installe, le met à jour, le sauvegarde et le surveille, et toi, tu crées tes tables et tu écris tes requêtes. Chez Microsoft, le service s'appelle Azure Database for MySQL, en déploiement « serveur flexible » ; il fait tourner MySQL Community, la même base que dans le cours SQL. Ce chapitre montre ce que le service prend en charge, comment choisir sa taille, sa version et son mode réseau, puis il importe la base parc de Sorbier dans Azure et la restaure à un instant précis.
Ce que la base managée fait à ta place
| Tâche | MySQL installé sur une VM | Azure Database for MySQL |
|---|---|---|
| Installer, configurer le système et MySQL | Toi | Microsoft |
| Correctifs de sécurité de l'OS et de MySQL | Toi | Microsoft, pendant une fenêtre de maintenance que tu peux choisir |
| Sauvegardes | Toi (mysqldump, scripts, supervision) | Automatiques, conservées de 1 à 35 jours (7 par défaut) |
| Restauration à un instant précis | Journal binaire à rejouer à la main | Une commande, vers un nouveau serveur |
| Haute disponibilité | Réplication à monter et à surveiller | Une option : serveur de secours dans la même zone ou dans une autre zone |
| Supervision | À installer | Métriques et alertes intégrées |
| Tables, requêtes, comptes de l'application, index | Toi | Toi |
Tu perds en échange l'accès au système : pas de connexion SSH, pas de compte root complet, certains paramètres seulement modifiables. Pour une application classique, c'est un bon marché.
Choisir le niveau, la taille et la version
Le niveau de calcul.
| Niveau | Tailles | Pour quoi | Haute disponibilité |
|---|---|---|---|
| Burstable | B1s, B1ms, B2s… | Développement, petites applications peu chargées | Non |
| General Purpose | D2ds v4 et plus | La plupart des applications en production | Oui |
Business Critical (MemoryOptimized dans la CLI) | E2ds v4 et plus | Charges lourdes, beaucoup de mémoire | Oui |
Le lab utilise B1ms (1 vCPU, 2 Gio), qui fait partie des services gratuits pendant 12 mois (750 heures par mois, avec 32 Go de stockage). Avec la haute disponibilité redondante entre zones, Microsoft s'engage sur une disponibilité jusqu'à 99,99 % (chapitre 13).
La version de MySQL. En novembre 2026, Azure propose MySQL 8.0 et 8.4. MySQL 8.4 est la version à support long (LTS) de référence, celle du cours SQL. MySQL 8.0 n'est plus maintenue par la communauté depuis avril 2026 ; Azure la maintient encore jusqu'au 31 janvier 2027, puis la bascule dans un support étendu payant. MySQL 5.7 est déjà dans ce cas.
Réseau : accès public filtré ou accès privé
| Mode | Fonctionnement | Quand |
|---|---|---|
| Accès public, adresses autorisées | Le serveur a une adresse publique ; un pare-feu n'accepte que les adresses listées dans ses règles | Labs, petites applications ; à limiter au strict nécessaire |
| Accès privé (intégration à un réseau virtuel) | Le serveur n'a qu'une adresse privée dans un sous-réseau dédié ; seules les ressources de ce réseau, ou reliées à lui (VPN, appairage), le joignent | Production : rien n'est exposé à Internet |
Dans les règles de pare-feu, l'adresse 0.0.0.0 a un sens particulier : elle autorise tous les services d'Azure, y compris ceux des autres clients d'Azure. Microsoft réserve ce réglage au développement et aux tests.
Les connexions sont chiffrées par TLS : le serveur refuse par défaut les connexions en clair. Son certificat est signé par l'autorité DigiCert Global Root G2, présente dans les magasins de certificats des systèmes et de Node.js.
Lab : la base parc de Sorbier dans Azure
1. Crée le serveur. Son nom devient <nom>.mysql.database.azure.com : il doit être unique dans tout Azure.
az group create --name rg-cloud-lab --location francecentral --tags cours=cloud
MON_IP=$(curl -s https://api.ipify.org)
SERVEUR=mysql-parc-jc42
# Le mot de passe est saisi sans s'afficher : 8 à 128 caractères, avec au moins
# trois types parmi majuscules, minuscules, chiffres et symboles
read -rs -p "Mot de passe de l'administrateur : " MDP_ADMIN; echo
az mysql flexible-server create \
--resource-group rg-cloud-lab \
--name "$SERVEUR" \
--location francecentral \
--tier Burstable \
--sku-name Standard_B1ms \
--version 8.4 \
--storage-size 32 \
--admin-user sioadmin \
--admin-password "$MDP_ADMIN" \
--public-access "$MON_IP" \
--high-availability Disabled
La création prend cinq à dix minutes. --public-access avec ton adresse crée la première règle de pare-feu. Si la commande refuse la version 8.4, mets à jour l'Azure CLI (az upgrade).
2. Importe la base parc. Télécharge le script du cours SQL et envoie-le au serveur avec le client mysql.
curl -O https://reussirmonbtssio.com/fichiers/sql/parc.sql
# Client MySQL d'Oracle (et celui de Cloud Shell)
mysql -h "$SERVEUR.mysql.database.azure.com" -u sioadmin -p --ssl-mode=REQUIRED < parc.sql
# Client MariaDB (paquet `default-mysql-client` de Debian) : l'option s'appelle --ssl
mysql -h "$SERVEUR.mysql.database.azure.com" -u sioadmin -p --ssl < parc.sql
3. Vérifie, puis crée le compte de l'application avec le seul droit dont elle a besoin (cours SQL).
-- Connecté en sioadmin
SELECT COUNT(*) AS nb_postes FROM parc.poste;
-- nb_postes : 15
CREATE USER 'app_parc'@'%' IDENTIFIED BY 'un-mot-de-passe-long-et-unique';
GRANT SELECT ON parc.* TO 'app_parc'@'%';
L'application du chapitre 10 se connectera avec app_parc, jamais avec le compte administrateur. Le serveur refuse en plus les connexions sans TLS, quel que soit le compte.
4. Observe les sauvegardes et restaure à un instant précis. Les sauvegardes sont automatiques. La restauration ne remplace pas le serveur : elle en crée un nouveau, dans l'état exact de l'instant demandé.
# Le plus ancien instant restaurable
az mysql flexible-server show --resource-group rg-cloud-lab --name "$SERVEUR" \
--query backup.earliestRestoreDate --output tsv
# Restaurer l'état du serveur à 14 h 00 UTC, dans un nouveau serveur
az mysql flexible-server restore \
--resource-group rg-cloud-lab \
--name "$SERVEUR-restaure" \
--source-server "$SERVEUR" \
--restore-time "2026-11-08T14:00:00+00:00"
Remplace la date par un instant situé après la création de ton serveur. Un serveur restauré est facturé comme un autre : supprime-le dès que tu as vérifié son contenu.
5. Arrête ou supprime. az mysql flexible-server stop arrête le calcul (le stockage reste facturé) ; au bout de 30 jours d'arrêt, le serveur redémarre tout seul. Pour un lab, supprime tout :
az group delete --name rg-cloud-lab --yes --no-wait
Exercices
Exercice 1 sur 4 Base managée ou VM ? Réussi À revoir
Pour chaque situation, choisis entre une base managée (PaaS) et MySQL installé sur une VM (IaaS), et justifie.
- Une petite équipe de développeurs, sans administrateur système, lance l'application de réservation des quais de l'entrepôt.
- Un éditeur impose un plugin MySQL qui demande un accès au système de fichiers du serveur.
- Une application critique doit survivre à la panne d'un centre de données, avec un minimum de travail d'exploitation.
Voir la réponseMasquer la réponse de l'exercice 1
- Base managée : les sauvegardes, les correctifs et la supervision sont pris en charge ; l'équipe se concentre sur l'application.
- VM : la base managée ne donne pas accès au système de fichiers ni à tous les plugins. Seul un serveur dont on maîtrise le système convient, avec toute l'administration qui va avec.
- Base managée en niveau General Purpose ou Business Critical, avec la haute disponibilité redondante entre zones : un serveur de secours dans une autre zone prend le relais automatiquement. Le faire soi-même sur des VM demanderait de monter et surveiller une réplication.
Tu avais trouvé ?
Exercice 2 sur 4 Une règle de pare-feu inquiétante Réussi À revoir
Sur le serveur de production de Sorbier, tu trouves la règle de pare-feu tout-le-monde, de 0.0.0.0 à 255.255.255.255. Le développeur explique : « Sinon l'application ne se connectait pas. » Explique le risque, puis propose deux corrections, de la plus rapide à la plus solide.
Voir la réponseMasquer la réponse de l'exercice 2
Le risque : le port 3306 du serveur accepte des connexions de toute adresse d'Internet. Il ne reste que le mot de passe pour protéger la base, face aux robots qui testent en permanence les services exposés. Une fuite ou un mot de passe faible suffit à exposer les données des clients.
Corrections :
- Rapide : supprimer la règle et n'autoriser que les adresses sortantes de l'application (une application App Service les affiche avec
az webapp show --query outboundIpAddresses), plus l'adresse d'administration du siège. - Solide : passer la base en accès privé dans le réseau virtuel de Sorbier, relié à l'application (intégration au réseau virtuel d'App Service) et au siège par le VPN. La base n'a plus d'adresse publique du tout. Comme le mode réseau ne se change pas après la création, on crée un nouveau serveur en accès privé et on y restaure les données.
Tu avais trouvé ?
Exercice 3 sur 4 Le DELETE sans WHERE Réussi À revoir
Le jeudi 6 novembre 2026 à 14 h 32 (heure de Paris), un technicien lance DELETE FROM ticket; au lieu de supprimer un seul ticket. La rétention des sauvegardes est de 7 jours. Que fais-tu, étape par étape ? Quelle perte de données subit Sorbier ?
Voir la réponseMasquer la réponse de l'exercice 3
- Noter l'heure exacte de l'erreur : 14 h 32 à Paris, soit 13 h 32 UTC (Paris est à UTC+1 en novembre).
- Restaurer le serveur à 13 h 31 UTC, juste avant l'erreur, dans un nouveau serveur :
az mysql flexible-server restore ... --restore-time "2026-11-06T13:31:00+00:00". C'est possible, car l'instant est dans la fenêtre de 7 jours. - Récupérer les tables touchées du serveur restauré :
ticket, mais aussiintervention, car sa clé étrangère versticketest enON DELETE CASCADE: leDELETEa effacé toutes les interventions avec les tickets. On les exporte avecmysqldump parc ticket intervention, puis on les réimporte dans le serveur de production. Restaurer ces deux tables plutôt que tout le serveur évite de perdre les modifications faites ailleurs depuis 14 h 32. - Contrôler les données, puis supprimer le serveur restauré.
La perte : seuls les tickets et interventions créés ou modifiés entre 14 h 31 et la réimportation manquent, s'il y en a ; on les ressaisit à partir des courriels ou des notes des techniciens. Pour éviter que cela se reproduise : des comptes nominatifs sans droit DELETE sur toute la table pour le travail courant, et des transactions (cours SQL).
Tu avais trouvé ?
Exercice 4 sur 4 La fin de support de MySQL 8.0 Réussi À revoir
Le serveur de l'application de paie d'un client tourne en MySQL 8.0 sur Azure. Que se passe-t-il le 1er février 2027 s'il ne fait rien ? Que lui conseilles-tu ?
Voir la réponseMasquer la réponse de l'exercice 4
Le 1er février 2027, le serveur passe automatiquement en support étendu, facturé en plus par vCore et par heure : il continue de recevoir les correctifs de sécurité critiques, mais coûte plus cher. Conseille-lui de planifier la montée de version vers MySQL 8.4 : tester l'application sur une copie (un serveur restauré, par exemple), vérifier les comptes qui utilisent encore l'authentification mysql_native_password (la valeur par défaut de 8.4 est caching_sha2_password), faire une sauvegarde à la demande, puis lancer la mise à niveau (az mysql flexible-server upgrade --version 8.4) pendant une fenêtre de maintenance annoncée aux utilisateurs. En Burstable, la CLI refuse cette mise à niveau : on passe par le portail, qui bascule le serveur en General Purpose le temps de l'opération, ou par un export mysqldump restauré sur un nouveau serveur 8.4.
Tu avais trouvé ?