settings
OTEX_BIG
Süddeutsche Zeitung Institut Auszeichnung
 Image
Alle PostgreSQL Schulungen

Schulung PostgreSQL Hochverfügbarkeit und Replikation

Streaming Replication, Logical Replication, Patroni und Connection Pooling

3 Tage / S6878
Neues Seminar
Per E-Mail senden

Schulungsformen

Offene Schulung


  • Dritter Mitarbeitende kostenfrei
  • Learning & Networking in einem. Garantierte Durchführung ab 1 Teilnehmenden.
Präsenz Online

Inhouse-/Firmenschulung

  • 3 Tage - anpassbar
  • Termin nach Wunsch
  • In Ihrem Hause oder bei der GFU
  • Preis nach Angebot

  • Lernumgebung in der Cloud
  • Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid

Individualschulung

  • 3 Tage - anpassbar
  • Termin nach Wunsch
  • In Ihrem Hause oder bei der GFU
  • Preis nach Angebot

  • Lernumgebung in der Cloud
  • 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid

Beschreibung

PostgreSQL hat kein eingebautes Clustering - im Gegensatz zu SQL Server (AlwaysOn), Oracle (RAC) oder MySQL (Galera). Das ist gleichzeitig seine größte Schwäche und seine größte Stärke: Schwäche, weil HA nicht „out of the box" funktioniert. Stärke, weil die Tools, die das PostgreSQL-Ökosystem dafür bietet (Patroni, repmgr, PgBouncer, PgPool-II), flexibler und transparenter sind als proprietäre Black-Box-Lösungen.
In der Praxis bedeutet das: Wer PostgreSQL in Produktion betreibt, muss HA selbst bauen - Streaming Replication für Datenreplikation, Patroni für automatischen Failover, PgBouncer für Connection Pooling und Load Balancing, Monitoring für Replikations-Lag und Split-Brain-Erkennung. Dieses dreitägige Seminar zeigt den gesamten Weg - von der ersten Standby-Replik bis zum automatisierten 3-Knoten-Cluster mit Failover in unter 30 Sekunden.


Bei Interesse an einer weiteren PostgreSQL Weiterbildung, werfen Sie einen Blick auf unser gesamtes Portfolio.

Schulungsziel

Jede teilnehmende Person verlässt das Seminar mit einem funktionierenden 3-Knoten-HA-Cluster (Patroni + Streaming Replication + PgBouncer + HAProxy), der Fähigkeit, automatischen Failover zu konfigurieren und zu testen , dem Verständnis von Streaming und Logical Replication (Unterschiede, Anwendungsfälle, Einschränkungen), einem Monitoring-Setup (Prometheus + Grafana), einem Failover-Runbook und einer HA-Architektur für die eigene Umgebung.

Details

Inhalt

Tag 1: Replikationsgrundlagen und Streaming Replication
1. PostgreSQL HA im Überblick: Konzepte und Architekturentscheidungen
  • Ziele und Erwartungen der Teilnehmenden
    • Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
  • Warum HA? RPO (Recovery Point Objective) und RTO (Recovery Time Objective) als Planungsgrundlage. Typische Anforderungen: RPO=0 (kein Datenverlust), RTO < 30 Sekunden (automatischer Failover).
  • HA-Bausteine in PostgreSQL: Replikation (Daten auf Standby kopieren), Failover-Orchestrierung (Standby zum Primary promoten), Connection Routing (Applikation auf neuen Primary umleiten), Connection Pooling (Verbindungen effizient verwalten), Monitoring (Lag, Zustand, Split-Brain erkennen).
  • Topologien: Primary + 1 Standby (einfachste HA), Primary + 2 Standbys (Quorum-fähig, Read-Scale), Cascading Replication (Standby repliziert von Standby - reduziert Last auf Primary), Multi-Datacenter (synchron lokal, asynchron remote).
  • Streaming vs. Logical Replication: Streaming = physische Kopie (WAL-basiert, gesamte Instanz), Logical = logische Kopie (tabellenbasiert, selektiv, Cross-Version). Wann welche?
  • Praxis-Übung: 3-Knoten-Umgebung vorbereiten (3 VMs oder Docker-Container mit PostgreSQL). Netzwerk, DNS und Basisinstallation prüfen.
2. Streaming Replication: Physische Replikation konfigurieren
  • WAL-basierte Replikation: Primary schreibt WAL (Write-Ahead Log), Standby empfängt und replayed WAL-Segmente. Asynchron (Standard: Standby kann kurzzeitig hinter dem Primary sein) vs. Synchron (Primary wartet auf Bestätigung des Standby - RPO=0, aber höhere Latenz).
  • Konfiguration Schritt für Schritt: postgresql.conf (wal_level=replica, max_wal_senders, wal_keep_size), pg_hba.conf (Replication-Zugang), Replication Slot (verhindert WAL-Löschung bevor Standby empfangen hat), pg_basebackup (initiale Kopie des Primary auf den Standby).
  • Hot Standby: Standby akzeptiert Read-Only-Queries - für Reporting, Analytics, Backups. Konfiguration: hot_standby = on. Conflict Handling: was passiert, wenn eine Query auf dem Standby einen Lock braucht, den der Replay-Prozess hält?
  • Synchrone Replikation: synchronous_commit, synchronous_standby_names. Trade-off: Datensicherheit (RPO=0) vs. Performance (Primary wartet). Quorum-basierte synchrone Replikation: ANY 1 (standby1, standby2) - mindestens einer muss bestätigen.
  • WAL Archiving und Restore: Ergänzung zur Streaming Replication - WAL-Segmente zusätzlich auf Dateisystem oder Object Storage archivieren. archive_command, restore_command. Für Point-in-Time Recovery (PITR) und als Fallback wenn Streaming unterbrochen wird.
  • Praxis-Übung: Streaming Replication aufsetzen: Primary konfigurieren, pg_basebackup auf Standby, Hot Standby starten, Read-Only-Query auf Standby ausführen. Replication Lag messen (pg_stat_replication). Auf synchrone Replikation umschalten und Latenz-Auswirkung messen.
3. Manueller Failover und Switchover
  • Geplanter Switchover (Wartung): Primary herunterfahren, Standby promoten (pg_ctl promote oder pg_promote()), Applikation umleiten, ehemaligen Primary als neuen Standby einrichten (pg_rewind für schnelles Resync).
  • Ungeplanter Failover (Ausfall): Primary ist nicht erreichbar. Standby promoten. Risiko: Split-Brain (alter Primary kommt zurück und glaubt, noch Primary zu sein). Timeline-Divergenz erkennen und auflösen.
  • pg_rewind: Schnelles Resync eines ehemaligen Primary als Standby - statt vollem pg_basebackup nur die divergierten WAL-Segmente zurücksetzen. Voraussetzung: wal_log_hints = on oder Data Checksums.
  • Warum manueller Failover nicht reicht: Reaktionszeit (DBA muss verfügbar sein, Nachts/Wochenende), Fehleranfälligkeit (falsche Reihenfolge, vergessene Schritte), Split-Brain-Risiko. -> Automatisierung mit Patroni (Tag 2).
  • Praxis-Übung: Geplanter Switchover: Primary -> Standby promoten -> ehemaligen Primary mit pg_rewind als Standby einrichten. Ungeplanter Failover simulieren: Primary-Prozess killen -> Standby manuell promoten -> Replikationsstatus prüfen.
Tag 2: Patroni, automatischer Failover und Connection Pooling
4. Patroni: HA-Orchestrierung mit automatischem Failover
  • Patroni im Überblick: Open-Source-HA-Lösung von Zalando, de-facto-Standard für PostgreSQL-HA. Patroni verwaltet den Cluster-Zustand in einem Distributed Configuration Store (DCS: etcd, Consul oder ZooKeeper), überwacht Primary und Standbys, führt automatisches Failover durch, verhindert Split-Brain.
  • Architektur: Patroni-Agent auf jedem PostgreSQL-Knoten, DCS (etcd-Cluster mit 3+ Knoten für Quorum), Patroni REST API für Status und Steuerung. Leader Election über DCS-Lock: wer den Lock hält, ist Primary.
  • Konfiguration: patroni.yml - Cluster-Name, DCS-Verbindung, PostgreSQL-Parameter, Replication-Konfiguration, Failover-Bedingungen (TTL, Loop Wait, Retry Timeout), Tags (nofailover, noloadbalance, clonefrom).
  • Automatischer Failover: Primary fällt aus -> Patroni erkennt Ausfall (TTL abgelaufen) -> Leader Election -> bester Standby wird zum Primary promotet -> übrige Standbys folgen dem neuen Primary -> Gesamtdauer: 10-30 Sekunden.
  • Patroni-Befehle: patronictl list (Cluster-Status), patronictl switchover (geplanter Wechsel), patronictl failover (erzwungener Wechsel), patronictl restart (Rolling Restart), patronictl edit-config (Cluster-Konfiguration ändern).
  • Split-Brain-Vermeidung: DCS als Single Source of Truth. Fencing: alter Primary wird per pg_ctl stop oder kill gestoppt, bevor neuer Primary startet. Watchdog (Linux Kernel Watchdog) als zusätzliche Absicherung.
  • Praxis-Übung: Patroni-Cluster aufsetzen: etcd installieren (3-Knoten-Cluster oder Single-Node für Demo), Patroni auf allen 3 PostgreSQL-Knoten konfigurieren und starten, patronictl list -> Cluster-Status prüfen. Automatischen Failover testen: Primary-Container stoppen -> beobachten: Patroni promotet Standby -> Applikation prüfen. Geplanten Switchover mit patronictl switchover durchführen.
5. Connection Pooling und Routing: PgBouncer und PgPool-II
  • Warum Connection Pooling? PostgreSQL erzeugt pro Verbindung einen eigenen Prozess (fork) - bei 500+ Verbindungen: hoher RAM-Verbrauch, Context-Switch-Overhead. Connection Pooler halten einen Pool persistenter Verbindungen und multiplexen Client-Verbindungen darauf.
  • PgBouncer: Leichtgewichtiger Connection Pooler (Single-Binary, minimaler RAM). Modi: Session Pooling (1:1 Zuordnung, sicherste Kompatibilität), Transaction Pooling (Verbindung wird nach jeder Transaktion freigegeben - höchste Effizienz, aber: keine Session-Features wie Prepared Statements über Transaktionsgrenzen), Statement Pooling (selten genutzt). Konfiguration: pgbouncer.ini (Pool-Größe, Auth, Timeouts).
  • PgPool-II: Mehr als Pooling - Connection Pooling + Load Balancing (Read-Queries auf Standbys verteilen) + Automatischer Failover (ohne Patroni) + Query Caching. Komplexer als PgBouncer, aber mehr Features. Wann PgBouncer, wann PgPool-II?
  • Routing bei Failover: Applikation muss den neuen Primary finden. Optionen: DNS-Update (Patroni Callback -> DNS-Record ändern), Virtual IP (Patroni Callback -> VIP verschieben), HAProxy/PgBouncer vor Patroni (HAProxy prüft Patroni REST API -> routet zu aktuellem Primary), Applikations-seitig (libpq target_session_attrs=read-write, Multi-Host-Connection-String).
  • HAProxy + Patroni: HAProxy als Load Balancer vor dem Cluster. Health Check gegen Patroni REST API (/primary, /replica). Write-Traffic -> Primary, Read-Traffic -> Replicas. Konfiguration und Failover-Verhalten.
  • Praxis-Übung: PgBouncer vor dem Patroni-Cluster konfigurieren (Transaction Pooling, Pool-Größe 50). HAProxy mit Patroni-Health-Checks konfigurieren: Write-Backend (Primary) + Read-Backend (Replicas). Failover-Test: Primary stoppen -> HAProxy routet automatisch auf neuen Primary -> Applikation merkt nichts (Verbindung über HAProxy bleibt stabil).
6. Logical Replication: Selektive und Cross-Version-Replikation
  • Logical vs. Streaming: Streaming = physische Byte-Kopie (gesamte Instanz, gleiche Major Version). Logical = logische Änderungen (INSERT/UPDATE/DELETE auf Tabellenebene, verschiedene Major Versions möglich, selektive Replikation einzelner Tabellen).
  • Anwendungsfälle: Cross-Version-Upgrades (PG 14 -> PG 17 mit Logical Replication und Zero Downtime), selektive Replikation (nur bestimmte Tabellen an Data Warehouse replizieren), Multi-Master-Szenarien (mit Conflict Resolution - z.B. BDR/pgEdge), Daten-Integration (PostgreSQL -> andere Systeme via Logical Decoding + Kafka/Debezium).
  • Konfiguration: wal_level=logical, Publication (auf Primary: CREATE PUBLICATION), Subscription (auf Subscriber: CREATE SUBSCRIPTION). Initial Data Sync, Slot Management, Monitoring (pg_stat_subscription, pg_stat_replication_slots).
  • Einschränkungen: DDL wird nicht repliziert (Schema-Änderungen manuell synchronisieren), Sequences werden nicht repliziert, Large Objects nicht unterstützt, Truncate erst ab PG 11.
  • Logical Decoding und Change Data Capture: pgoutput (Standard), wal2json, test_decoding. Integration mit Debezium für CDC -> Kafka -> Data Lake / Data Warehouse.
  • Praxis-Übung: Logical Replication einrichten: Publication auf Primary (3 Tabellen), Subscription auf separatem PostgreSQL-Server (andere Major Version). Daten einfügen -> Replikation prüfen. DDL-Änderung auf Primary -> beobachten, dass Subscriber nicht folgt -> manuell nachziehen.
Tag 3: Monitoring, Troubleshooting und Praxis
7. Replikations-Monitoring und Troubleshooting
  • Monitoring-Views: pg_stat_replication (Replikationsstatus, Lag in Bytes und Zeit, Sync State), pg_stat_wal_receiver (auf Standby: Empfangsstatus), pg_stat_replication_slots (Slot-Nutzung, Disk-Verbrauch), pg_stat_activity (aktive Connections, Wartezustände).
  • Replikations-Lag messen und alarmieren: Lag in Bytes (sent_lsn - replay_lsn), Lag in Zeit (replay_lag). Alerting: Lag > 1 MB oder > 10 Sekunden -> Warnung. Lag > 100 MB oder > 60 Sekunden -> Alarm.
  • Typische Probleme und Lösungen: Replication Slot wächst unbegrenzt (Standby offline -> WAL staut sich -> Disk voll -> pg_drop_replication_slot), Standby hängt (WAL Replay Conflict -> max_standby_streaming_delay anpassen), Network Partition (Standby verliert Verbindung -> automatisches Reconnect, ggf. pg_basebackup nötig), Timeline-Divergenz nach Failover (-> pg_rewind).
  • Monitoring-Stack: Prometheus + postgres_exporter + Grafana als Standard. Patroni-Metriken über REST API exportieren. pgwatch2 als PostgreSQL-spezifische Alternative. Vorgefertigte Grafana-Dashboards für PostgreSQL-Replikation.
  • Praxis-Übung: Prometheus + postgres_exporter auf dem Cluster einrichten. Grafana-Dashboard für Replikations-Monitoring importieren. Lag-Szenario provozieren (Standby belasten -> Replay verzögert sich -> Lag steigt -> Alert feuert). Replication Slot Bloat simulieren und beheben.
8. Fortgeschrittene HA-Szenarien
  • Multi-Datacenter-HA: Synchrone Replikation innerhalb eines Standorts (RPO=0), asynchrone Replikation zum Remote-Standort (RPO > 0, aber DR-fähig). Patroni mit DCS über Standorte hinweg (etcd Multi-Site oder Consul Federation).
  • Delayed Standby: Standby mit absichtlicher Verzögerung (z.B. 1 Stunde) - als Schutz gegen logische Fehler (versehentliches DROP TABLE: auf normalem Standby sofort repliziert, auf Delayed Standby noch 1 Stunde Zeit zum Recover). recovery_min_apply_delay.
  • Read-Scaling: Multiple Standbys für Read-Heavy-Workloads. HAProxy mit Weighted Round-Robin auf Replicas. Applikations-seitig: Connection-String mit target_session_attrs=prefer-standby.
  • Backup-Integration: Barman und WAL-G als Enterprise-Backup-Tools, die sich nahtlos in HA-Cluster integrieren. Backup vom Standby (nicht vom Primary) - reduziert Last. PITR (Point-in-Time Recovery) als Ergänzung zu Replikation.
  • Vergleich mit Managed Services: Amazon RDS/Aurora PostgreSQL, Azure Database for PostgreSQL Flexible Server, Google Cloud SQL - eingebaute HA vs. Self-Managed. Wann Self-Managed (Kontrolle, Compliance, On-Premises), wann Managed (weniger Aufwand, schnellerer Start)?
  • Praxis-Übung: Delayed Standby konfigurieren (30 Min Verzögerung). Szenario: versehentliches DELETE auf Primary -> Daten vom Delayed Standby retten, bevor der Replay den DELETE erreicht.
9. Praxis-Workshop: „Unser PostgreSQL-HA-Cluster"
Phase 1 - Architektur-Entwurf (15 Min):
  • Eigene Anforderungen beschreiben: RPO/RTO, Standort-Verteilung, Read-Scaling-Bedarf, Compliance.
  • HA-Topologie wählen und begründen: 2-Knoten vs. 3-Knoten, synchron vs. asynchron, Multi-Datacenter, Delayed Standby.
  • Toolstack festlegen: Patroni + etcd + PgBouncer + HAProxy (Standard) oder Alternativen.
Phase 2 - Betriebsplan (20 Min):
  • Failover-Runbook erstellen: Automatischer Failover (Patroni), manueller Switchover (Wartung), Desaster-Recovery (Standort-Ausfall).
  • Monitoring-Setup definieren: Welche Metriken, welche Schwellwerte, welche Alerting-Kanäle?
  • Backup-Strategie mit HA verbinden: Backup vom Standby, WAL-Archivierung, PITR-Ziel.
Phase 3 - Peer-Review und Stresstest (10 Min):
  • HA-Architektur vorstellen. Stresstest: „Primary und ein Standby fallen gleichzeitig aus - was passiert?" „Der DCS (etcd) verliert das Quorum - was passiert mit dem Cluster?" „Replication Lag steigt auf 10 Minuten - was tust du?"

  • PostgreSQL-Administratoren: Die produktive Datenbanken ausfallsicher betreiben und Failover-Szenarien beherrschen.
  • Platform Engineers und DevOps: Die PostgreSQL-HA-Cluster aufbauen, automatisieren und überwachen.
  • IT-Architekten: Die HA-Strategien für PostgreSQL bewerten und die richtige Topologie für ihre Anforderungen wählen.
  • DBAs mit Oracle- oder SQL-Server-Hintergrund: Die PostgreSQL-HA-Konzepte (kein eingebautes Clustering) verstehen und die passenden Tools kennenlernen.
Voraussetzungen: Solide PostgreSQL-Administrationskenntnisse (Installation, Konfiguration, Backup/Restore, Benutzerverwaltung). Idealerweise Besuch von „PostgreSQL Administration" (S611, 3T) oder „PostgreSQL DBA Fortgeschrittene" (S2146, 5T). Linux-Grundkenntnisse (Shell, systemd, Netzwerk). Grundverständnis von Netzwerk-Topologien und DNS.


In Präsenz

Online
Lernmethode

Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC.

Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent.

Unterlagen

Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne.

Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne.

Arbeitsmaterialien

DIN A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its

Teilnahmezertifikat

Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF.


In Präsenz

Online
Teilnehmendenzahl

min. 1, max. 8 Personen

Garantierte Durchführung

Ab 1 Teilnehmenden*

Schulungszeiten
3 Tage, 09:00 - 16:00 Uhr
Ort der Schulung
GFU Schulungszentrum oder Virtual Classroom
GFU Schulungszentrum
Am Grauen Stein 27
51105 Köln-Deutz

oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung

Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden.

Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen.

Räumlichkeiten

Helle und modern ausgestattete Räume mit perfekter Infrastruktur

Bequem aus dem Homeoffice von überall

Preisvorteil

Dritter Mitarbeitende nimmt kostenfrei teil.
(Nicht mit anderen Rabatten kombinierbar.)

Eventuell anfallende Prüfungskosten für den dritten Teilnehmenden werden zusätzlich berechnet.

Hinweis: Um den Erfolg der Schulung zu gewährleisten, sollte auch der dritte Teilnehmende die erwarteten Vorkenntnisse mitbringen.

KOMPASS — Förderung für Solo-Selbstständige

Solo-Selbstständige können für dieses Seminar eine Förderung via KOMPASS beantragen.

Ausführliche Informationen dazu finden Sie hier.

All-Inclusive

Gebäck, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch

Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu.

Barrierefreiheit

Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei

-
Rechnungsstellung

Erst nach dem erfolgreichen Seminar. Keine Vorkasse.

Stornierung

Kostenfrei bis zum Vortag des Seminars

Vormerken statt buchen

Sichern Sie sich unverbindlich Ihren Seminarplatz schon vor der Buchung - auch wenn Sie selbst nicht berechtigt sind zu buchen


In Präsenz

Online
  • Eigener Shuttle-Service
  • Reservierte Parkplätze
  • Hotelreservierung
  • Technik-Sofort-Support

Buchungsmöglichkeiten

Online oder in Präsenz teilnehmen

Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.

Weiterbildung PostgreSQL Hochverfügbarkeit und Replikation

TerminOrtPreis
03.08.-05.08.2026
Plätze vorhanden
Köln / Online 2.030,00
Köln / Online 2.030,00 Buchen Vormerken
12.10.-14.10.2026
Plätze vorhanden
Köln / Online 2.030,00
Köln / Online 2.030,00 Buchen Vormerken
14.12.-16.12.2026
Plätze vorhanden
Köln / Online 2.030,00
Köln / Online 2.030,00 Buchen Vormerken
2027
19.04.-21.04.2027
Plätze vorhanden
Köln / Online 2.030,00
Köln / Online 2.030,00 Buchen Vormerken
21.06.-23.06.2027
Plätze vorhanden
Köln / Online 2.030,00
Köln / Online 2.030,00 Buchen Vormerken
  • Buchen ohne Risiko
  • Keine Vorkasse
  • Kostenfreies Storno bis zum Vortag des Seminars
  • Rechnung nach erfolgreichem Seminar
  • All-Inclusive-Preis
  • Garantierter Termin und Veranstaltungsort
  • Preise pro Person zzgl. Mehrwertsteuer
  • Dritter Mitarbeitende kostenfrei (Nicht mit anderen Rabatten kombinierbar.)
Inhouse-/Firmenschulung
  • Lernumgebung in der Cloud
  • Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
  • Lernumgebung in der Cloud
  • 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Nachbetreuung

Unterstützung nach der Schulung durch
individuelle Nachbetreuung

Details & Anfrage

So haben GFU-Kunden gestimmt

Zu diesem Seminar wurden noch keine Bewertungen abgegeben.

FAQ für Offene Schulungen
  • Alle folgenden Schulungsformen können auch Online als Virtual Classroom durchgeführt werden.
  • Eine Offene Schulung findet zu einem festgelegten Zeitpunkt im voll ausgestatteten Schulungszentrum oder Online/Remote statt. Sie treffen auf Teilnehmende anderer Unternehmen und profitieren vom direkten Wissensaustausch.
  • Eine Inhouse-/Firmen-Schulung geht auf die individuellen Bedürfnisse Ihres Unternehmens ein. Sie erhalten eine kostenfreie Beratung von Ihrem Seminarleiter und können Inhalte und Dauer auf Ihren Schulungsbedarf anpassen. Inhouse-Schulungen können Europaweit durchgeführt werden.
  • Bei einer Individual-Schulung erhalten Sie eine 1-zu-1 Betreuung und bestimmen Inhalt, Zeit und Lerntempo. Der Dozent passt sich Ihren Wünschen und Bedürfnissen an.

Sie können unsere Schulungen auch als Remote Schulung im Virtual Classroom anfragen.

In drei Schritten zum Online Seminar im Virtual Classroom:

  1. Seminar auswählen und auf "Buchen" klicken
  2. Wählen Sie bei "Wie möchten Sie teilnehmen?" einfach "Online" aus.
  3. Formular ausfüllen und über den Button "Jetzt buchen" absenden.

Unser Kundenservice meldet sich bei Ihnen mit der Buchungsbestätigung.

Unsere Online Schulungen finden im Virtual Classroom statt. Ein Virtual Classroom bündelt mehrere Werkzeuge, wie Audio-Konferenz, Text-Chat, Interaktives Whiteboard, oder Application Sharing.

Vorteile von Virtual Classroom:

  • Sie erhalten 1 zu 1 die gleiche Lernumgebung, die Sie auch vor Ort bei uns vorfinden
  • Die technische Vorbereitung wird von den GFU-Technikern vorgenommen
  • Sie erhalten remote Zugriff auf Ihren persönlichen Schulungs-PC im GFU-Seminarraum
  • Die Virtual Classroom Lösung lässt sich auch im Browser betreiben
  • Die GFU-Technik leistet wie gewohnt Soforthilfe bei Problemen
  • Die Schulungsunterlagen bekommen Sie via DHL zugeschickt
  • Sie sparen Reisekosten und Zeit
  • 03. Aug. - 05. Aug. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
  • 12. Okt. - 14. Okt. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
  • 14. Dez. - 16. Dez. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
  • 19. Apr. - 21. Apr. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
  • 21. Jun. - 23. Jun. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
  • Auch als Inhouse-Schulung, bundesweit mit Termin nach Wunsch und individuellen Inhalten
  • Buchen ohne Risiko! Kostenfreie Stornierung bis zum Vortag des Seminars
Das GFU-Sorglos-Paket

Die Seminare der GFU finden in angenehmer Atmosphäre statt und sind perfekt organisiert. Profitieren Sie von dem Rundum-Service der GFU!

Shuttle-Service

Machen Sie sich keinen Kopf um die Anreise! Unser Shuttle fährt Sie. Oder Sie parken einfach auf einem extra für Sie reservierten Parkplatz.

Hotelreservierung

Hotelzimmer gesucht? Wir organisieren Ihnen eins. Ihr Vorteil: Sie sparen Zeit und Geld!

Kostenfreies Storno

Stornierung bei offenen Seminaren kostenfrei bis einen Tag vor Schulungsbeginn.

Technik-Support

Unsere Techniker sind immer zur Stelle, egal ob online oder vor Ort.

aegallianzaxaElement 1deutsche-bankdeutsche-postlufthansamercedessonyzdf