PostgreSQL in der Praxis - Replikation und Hochverfügbarkeit

Transkript

1 PostgreSQL in der Praxis - Replikation und Hochverfügbarkeit Michael Banck <michael.banck@credativ.de> FrOSCon 2017 Michael Banck <michael.banck@credativ.de> 1 / 31

2 PostgreSQL - Überblick Erweiterbares, Objekt-Relationales Datenbanksystem Entstanden als Forschungsprojekt in Berkeley, Community-basierte Entwicklung seit Mitte der 90er Hersteller-Unabhängig, kommerzieller Support von mehreren Firmen erhältlich Postgres Global Development Group, 5 köpfiges Core Team, 3 köpfiges Release Team, ca. 20 Committer Jährlicher Release-Zyklus, 5 Jahre Wartungszeitraum pro Release Vierteljährliche Patch-Releases Keine Copyright-Assignments, Open-Core oder Dual-Lizenzierung BSD/MIT-artige Lizenz Viele (auch proprietäre) Forks Michael Banck <michael.banck@credativ.de> 2 / 31

3 PostgreSQL - Forks Michael Banck <michael.banck@credativ.de> 3 / 31

4 PostgreSQL - Cloud Provider Michael Banck <michael.banck@credativ.de> 4 / 31

5 PostgreSQL - Haupt-Features Rock Solid Gute und konsistente Abdeckung des SQL-Standards, sowie sinnvolle moderne Erweiterungen Kosten-basierter Query-Planer Große Anzahl an Erweiterungen Transaktionale Änderungen an Datenbankstruktur Hohe Anzahl an Treibern für Programmiersprachen Viele verschiedene prozedurale Sprachen Fremddaten-Wrapper für den Zugriff auf viele andere Datenquellen/Datenbanken Michael Banck <michael.banck@credativ.de> 5 / 31

6 PostgreSQL - Benutzer Michael Banck <michael.banck@credativ.de> 6 / 31

7 Top Feature-Requests 2009 Einfache, eingebaute Replikation In-Place Upgrades Administration/Monitoring Treiber-Qualität/Wartung Erweiterungs-Management Locales/Collationen pro Spalte Materialisierte und Aktualisierbare Sichten Parallelisierte Queries Index-Only Scans Merge/Upsert Anweisung Automatische Partitionierung Hot Standby Rekursive Abfragen Window Funktionen Autonome Transaktionen Michael Banck 7 / 31

8 Top Feature-Requests Stand 2017 Einfache, eingebaute Replikation In-Place Upgrades Administration/Monitoring Treiber-Qualität/Wartung Erweiterungs-Management Locales/Collationen pro Spalte Materialisierte und Aktualisierbare Sichten Parallelisierte Queries Index-Only Scans Merge/Upsert Anweisung Automatische Partitionierung Hot Standby Rekursive Abfragen Window Funktionen Autonome Transaktionen Michael Banck <michael.banck@credativ.de> 8 / 31

9 Aussicht auf Postgres 10 Logische Replikation Weitergehende Parallelisierung Native, deklarative Partitionierung Client-basiertes Verbindungs-Failover Quorum-Commit für synchrone Standbys Vereinfachte Konfiguration von Replikation Salted Challenge Response Authentication Mechanism (SCRAM) Verbesserte und Produktiv-Reife Hash-Indexe Schnellere Ausführung von Expressions Änderung der SSL-Einstellungen ohne Neustart Spaltenübergreifende Statistiken für den Query-Planer Michael Banck 9 / 31

10 Replikation Michael Banck 10 / 31

11 PostgreSQL Streaming Replication Transaktionslog (Write-Ahead Log) wird via Datenbank-Verbindung übertragen (streaming) Standby wendet Transaktionslog an und befindet sich fortlaufend im Wiederherstellungs-Modus Lesende Abfragen auf Standby möglich (Hot-Standby) Einschränkungen: Gleiche Major-Version zwischen Primary und Standby nötig Gesamte Instanz, keine einzelnen Datenbanken oder Teile davon Michael Banck 11 / 31

12 PostgreSQL Streaming Replication Michael Banck 12 / 31

13 PostgreSQL Streaming Replication - Operative Features Vorhaltung der benötigten Transaktionslogs auf Primary pro Standby via Replikations-Slots Cloning eines neuen Standbys Switchover, Switchback, Promote und Remastering Kaskadierende und/oder Zeitverzögerte Replikation Quorum-basierte synchrone Replikation, optional pro Transaktion Synchronitäts-Level: An Standby gesendet In Transaktionslog geschrieben In Datenverzeichnis geschrieben Bereit für lesende Abfragen Optional zentrale Archivierung von Transaktionslogs Einfache Konfiguration Michael Banck <michael.banck@credativ.de> 13 / 31

14 PostgreSQL Streaming Replication - Setup mit Postgres 10 $ initdb --pgdata=data1 1> /dev/null 2>&1 $ pg_ctl --pgdata=data1 --log=pg1.log start 1> /dev/null $ pg_basebackup --pgdata=data2 --write-recovery-conf $ sed -i -e s/^#port.=.5432/port = 5433/ \ > data2/postgresql.conf $ pg_ctl --pgdata=data2 --log=pg2.log start 1> /dev/null $ psql --tuples-only --port dbname postgres \ > --command "SELECT pg_is_in_recovery();" t Michael Banck <michael.banck@credativ.de> 14 / 31

15 Logische Replikations-Lösungen Versions-Unabhängig Einzelne Datenbanken, oder Teile davon replizierbar Trigger-basiert Slony-I Londiste Bucardo (Master-Master) Logical Decoding-basiert Native Logical Replication (ab PostgreSQL 10) pglogical (Erweiterung, seit 9.4) Bi-Directional Replication (BDR, Master-Master) Michael Banck 15 / 31

16 Logische Replikations-Lösungen - Benchmark Michael Banck <michael.banck@credativ.de> 16 / 31

17 PostgreSQL Logical Replication Michael Banck 17 / 31

18 PostgreSQL Logical Replication - Setup mit Postgres 10 Replikation via CREATE PUBLICATION/SUBSCRIPTION: primary=> CREATE PUBLICATION pub1 FOR ALL TABLES; CREATE PUBLICATION standby=> CREATE SUBSCRIPTION sub1 CONNECTION \ standby-> dbname=primary PUBLICATION pub1; NOTICE: created replication slot "sub1" on publisher CREATE SUBSCRIPTION Replikation ist pro Datenbank Einschränkungen: Tabellenstruktur muss separat aufgesetzt werden Superuser-Rechte benötigt Bisher kein Support für Failover Michael Banck <michael.banck@credativ.de> 18 / 31

19 Hochverfügbarkeit Michael Banck 19 / 31

20 Hochverfügbarkeit - Definition Schutz gegen Hardware/Software-Ausfall CPU defekt Ausfall Netzwerk-Karte Kernel-Panik Absturz des Postgres-Prozesses Wartung beeinträchtigt Betrieb nicht Neustart Postgres-Prozess nach Patching oder Konfiguration-Änderung Major-Versions Upgrade von Postgres Aktualisierung Betriebssystem Anwendung ist durchgehend verfügbar Keine langanhaltenden Locks während Schema-Änderungen Michael Banck <michael.banck@credativ.de> 20 / 31

21 Hochverfügbarkeit - Produkte und Lösungen Pacemaker/Corosync pgsql Ressourcen-Agent (Standard) pgsqlms Ressourcen-Agent (PostgreSQL Automatic Failover, PAF) repmgr pgpool-ii Patroni Compose Governor Stolon Michael Banck <michael.banck@credativ.de> 21 / 31

22 Hochverfügbarkeit - Client Failover Lösungen Virtuelle IPs (VIPs) DNS mit kurzem TTL HAProxy mit Health-Check bzgl. Primary Automatisierte Anpassung pgbouncer-konfiguration nach Promote Client-basiertes Failover durch Angabe mehrerer Hosts PgJDBC (seit ) libpq (ab Postgres 10) Michael Banck <michael.banck@credativ.de> 22 / 31

23 Hochverfügbarkeit - Pacemaker Corosync bietet Low-Level Messaging, Membership und Quorum Pacemaker managed Ressourcen-(Gruppen) Virtuelle IP(s) Fencing Agents/STONITH Postgres-Prozess(e) Cold Standby, Shared Storage SAN oder DRBD-repliziert Postgres-Datenverzeichnis schwenkt mit, Recovery beim Starten Synchron per Definition Replikation über Master/Slave Set, Lokales Storage Standby wird automatisch promotet, wenn Primary wegbricht Kein automatisches Recovery des alten Primaries Synchrone oder Asynchrone Replikation möglich Typischerweise 2-Knoten Cluster, kein automatisches Scale-Out Michael Banck <michael.banck@credativ.de> 23 / 31

24 Hochverfügbarkeit - Pacemaker Master/Slave Set (pgsql) Pacemaker Multi-State Ressource (ms pgsql) Streaming Replication zwischen Primary ( Master ) und Standby ( Slave ) Für Postgres zwingend 1 Master (master-max=1) Mehrere Standbys möglich (clone-max=2/3/4...) Maximal eine Instanzart (Master oder Slave) pro Server (clone-node-max=1, master-node-max=1) Transaktions-Log Position und Status (Primary/Standby, Synchron/Asynchron) wird als Node-Attribut gespeichert Bei Failover mit mehreren Standbys Leader-Election auf Basis von Score Synchroner Standby mit Umschalten auf asynchron möglich, kann bei 2-Node Setups zu hängenden Verbindungen führen Michael Banck <michael.banck@credativ.de> 24 / 31

25 Hochverfügbarkeit - Pacemaker Master/Slave Set (pgsql) Master/Slave Set: ms_pgsql [pgsql] Masters: [ h1db1 ] Slaves: [ h1db2 ] Node Attributes: * Node h1db1: + master-pgsql : pgsql-data-status : LATEST + pgsql-master-baseline : pgsql-status : PRI * Node h1db2: + master-pgsql : pgsql-data-status : STREAMING ASYNC + pgsql-status : HS:async Michael Banck <michael.banck@credativ.de> 25 / 31

26 Hochverfügbarkeit - Pacemaker Requirements und Best-Practises Abhängigkeit von VIP und Postgres via order-direktive order <name> 0: ms pgsql:promote vip master:start symmetrical=false Abhängigkeit von Master/Slave VIP zu entsprechender Ressource colocation <name> inf: vip master ms pgsql:master STONITH-Ressource stets auf anderem Knoten location <name> fence node1 -inf: node1 Maintenance-Mode bei Wartungen crm attribute --name maintenance-mode --update true Simulation von Status-Änderungen z.b. crm simulate --node-up Timeouts, Timeouts, Timeouts; Tests unter Last - z.b. mit jmeter Michael Banck <michael.banck@credativ.de> 26 / 31

27 Hochverfügbarkeit - Pacemaker Master/Slave Set (PAF) Neuer Ressourcen-Agent pgsqlms, entwickelt von Dalibo, Postgres-Lizenz Nur Master/Slave-Set, nur Streaming Replication Neben Failover/Promote auch kontrolliertes Switchover/ Switchback und Demote möglich Switchover nur wenn momentaner Primary problemlos wieder Standby werden kann Im Promote-Fall wird Notify-Event abgefangen und abgeklärt, ob andere Knoten weitere Transaktionen nachgespielt haben Einfach(ere) Konfiguration Für Neuinstallationen empfohlen Michael Banck <michael.banck@credativ.de> 27 / 31

28 Hochverfügbarkeit - Patroni Projekt von Zalando, MIT Lizenz, Python Konfiguriert Instanzen und Replikation, ermöglicht Switchover Verwendet etcd als Verteiltes Konfigurations-System (DCS) Raft-Algorithmus für Leader Election Vermeidung von Split-Brain, ungerade Anzahl an Knoten Leader Time-to-Live Postgres Cluster-Status Transaktions-Log Position Node-Tags Optional HAProxy für Master/Replica Service-Endpunkte HTTP-Check REST-API auf /master bzw. /replica Optional confd zur Aktualisierung der HAProxy Konfiguration an Hand des etcd Datenbestands Momentan Arbeit an Kubernetes-Integration (u.a. von Red Hat) Michael Banck <michael.banck@credativ.de> 28 / 31

29 Hochverfügbarkeit - Patroni Michael Banck <michael.banck@credativ.de> Figure: 29 / 31

30 Hochverfügbarkeit - Patroni We are already running some hundreds PostgreSQL clusters in AWS + etcd with Spilo/Patroni. After evaluting both [Stolon and Patroni], I opted for Patroni, and I got to work integrating it into our environment [... ] and it worked like a charm when it came time to do the cutover Michael Banck <michael.banck@credativ.de> 30 / 31

31 Danke für die Aufmerksamkeit - Kontakt Fragen? Michael Banck <michael.banck@credativ.de> Twitter, Michael Banck <michael.banck@credativ.de> 31 / 31