Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Ein PostgreSQL-Standby allein ist kein vollständiges HA-Design. Replication Mode, WAL-Retention, Failover, Client-Routing, Split-Brain-Schutz und Backup/Recovery gehören zusammen. Synchrone Replikation reduziert Datenverlust-Risiko, kann aber Commit-Latenz erhöhen.
PostgreSQL kann Commits von einem oder mehreren Standbys bestätigen lassen. Das erhöht Durability, kann aber Netzwerk-/Standby-Latenz zum Commit addieren. Asynchrone Replication ist schneller, kann bei Failover letzte WAL-Änderungen verlieren.
Apps können über Virtual Endpoint, HAProxy oder failover-aware Service statt fester Primary-IP verbinden. Standby folgt WAL und kann bei Bedarf promoted werden.
Latenztoleranz und Datenverlust-Toleranz gemeinsam bewerten.
Promotion, DNS/LB-Routing, Fencing, Client-Reconnect und Replication-Slot-Status testen.
Befehle mit passend privilegiertem PostgreSQL-User ausführen.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
psql -c "SELECT pg_is_in_recovery();"psql -c "SELECT application_name,state,sync_state,write_lag,flush_lag,replay_lag FROM pg_stat_replication;"psql -c "SELECT pg_current_wal_lsn();"pg_isreadyFehlerhafte DELETEs, Schemafehler oder Korruption können repliziert werden. Für PITR braucht man unabhängige Recovery wie Base Backup plus WAL Archive.
Keine pauschale Zahl. Primary + Standby können zwei Daten-Nodes sein; automatisches Quorum/Failover kann zusätzliche Nodes/Witness erfordern.
Sie erhöht Commit-Durability, aber Gesamtsystem-Fehler, Storage und Client-Verhalten müssen zusätzlich bewertet werden.
Normalerweise read-only, bis sie zum Primary promoted wird.
Teilen Sie DB-Größe, Write Rate, akzeptablen Datenverlust und RTO; Async/Sync Standby und Endpoint planen.