Das Team „fügt Replikation für mehr Leistung hinzu“. Zwei Monate später: Master ausgelastet, Replikat inaktiv bei 4 % CPU, Budget verdoppelt. Ein anderes Szenario: „Automatisches“ Failover aktiviert – die Anwendung schreibt weiterhin auf die alte IP-Adresse des Masters fällt aus – zwanzig Minuten lang nicht verfügbar.
Die Replikation löst ein gut gestelltes Problem:
- Verfügbarkeit (den Tod des Meisters überleben)
- Leselasterhöhung (Lastabwurf von SELECT)
- Berichterstattung (analytisch, ohne die Produktion zu unterbrechen)
- Geografische Nähe (lokale Lesart – mit schwacher Konsistenz)
„Replikat, weil es professionell ist“ ohne Leserouting wählen = Kosten plus Komplexität ohne Gewinn.
Zielmatrix → Architektur
| Ziel | Modell | Falle |
|---|---|---|
| Hohe Verfügbarkeit | Primär + synchroner/halbsynchroner Standby + Patroni | Ungetestetes Split-Brain |
| Lesekompetenz steigern | Asynchrone Replikate + Lese-/Schreib-Proxy | UX Shift nach dem Schreiben |
| Live-Backup | Verzögerte Replik | Ersetzt kein getestetes Backup |
| Geografische Lektüre | Regionale Nachbildung | Konsistenzkonflikte |
Ein Replikat ist kein Backup – auch logische Beschädigungen werden repliziert.
Replikationsverzögerung und Webbenutzererfahrung
Nach der Anmeldung:
// POST-Master → Umleitung GET /profile
// GET auf Replikat → Benutzer noch nicht sichtbar, wenn die Verzögerung 2 Sekunden beträgt
Lösungen:
- Lesen Ihrer eigenen Schreibvorgänge: Sticky-Sitzung auf dem Master N Sekunden nach dem Schreiben.
- Proxy: ProxySQL, PgBouncer mit intelligentem Routing.
- CQRS: Mögliche Konsistenz auf der Schnittstellenseite akzeptieren.
MySQL vs. PostgreSQL: Ausnutzungsansicht
MySQL: asynchrones/halbsynchrones Binlog; Replikate lesen; MHA/Orchestrator-Umschaltung.
PostgreSQL: Streaming-Replikation; Hot-Standby beim Lesen; Patroni-Umstellung + etcd.
Verwaltete Datenbank (RDS, Cloud SQL, OVH DB): Multi-AZ ≠ Read Replica – lesen Sie die Produktdokumentation. Informationen zur Auswahl des Hostings finden Sie unter VPS oder Cloud und im Verzeichnis.
Wenn eine Replik auf demselben Host ausreicht – oder nicht
| Laden | Empfehlung |
|---|---|
| Blog, kleines SaaS | Einzelinstanz plus getestete Backups |
| Lesen >> dosiertes Schreiben | Ein oder zwei Read Replicas |
| SLA 99,9 %+ | Verwaltetes Hochverfügbarkeits- oder Patroni-Team |
| Schwere Analytik | Replikat für die Berichterstattung |
Eine Replik auf demselben physischen Server (einige Shared- oder Einstiegsangebote) ist eine Illusion von Hochverfügbarkeit: Hardwarefehler, Ausfall beider. Messen Sie vor dem Hinzufügen eines Replikats das Lese-/Schreibverhältnis mit pg_stat_statements oder Ihrem Anwendungsüberwachungstool – ein schlecht indizierter Master bleibt selbst mit drei ungenutzten Replikaten langsam.
Die Spitze: Replikation doppelter Daten – keine Verfügbarkeit ohne Tests
Folgendes wird auf der Folie „Hochverfügbarkeit“ nicht angezeigt.
Budget: vierteljährliche Umstellung > drittes ungenutztes Replikat.
Entscheide dich und gehe ohne blinden Fleck voran
Bevor Sie eine Replik hinzufügen, formulieren Sie das Ziel in einem Satz:
- Formulieren Sie das Ziel: hohe Verfügbarkeit, Lesen, Berichterstattung oder Geografie.
- Messen Sie das Lese-/Schreibverhältnis Ihrer Anwendungsrouten.
- Leiten Sie die SELECTs explizit weiter, wenn die Leselast zunimmt.
- Überwachen Sie die Verzögerung und Warnungen, die über den Geschäftsschwellenwert hinausgehen.
- Testen Sie den dokumentierten Failover mindestens vierteljährlich.
Ein Replikat ohne Leserouting oder Failover-Übung ist eine Budgetlinie, keine Versicherung. Kreuzen Sie mit EXPLAIN PostgreSQL, um den Master zu optimieren, bevor Sie ihn duplizieren.
Häufig gestellte Fragen
Beschleunigt eine Lesereplikat automatisch meine Website?
Nur wenn Sie SELECTs explizit an das Replikat weiterleiten und die Last größtenteils gelesen wird. Wenn alles über den Master läuft, bleibt das Replikat inaktiv und für die Leistung unbrauchbar.
Was ist Replikationsverzögerung?
Dies ist die Verzögerung zwischen dem Commit auf dem Master und der Sichtbarkeit auf dem Replikat. Eine Verzögerung von einigen Sekunden kann dazu führen, dass die gerade geschriebenen Daten eines Benutzers vorübergehend verschwinden.
Synchrone vs. asynchrone Replikation?
Synchron begrenzt den Datenverlust, erhöht jedoch die Schreiblatenz. Asynchron verbessert die Schreibleistung auf Kosten eines Verlustrisikos, wenn der Master vor der Weitergabe ausfällt.
Ist der Automatikschalter betriebsbereit?
Nein. Es erfordert einen Orchestrator, regelmäßige Tests und Split-Brain-Management. DNS oder virtuelle Adresse müssen zum neuen Master wechseln – ohne Konfiguration und Übung geht nichts automatisch.
Eine Replikation ohne Ziel bedeutet, dass für dieselbe Abfrage, die auf dem Master schlecht indiziert ist, doppelt bezahlt wird.