
Bitte wählen Sie die Bereiche, die Sie exportieren möchten:

Schulung PostgreSQL Hochverfügbarkeit und Replikation
Streaming Replication, Logical Replication, Patroni und Connection Pooling
Schulungsformen
Offene Schulung
- 3 Tage
- 5 gesicherte Termine
- Köln / Online
- 2.030,00 p. P. zzgl. MwSt.
- Dritter Mitarbeitende kostenfrei
- Learning & Networking in einem. Garantierte Durchführung ab 1 Teilnehmenden.
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.
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.
Beschreibung
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
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.
- 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.
- 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.
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.
- 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).
- 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.
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.
- 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.
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.
- 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.
- 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?"
Zielgruppe & Vorkenntnisse
- 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.
Ihre Schulung
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. | |
Organisation
In Präsenz | Online | |
|---|---|---|
| Teilnehmendenzahl | ||
min. 1, max. 8 Personen | ||
| Garantierte Durchführung | ||
Ab 1 Teilnehmenden* | ||
| Schulungszeiten | ||
| ||
| Ort der Schulung | ||
GFU SchulungszentrumAm 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. 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. | ||
| 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 | - | |
Buchen ohne Risiko
| 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 |
Kostenfreie Services
In Präsenz | Online |
|---|---|
|
|
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.
Gesicherte offene Termine
| Termin | Ort | Preis | ||
|---|---|---|---|---|
| 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 | |
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Unterstützung nach der Schulung durch
individuelle Nachbetreuung
- 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:
- Seminar auswählen und auf "Buchen" klicken
- Wählen Sie bei "Wie möchten Sie teilnehmen?" einfach "Online" aus.
- 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
Die Seminare der GFU finden in angenehmer Atmosphäre statt und sind perfekt organisiert. Profitieren Sie von dem Rundum-Service der GFU!
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.
Hotelzimmer gesucht? Wir organisieren Ihnen eins. Ihr Vorteil: Sie sparen Zeit und Geld!
Stornierung bei offenen Seminaren kostenfrei bis einen Tag vor Schulungsbeginn.
Unsere Techniker sind immer zur Stelle, egal ob online oder vor Ort.
GFU Schulungszentrum