Eine 50-GB-WooCommerce-Site ohne Downtime migrieren — das Runbook, das wir verwenden

Eine kürzliche WooCommerce-Migration: 50 GB Daten, 480.000 Produkte, 14 Jahre Bestellhistorie, von einem ächzenden Single-Server-VPS auf ein ordentlich architektonisches Setup verschoben. Gesamte kundenseitige Downtime: 38 Sekunden. Der Trick ist nicht Geschwindigkeit — es ist, die MySQL-Replikation zum neuen Host einzurichten, während der alte Host noch Bestellungen entgegennimmt, sodass der Cutover nur die letzten Sekunden an Writes nachholt.

Das Cutover-Skript — der 38-Sekunden-Teil

ssh source "wp maintenance-mode activate"
sleep 60                                          # in-flight Checkouts auslaufen lassen
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"

Der rsync ist schnell, weil die Bulk-Kopie eine Woche lang nächtlich gelaufen ist. Die DB ist schnell, weil die Replikation die ganze Zeit aufgeholt hat.

Der vollständige Beitrag behandelt:

• Warum mysqldump-and-import bei Sites dieser Größe falsch ist
• Cross-Host-MySQL-Replikation für die Bulk-Copy-Phase einrichten
• Zeichensatz- und Collation-Fallen (Emojis in Produktnamen beißen Sie)
• Der Dry-Run-Cutover gegen Staging — was vor dem echten zu testen ist
• Payment-Gateway-Webhook-Handling während des Cutovers
• Das 72-Stunden-Reverse-Replication-Sicherheitsnetz für Hot Rollback

Wir haben dieses Playbook bei jeder bedeutenden WooCommerce-Migration der letzten zwei Jahre angewendet. Melden Sie sich, wenn Sie eine vor sich haben.