In Bezug auf Bernds Blogpost mit seinem Hinweis auf die gute Weiterentwicklung der Replikationsfunktionen in Postgresql stelle ich heute eine sehr komfortable und robuste Art der PGSQL-Replikation vor. Postgresql verfügt ab der Version 9.0 über eine Streaming-Replikation mit Hot-Stand-by. Eine Streaming-Replikation ist im Prinzip das gleiche Verfahren wie bei einem MySQL Master-Slave Setup mit Row-Based Replikation. Das WAL (Write-Ahead-Log) wird hier vom Read-only Slave Server abgerufen und ausgeführt. Im Falle eines Ausfalls des Masters besteht die Möglichkeit darauf zu reagieren und vom Read-Only- in Read-Write-Mode zu wechseln und somit den Slave zum Master zu propagieren.
Die third-party Software pgpool2 ist in der Lage diesen Failover zu steuern bzw. zu veranlassen. Pgpool2 ist eine Middleware die zwischen dem PGSQL-Client und Servern fungiert und bietet folgende Funktionen:
- Connection-Pooling,
Verbindungen zu den PGSQL-Servern werden persistent erzeugt und werden wiederverwendet.
- Replication,
DML-Statements können dupliziert werden und an die dahinter liegenden Postgres Server verteilt. Eine Streaming-Replikation wäre hierbei nicht notwendig.
- Load-Balancing,
Client-Anfragen werden verteilt auf die Nodes, die sich im Pool befinden. In einer Streaming-Replikation besteht außerdem die Möglichkeit DML-Statements nur an den Master zu senden und SELECTS an die Slaves.
- Limiting Exceeding Connections,
bei erreichen der maximalen Anzahl von Datenbankverbindungen gibt Postgres einen Fehler zurück. pgpool2 kann diese Verbindungen in eine Queue ablegen und abarbeiten.
- Parallel Query
Queries können paralell über mehrere Datenbankserver hinweg ausgeführt werden, um ein Ergebnis schneller ausliefern zu können.
Für die Hot-Standby-Lösung muss der Replikationsmodus von pgpool2 deaktiviert werden. pgpool2 steuert nur die Verbindungen auf die Server, sucht sich seinen Master und kümmert sich um den Failover. Hierfür sind einige kleine Skripte notwendig. Ein weiteres sehr nützliches Feature ist die Überwachung des Slave-Lags. Ist der Slave-Lag höher als der eingestellte Schwellwert schwenkt pgpool2 die Verbindungen von diesem Slave weg bis dieser wieder aufgeholt hat. Auch sehr hilfreich ist das Online-Recovery das eigentlich durch Postgres zur Verfügung gestellt wird. Mit pgpool2 kann man dieses jedoch bequem starten und einen inkonsistenten Slave von seinem Master im Produktivbetrieb ohne Downtime, Snapshots oder gelockten Tabellen wiederherstellen.
Die Steuerung von pgpool2 erfolgt über die i.d.R. mit installierten CLI-Tools. Zum Beispiel kann man mit pcp_recovery_node das Online-Recovery durchführen oder mit pcp_attach_node bzw. pcp_detach_node Hosts aus dem Pool entfernen bzw. hinzufügen.
Der Blogpost soll nur einen kurzen Überblick über Features und Möglichkeiten darstellen – vollständige Informationen findet man in den sehr guten Dokumentationen von pgpool2 und Postgresql.
0 Kommentare