Migrer une base de données depuis un autre serveur

Une migration de base de données n'échoue pas sur les commandes : elle échoue sur l'ordre des étapes. On bascule souvent le domaine d'abord, pour découvrir ensuite que la moitié des données n'a jamais été transférée. Voici une séquence qui évite cela.

Préparation

Sur la nouvelle machine, installez la même version du serveur de base de données, ou une version plus récente — PostgreSQL ou MySQL. Le retour à une version antérieure n'est pas pris en charge.

psql --version
mysql --version
df -h /

Prévoyez environ 2,5 fois la taille de la base en espace libre : le dump, les données décompressées et une marge de sécurité. Sur VDS-1, cela représente 40 Go au total, anticipez donc.

Créez un utilisateur et une base vide avec le même encodage que sur l'ancien serveur.

Transfert des données

La voie la plus simple est un dump via SSH, sans fichiers intermédiaires :

ssh root@OLD 'pg_dump -Fc -U shop shop' > /srv/shop.dump
pg_restore -U postgres -d shop --no-owner --role=shop /srv/shop.dump

Pour MySQL :

ssh root@OLD 'mysqldump --single-transaction --routines --events -u root shop' \
  | mysql -u root shop

Les rôles et les utilisateurs ne sont pas inclus dans un dump de base de données — exportez-les séparément : pg_dumpall --roles-only, ou créez-les manuellement — voir utilisateurs et droits.

La bande passante atteint 500 Mbps : une base de 20 Go migre en quelques minutes ; le goulot d'étranglement vient généralement de l'écriture disque, limitée selon le tier.

Vérification avant la bascule

Contrôlez les chiffres, pas seulement « le site s'est chargé » :

SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 20;

SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='shop';

Comparez le nombre de lignes des tables clés avec l'ancien serveur, vérifiez que les séquences n'ont pas été réinitialisées (SELECT last_value FROM users_id_seq;) et lancez l'application sur la nouvelle base en mode test.

Bascule

1. Activez le mode maintenance ou arrêtez l'application sur l'ancien serveur.
2. Effectuez un dernier dump des modifications apportées pendant la préparation.
3. Restaurez-le sur la nouvelle machine.
4. Changez la chaîne de connexion de l'application et redémarrez le service.
5. Laissez l'ancien serveur en marche une semaine de plus, sans supprimer les données.

Ne sautez pas l'étape cinq : découvrir une table manquante trois jours plus tard est monnaie courante.

Erreurs fréquentes

Avant de migrer, vérifiez que la nouvelle base n'écoute que sur 127.0.0.1. Inutile de l'exposer publiquement « le temps de la migration » — le transfert passe par SSH, voir accès distant.