Ausgangslage
Eine der führenden Online-Marktplatz-Plattformen des Landes — mit über 5 Millionen monatlichen Besuchern und Hunderttausenden aktiver Listings — betrieb ihre Kerndatenbank auf SQL Server 2016 Standard Edition. Das System war der Single Point of Failure für die gesamte Plattform.
Die Risiken waren real:
- Kein Hochverfügbarkeits-Setup: Ein einzelner Datenbankserver ohne Failover. Jeder Hardwarefehler bedeutete vollständigen Plattformausfall
- Wartungsfenster: Monatliche Patches erforderten 2-4 Stunden geplante Downtime — immer nachts, immer mit Risiko
- Performance-Grenzen: SQL Server 2016 Standard Edition war auf 128 GB RAM und 24 CPU-Kerne limitiert — die Plattform näherte sich diesen Grenzen
- Wachsende Datenmenge: 2,8 TB Datenbankgröße mit 15 % jährlichem Wachstum
- Kein Read-Scale-Out: Alle Lese- und Schreiboperationen liefen über denselben Server — Report-Queries konkurrierten mit Transaktionen
Herausforderung
Das Upgrade musste mehrere Ziele gleichzeitig erreichen:
- Zero Downtime: Die Plattform darf während der Migration nicht offline gehen — nicht eine Minute
- Hochverfügbarkeit: Automatisches Failover bei Hardwareausfällen in unter 30 Sekunden
- Read Scale-Out: Report-Queries auf Secondary Replicas umleiten, um den Primary zu entlasten
- Wartung ohne Downtime: Patches und Updates rolling, ohne Plattformunterbrechung
- Datenkonsistenz: Synchrone Replikation für die primäre Replica, asynchron für Disaster Recovery
Lösung
Zielarchitektur
Wir implementierten ein SQL Server 2019 Always On Availability Group Setup mit drei Knoten:
| Knoten | Rolle | Standort | Replikationsmodus |
|---|---|---|---|
| Node 1 | Primary | Rechenzentrum A | — |
| Node 2 | Secondary (Sync) | Rechenzentrum A | Synchron |
| Node 3 | Secondary (Async) | Rechenzentrum B | Asynchron |
- Node 1 + 2: Synchrone Replikation im selben Rechenzentrum — automatisches Failover in unter 30 Sekunden
- Node 3: Asynchrone Replikation in ein zweites Rechenzentrum — Disaster Recovery mit RPO von wenigen Sekunden
- Read-Only Routing: Report-Queries werden automatisch auf Node 2 oder 3 umgeleitet
Migrationsplan
Die Migration von SQL Server 2016 auf 2019 mit gleichzeitiger Einführung von Always On erfolgte in 5 Phasen:
Phase 1: Infrastruktur (2 Wochen)
- 3 neue Server provisioniert und gehärtet
- Windows Server Failover Cluster (WSFC) konfiguriert
- Netzwerk: dedizierte VLANs für Replikationstraffic
Phase 2: Side-by-Side Installation (1 Woche)
- SQL Server 2019 Enterprise auf allen 3 Knoten installiert
- Compatibility Level initial auf 130 (SQL 2016) belassen — für Rollback-Sicherheit
Phase 3: Datenmigration (1 Woche)
- Vollständiges Backup der Produktionsdatenbank (2,8 TB)
- Restore auf Node 1 (SQL Server 2019)
- Log Shipping vom alten Server zum neuen — kontinuierliche Synchronisation
- Validierung: Checksummen-Vergleich aller Tabellen
Phase 4: Cutover (4 Stunden, Zero Downtime)
- Log Shipping bis zum letzten Transaction Log angewendet
- Application Connection String auf den neuen Listener umgestellt
- Always On Availability Group aktiviert
- DNS-Umschaltung auf den neuen Listener (TTL vorher auf 60 Sekunden reduziert)
- Der alte Server blieb 72 Stunden als Rollback-Option bereit
Phase 5: Optimierung (2 Wochen)
- Compatibility Level auf 150 (SQL Server 2019) angehoben
- Query Store aktiviert für Performance-Monitoring
- Read-Only Routing konfiguriert und getestet
- Alte Server dekommissioniert
Ergebnisse
| Metrik | Vorher (SQL 2016 Standard) | Nachher (SQL 2019 Always On) |
|---|---|---|
| Verfügbarkeit | 99,7 % (inkl. geplanter Downtime) | 99,99 % |
| Failover-Zeit | Manuell (30-60 Min.) | Automatisch (unter 30 Sek.) |
| Geplante Downtime | 2-4 Std./Monat | 0 (Rolling Updates) |
| Report-Query-Performance | Baseline | +40 % (Read Replica) |
| Ungeplante Ausfälle (12 Monate) | 3 | 0 |
| Maximale RAM-Nutzung | 128 GB (Limit) | 256 GB (Enterprise) |
| Disaster Recovery RPO | Letztes Backup (bis zu 24 Std.) | Wenige Sekunden (Async Replica) |
Lessons Learned
1. Compatibility Level schrittweise anheben
Wir haben den Compatibility Level erst 2 Wochen nach dem Cutover von 130 auf 150 angehoben — und dabei den Query Store genutzt, um Regressionen zu identifizieren. 3 Queries zeigten schlechtere Pläne und wurden manuell optimiert. Ohne diese Vorsicht hätten wir Performance-Probleme im Produktivbetrieb entdeckt.
2. Log Shipping als Migrations-Werkzeug
Log Shipping ist nicht nur für Disaster Recovery — es ist das beste Werkzeug für Zero-Downtime-Migrationen. Der neue Server ist jederzeit synchron, und der Cutover reduziert sich auf eine DNS-Änderung.
3. Read-Only Routing ist Gold wert
Die Umleitung von Report-Queries auf die Secondary Replica hat die Performance des Primary um 40 % verbessert — ein Nebeneffekt, der wichtiger wurde als das ursprüngliche Migrationsziel.