# Migrer une base WordPress d’un mutualisé vers Scaleway Database

> Externaliser la base d'un WordPress vers un service de base de données managée réduit la charge du mutualisé, à condition de gérer finement la fenêtre de bascule.

- Auteur : WordPress Développement
- Publié le : 2024-02-22
- Mis à jour le : 2026-09-30
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/migrer-base-wordpress-mutualise-scaleway-database/

## L’essentiel

- mysqldump avec verrouillage minimal limite l'indisponibilité
- Le service managé impose ses propres règles de connexion et d'IP autorisées
- wp-config.php change, pas le reste du site

`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

> L'essentiel à retenir : mysqldump avec verrouillage minimal limite l'indisponibilité ; Le service managé impose ses propres règles de connexion et d'IP autorisées ; wp-config.php change, pas le reste du site

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 :

1. Comparer le nombre de lignes de `wp_posts` et `wp_comments` entre l'ancienne et la nouvelle base.
2. Vérifier qu'aucune requête lente n'apparaît dans les journaux du service managé pendant les premières heures.
3. Confirmer que les extensions qui écrivent directement en base via `$wpdb`, sans passer par l'API WordPress, fonctionnent toujours normalement.
4. 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.