MySQL-Migration im TB-Bereich ohne Ausfallzeit

Das Problem

Ein Fintech-SaaS-Unternehmen betrieb eine 2TB MySQL-Datenbank auf veralteten Bare-Metal-Servern. Die Infrastruktur neigte sich dem Ende zu. Backups waren manuell und ungetestet. Es gab kein Failover — wenn der primäre Server ausfiel, fiel die gesamte Plattform aus. Die Migration musste bald stattfinden, aber die Kosten für Ausfallzeiten waren inakzeptabel.

Die Herausforderung

Dies war nicht einfach nur eine Datenmigration. Das Unternehmen verarbeitet jährlich Milliarden von Transaktionen. Jede Sekunde Ausfallzeit kostet Geld. Eine traditionelle Big-Bang-Migration war keine Option.

Die Lösung

Wir haben eine Migration ohne Ausfallzeit mit einem gestaffelten Ansatz entworfen und durchgeführt:

Phase 1: Replica-Setup

• Errichtete einen Percona XtraDB Cluster (PXC) auf Kubernetes mit 3 Knoten
• Richtete MySQL-Replikation vom alten Bare-Metal-Primary zum neuen PXC-Cluster ein
• Validierte Replikationsverzögerung (konsistent < 100ms)
• Führte Abfragen gegen das Replica aus, um Korrektheit zu überprüfen

Phase 2: Verbindungsrouting

• Bereitstellung von ProxySQL vor beiden Clustern
• Schrieb Routing-Regeln, um Lesezugriffe zum neuen Cluster zu senden
• Hielt Schreibzugriffe auf den alten Primary gerichtet, während die Replikation aufholte
• Überwachte Replikationsverzögerung kontinuierlich

Phase 3: Cutover

• Nachdem die Replikationsverzögerung 24 Stunden lang Null war, führten wir den Cutover aus
• Umgeleitete Schreibzugriffe vom alten Primary zum neuen PXC-Cluster (5-Sekunden-Wechsel)
• Hielt alten Primary als Read-Replica für sofortiges Rollback
• Überwachte 2 Stunden ohne Probleme, dann stillgelegte alte Hardware

Phase 4: Backups

• Konfigurierte automatisiertes XtraBackup auf S3 (täglich + inkrementell)
• Richtete Backup-Verifizierung ein (tägliche Restore-Tests auf isolierte Instanz)
• Dokumentierte Wiederherstellungsvorgänge

Technologien

• MySQL 8.0 (InnoDB)
• Percona XtraDB Cluster 8.0
• ProxySQL 2.x (Connection Pooling und Routing)
• XtraBackup (Backup-Automatisierung)
• Amazon S3 (Backup-Speicher)
• Kubernetes (PXC-Cluster-Management)

Ergebnisse

• Keine Ausfallzeit während Migrationscutover
• 2TB Datenbank erfolgreich migriert und funktionsfähig
• Automatisierte Backups werden täglich mit Validierung ausgeführt
• RTO < 5 Minuten für einen einzelnen Knoten-Fehler (Cluster erholt sich automatisch)
• RPO < 1 Stunde (tägliche Backups mit inkrementeller Wiederherstellung)
• Team-Vertrauen — die Datenbankplattform wird nun verstanden und ist bedienbar

Das Unternehmen konnte veraltete Bare-Metal-Hardware aus 20 Jahren ausmustern und zu einer Cloud-nativen Datenbankplattform wechseln — ohne jegliche Produktionsstörung.