mysqldump --single-transaction --quick --lock-tables=false : cette ligne de commande résume à elle seule l’enjeu d’une migration de base de données en production. Sur un mutualisé qui commence à montrer ses limites en temps de requête, faire évoluer WordPress vers un service de base de données managée retire une charge importante du serveur web sans toucher aux fichiers du site, thème et extensions compris.
Le principe est simple sur le papier : exporter la base actuelle, l’importer sur le nouveau service, mettre à jour wp-config.php pour pointer vers la nouvelle adresse. En pratique, la difficulté tient dans la fenêtre pendant laquelle des écritures continuent d’arriver sur l’ancienne base pendant que l’export se termine.
Préparer l’export sans bloquer le site
Un export classique avec mysqldump pose verrou sur les tables pendant toute sa durée si l’option par défaut est laissée telle quelle, ce qui immobilise un site WordPress actif pendant plusieurs minutes sur une base de taille conséquente. L’option --single-transaction, disponible pour les tables InnoDB, évite ce verrou en s’appuyant sur une image cohérente de la base au moment du démarrage de l’export :
mysqldump --single-transaction --quick --lock-tables=false \
--user=wp_user --password \
--host=127.0.0.1 nom_de_la_base > export_avant_bascule.sql
Il faut vérifier au préalable que toutes les tables sont bien en InnoDB, avec SHOW TABLE STATUS : une table restée en MyISAM, souvent héritée d’une ancienne extension, ne bénéficie pas de la cohérence transactionnelle et peut introduire une incohérence mineure si elle est modifiée pendant l’export.
Créer et sécuriser l’instance managée
Un service de base de données managée impose ses propres règles réseau, généralement une liste blanche d’adresses IP autorisées à se connecter, à configurer avant même de tenter l’import. Sur ce type d’offre, l’adresse IP sortante du mutualisé doit être ajoutée à cette liste pour permettre l’import initial, puis remplacée par celle du serveur web définitif une fois la bascule terminée.
-- Création de l'utilisateur applicatif sur l'instance managée,
-- avec des droits limités à la base concernée uniquement.
CREATE USER 'wp_prod'@'%' IDENTIFIED BY 'un_mot_de_passe_genere';
GRANT ALL PRIVILEGES ON nom_de_la_base.* TO 'wp_prod'@'%';
FLUSH PRIVILEGES;
L’import se fait ensuite avec la commande symétrique à l’export, en pointant vers le nouvel hôte fourni par le service managé :
mysql --host=instance-scw.database.example.com --user=wp_prod --password \
nom_de_la_base < export_avant_bascule.sql
Le différentiel de dernière minute
Entre le moment de l’export initial et celui de la bascule effective, le site continue de recevoir des commentaires, des commandes ou de nouvelles publications si l’équipe éditoriale travaille en parallèle. Pour éviter de perdre ces écritures, la meilleure pratique consiste à mettre le site en mode maintenance quelques minutes seulement, le temps de réaliser un second export ciblé sur les tables les plus susceptibles d’avoir changé (wp_posts, wp_comments, wp_options), puis de l’appliquer sur l’instance managée juste avant de modifier wp-config.php.
Adapter wp-config.php
La bascule elle-même se limite à quatre constantes, sans toucher au reste de l’installation :
define( 'DB_NAME', 'nom_de_la_base' );
define( 'DB_USER', 'wp_prod' );
define( 'DB_PASSWORD', 'un_mot_de_passe_genere' );
define( 'DB_HOST', 'instance-scw.database.example.com' );
Un point souvent oublié : si le mutualisé imposait un port MySQL non standard ou un socket local, DB_HOST doit désormais inclure le port explicite si le service managé n’utilise pas le port 3306 par défaut, sous la forme hote:port.
Vérifier avant de couper l’ancienne base
Avant de considérer la migration terminée, une vérification systématique évite de découvrir un problème une semaine plus tard :
- Comparer le nombre de lignes de
wp_postsetwp_commentsentre l’ancienne et la nouvelle base. - Vérifier qu’aucune requête lente n’apparaît dans les journaux du service managé pendant les premières heures.
- Confirmer que les extensions qui écrivent directement en base via
$wpdb, sans passer par l’API WordPress, fonctionnent toujours normalement. - Conserver l’ancienne base en lecture seule pendant au moins une semaine avant suppression définitive.
Le vrai risque d’une migration de base de données n’est jamais l’export : c’est l’écriture arrivée entre l’export et la bascule, celle que personne ne pense à rejouer.
En résumé
Externaliser la base d’un WordPress vers un service managé comme celui proposé par Scaleway retire au mutualisé une charge de calcul significative, celle des requêtes SQL, sans exiger de toucher aux fichiers du site. La réussite de l’opération tient moins à la commande d’export ou d’import, techniquement simples, qu’à la discipline autour de la fenêtre de bascule et à la vérification systématique des écritures survenues entre les deux exports.
