Une agence gérait ses quarante sites WordPress avec une base MySQL locale sur chaque VPS, une architecture simple mais qui reportait sur l’équipe technique toute la charge d’administration : mises à jour de sécurité MySQL, ajustement de la configuration, gestion des sauvegardes propres à chaque instance. La décision a été prise de centraliser l’ensemble des bases vers Amazon RDS, un service de base de données managée qui prend en charge les correctifs, les sauvegardes automatiques et la réplication, moyennant un coût mensuel supérieur à l’auto-hébergement.
Migrer quarante bases en une fois demande une méthodologie répétable, pas une improvisation site par site : la même procédure, testée sur un premier site pilote, puis appliquée en série sur les trente-neuf suivants, avec une fenêtre de maintenance groupée un dimanche matin pour limiter l’impact cumulé sur les visiteurs.
Préparer l’instance RDS avant toute migration
Une instance RDS MySQL se provisionne avec un paramétrage propre, distinct d’un MySQL classique sur ses points les plus sensibles : RDS ne donne pas accès direct au système de fichiers ni à certaines variables globales réservées à AWS (comme innodb_flush_log_at_trx_commit modifiable seulement via un groupe de paramètres dédié, pas via un fichier my.cnf local).
aws rds create-db-instance \
--db-instance-identifier wp-agence-prod \
--db-instance-class db.t3.medium \
--engine mysql \
--engine-version 8.0.32 \
--allocated-storage 100 \
--master-username admin_agence \
--master-user-password 'xxxxxxxxxxxx' \
--multi-az
L’option --multi-az provisionne une instance de secours synchronisée dans une autre zone de disponibilité, avec bascule automatique en cas de panne de l’instance principale — un niveau de résilience que l’agence n’offrait à aucun de ses clients auparavant sur ses VPS individuels.
Migrer une première base pilote pour valider la méthode
Le dump classique via mysqldump reste l’outil le plus simple pour ce volume de données, avec une option cruciale pour la compatibilité RDS : exclure les commandes qui nécessitent des privilèges non disponibles sur une instance managée.
mysqldump --single-transaction --no-tablespaces \
-u client01 -p wordpress_client01 > client01.sql
mysql -h wp-agence-prod.xxxxxxxxxx.eu-west-3.rds.amazonaws.com \
-u admin_agence -p wordpress_client01 < client01.sql
L'option --no-tablespaces évite une erreur fréquente sur RDS, où l'utilisateur administrateur fourni par AWS ne dispose pas du privilège PROCESS nécessaire à l'export des tablespaces, une restriction spécifique aux instances managées absente d'un MySQL auto-hébergé classique.
Industrialiser la migration des trente-neuf bases restantes
Une fois la méthode validée sur le site pilote, un script a automatisé l'export et l'import successifs de chaque base restante, avec une vérification systématique du nombre de lignes de la table wp_posts entre source et destination avant de considérer chaque migration comme réussie.
#!/bin/bash
for site in $(cat liste-sites.txt); do
mysqldump --single-transaction --no-tablespaces -u "$site" -p"$MDP" "wordpress_$site" > "/tmp/$site.sql"
mysql -h "$RDS_HOST" -u admin_agence -p"$MDP_RDS" "wordpress_$site" < "/tmp/$site.sql"
echo "Migré : $site"
done
Adapter wp-config.php et vérifier la latence réseau
Chaque site pointait désormais vers l'endpoint RDS commun plutôt que vers localhost, un changement qui introduit une latence réseau supplémentaire (même minime, RDS restant dans la même région AWS que les VPS). Un test de temps de réponse avant et après migration a confirmé un impact négligeable pour l'ensemble des sites, à l'exception d'un site à fort volume de requêtes où un ajustement du pool de connexions a été nécessaire.
- Provisionner l'instance RDS dans la même région, voire la même zone de disponibilité que les serveurs applicatifs
- Vérifier le privilège
PROCESSet adapter les commandes d'export en conséquence - Tester systématiquement le comptage de lignes des tables principales avant de couper l'ancienne base
RDS retire la charge de gestion système de MySQL, jamais la responsabilité du schéma applicatif ni du dimensionnement des ressources : la bascule change qui gère l'infrastructure, pas la nécessité de la surveiller.
Notre verdict
La migration vers RDS a effectivement libéré l'équipe technique de la maintenance système répétitive sur quarante instances MySQL distinctes, au prix d'une facture mensuelle plus élevée qu'un MySQL auto-hébergé équivalent. Pour une agence dont le temps d'administration coûtait plus cher que cet écart tarifaire, la bascule s'est avérée rentable dès les premiers mois.
