Sonntag, 24. August 2008

PGPool-II als Loadbalancer und HA Lösung für Postgres

Im Netz findet man eine Menge verstreuter Informationen über PGPool. Es gibt eine Dokumentation, aber sie reißt viele Funktionen nur an und lässt Einsteiger an vielen Stellen im Dunkeln. Es hat mich eine Menge Mühe gekostet die Software wie gewünscht zum Laufen zu bringen. Gerade das Aufsetzen von der Online Recovery Scripte hat sich sehr in die Länge gezogen, weil Funktion, Aufrufszeitpunkt und -ort nicht klar dokumentiert sind. Aus diesem Grund schreibe ich heute ein kleines Howto über PGPool-II.

Als erstes braucht man ein Hostsystem für PGPool. Wir hatten zuerst OpenBSD im Auge, weil es über hervorragende Routing und TCP Loadbalancing Funktionen verfügt. Neben Postgres brauchten wir auch Loadbalancing für HTTP. Compilieren lässt sich PGPool wenn man ein paar Ports installiert hat und es funktioniert auch. Allerdings hatten wir später Versionsprobleme beim Onlinerecovery. Aus diesem Grund haben wir unsere Loadbalancer unser Ubuntu Linux aufgesetzt. Von den Packeten aus dem Repository raten wir allerdings ab, weil sie mittelmäßig veraltet sind. Kompilieren war unter Ubuntu relativ einfach.

Die Configuration in der pgpool.conf ist relativ gut dokumentiert. Im Grunde reicht es die IPs und Ports der Postgres Nodes einzutragen und PGPool funktioniert erstmal. Doch dann kommt die Wahl des Modes. Hier stehen verschiedene Modi zur Verfügung. In welcher Kombination sie Funktionieren lässt sich der Matrix im pgpool readme entnehmen.

Da es in unseren Applikationen wenig Schreiblast und viel Leselast gibt, haben wir uns für den Replication Mode entschieden. Wie man der Matrix im Readme entnehmen kann, ist im Replication Mode auch Loadbalancing möglich.

Alle SELECT Querys werden vom PGPool gleichmäßig auf alle Nodes aufgeteilt und die Last sinkt dadurch signifikant. Schreibende Querys wie z.b. INSERT, UPDATE oder DELETE werden auf allen Nodes ausgeführt. Es ist hier wichtig, dass sie deterministisch sind, also überall zum gleichen Ergebnis führen. Ansonsten kann es passieren, dass die Datenbanken inkonsistent werden. Besondere Vorsicht ist bei Funktionen wie NOW() oder RAND() geboten.

Aufpassen muss man auch bei Stored Procedures. Da mit einem SELECT Query aufgerufen werden hält der PGPool sie für lesende Abfragen. Das ist allerdings nicht immer der Fall. Als Lösung bietet es sich an bei schreibenden Stored Procedures den Kommentar /* NO LOADBALANCING */ zu schreiben.

Damit wird der Query auf allen Nodes ausgeführt. Der Preis für die Möglichkeit keinen Master Server zu haben darin besteht, dass man sich selber darum kümmern muss, dass alle Server immer in sync bleiben.

Da stellt sich die Frage was man anstellen muss damit Server in syncron werden. Im Postgres gibt es eine Funktion namens PTR - Point in Time Recovery. Diese macht sich PGPool zu nutze und automatisiert den Vorgang in drei kleinen Scripten die leider kaum dokumentiert sind. Dabei ist es wichtig dass alle Postgres Server untereinander Daten kopieren können. Außerdem müssen drei C Stored Procedures auf jedem Postgres Server installiert sein.

Online Recovery läuft nun in zwei Stufen ab. Stage1 - Checkpoint auf dem Master Server. Intern hat PGPool einen Master Server, aber prinzipiell sind alle Nodes gleichberechtigt. Danach wird das WAL (Write Ahead Log) gestartet und alle Daten zum Degraded Node kopiert.

Nun wartet PGPool, dass keine Verbindungen mehr zu einer Datenbank bestehen. In Stage 2 wird der Postgres Prozess auf dem neuen Node gestartet und stellt alle Transactions nach dem Checkpoint wieder her. Die letzten WAL Logs werden mit dem Befehl in der recovery.conf vom Master geholt. Dieser Prozess geht in der Regel sehr schnell. Danach ist der Node (wieder) Teil des Clusters und wird wie alle anderen Postgres Instancen behandelt.

Damit Online Recovery funktioniert ist es wichtig, dass kein anderer PGPool läuft. Ansonsten wartet PGPool vor Beginn von Stage2 bis zum Timeout, da PGPool die Verbindungen zu den Datenbanken in der Regel nicht beendet. Um den Datentransfer zwischen den Nodes zu ermöglichen bietet sich ssh pub-key Authentification an. Alternativ funktioniert auch ein gemeinsames SAN, NFS oder Samba Freigaben. Natürlich sollte man versuchen alle Rechner so homogen wie möglich zu halten, denn man weiß vorher nicht unbedingt von wo nach wo Online Recovery kopiert.

Keine Kommentare: