Migrer un site WooCommerce de 50 Go sans interruption — le runbook que nous suivons

Migration WooCommerce récente : 50 Go de données, 480 000 produits, 14 ans d'historique de commandes, déplacés d'un VPS mono-serveur grinçant vers une architecture correctement conçue. Indisponibilité totale visible par le client : 38 secondes. L'astuce n'est pas la vitesse — c'est mettre en place la réplication MySQL vers le nouvel hôte pendant que l'ancien hôte prend toujours des commandes, afin que le cutover ne rejoue que les dernières secondes d'écritures.

Le script de cutover — la partie 38 secondes

ssh source "wp maintenance-mode activate"
sleep 60                                          # drainer les checkouts en cours
ssh dest "mysql -e 'STOP SLAVE; RESET SLAVE ALL;'"
rsync -avz --delete source:uploads/ dest:uploads/
ssh dest "wp search-replace 'old-domain.com' 'new-domain.com' --all-tables --skip-columns=guid"
curl -X PATCH ".../dns_records/$ID" -d '{"content":"<new-ip>"}'
ssh dest "wp maintenance-mode deactivate"

Le rsync est rapide parce que la copie en masse tourne chaque nuit depuis une semaine. La DB est rapide parce que la réplication a rattrapé tout du long.

L'article complet couvre :

• Pourquoi mysqldump-and-import est faux pour les sites de cette taille
• Mettre en place la réplication MySQL cross-host pour la phase de copie en masse
• Les pièges de jeu de caractères et de collation (les emojis dans les noms de produits vous mordront)
• Le dry-run du cutover contre le staging — ce qu'il faut tester avant le vrai
• La gestion des webhooks de passerelle de paiement pendant le cutover
• Le filet de sécurité de réplication inverse de 72 heures pour le hot rollback

Nous avons exécuté ce playbook sur chaque migration WooCommerce significative au cours des deux dernières années. Contactez-nous si vous en avez une en perspective.