PostgreSQL und High Availability

[Colttt]

Hallo in die Runde,

ich setze mich aktuell mit PostgreSQL und high availability (HA) aus einander, jedoch erstmal nur rein theoretisch.
PSQL hat ja ein paar eingebaute Replikationen mit bei, die mMn schönste dabei ist Streaming Replication.

Das scheint ja relativ leicht zu sein, wenn ich es jedoch richtig verstehe und ein Server ausfällt und der andere übernimmt (quasi nen switchover) muss das durch eine Datei getriggert werden die in der recovery.conf drin steht.. so warum ist das so beknackt gemacht? aber ok das ist ja noch nicht das schlimmste. Wenn ist den old-master wieder repariert habe und dieser läuft und diesen starte muss ich wieder(!!) ein Backup vom Primary machen und das auf dem old-master einspielen. Geht das ganze auch schöner? bzw alles automatisiert? Ich will ja ja da nicht überall eingreifen. DRBD ist jetzt auch nicht soo die sauberste und schönste Lösung.

schonmal danke für die hilfe/infos!

PS: 2Server sollen in Master/Slave betrieb laufen, wenn Master ausfällt übernimmt Slave und wieder zurück möglichst ohne externe Einwirkung

[r4pt0r]

Genau weil die Replikationsmechanismen in praktisch allen RDBMs so "seltsam" und eher umständlich sind schaue ich mir aktuell Apache Cassandra an.

Wollte mich schon länger mit nichtrelationalen DBs beschäftigen und hab mir vor 2 Wochen spontan "Learning Apache Cassandra" (Mat Brown / Packt Publishing) bei O'Reilly bestellt (daily deal)...

Der Denkansatz des Datenmodells ist zwar erstmal ungewohnt bzw man muss sich teilweise erstmal zum denormalisieren zwingen und mit "multiple sources of truth" anfreunden, dann geht das aber sogar irgendwie leichter/logischer von der Hand als in DBRMs mit massenhaft joins. (Zumindest geht es mir so)

Die Replikation ist absolut simpel - es gibt keinen Master. Einfach neue Nodes zum Cluster hinzufügen, evtl den Replikationsfaktor anpassen und gut is. Alles andere regelt Cassandra. (Die Replikation basiert grundlegend auf Amazon Dynamo).
Die Applikation spricht nur den Cluster an, wo letztendlich die writes/reads ausgeführt werden ist dafür irrelevant und wird von Cassandra geregelt. Kein aufwändiges locking, fencing oder sonstwas bei/nach Ausfällen bis alle Master+Slaves wieder konsistent sind.

[TRex]

Und wie schauts dabei mit der Performance aus? Glücklich?

[r4pt0r]

Ich baue derzeit eine Testanwendung - eine Teiledatenbank für insgesamt ~750 000 Teile. Daraus soll dann ggf ne aktiv nutzbare Anwendung entstehen die nach und nach um weitere Funktionen wächst. Die rudimentäre Funktion wurde schon vor längerer Zeit mit PostgreSQL implementiert und läuft absolut ausreichend schnell (und um etliche Magnituden schneller als die proprietäre MSSQL-gestützte Anwendung die produktiv eingesetzt wird und keinerlei Replikation oder Skalierung unterstützt... )

Das reine Einlesen der Stammdaten aus der selben dicken csv in eine flache Tabelle (=nur ein primary key, kein compound-key oder clustering columns) ist zumindest messbar minimal schneller als in postgresql: ca 45 sec vs ca 40 sec.
Wobei ich mich da absolut nicht aus dem Fenster lehnen will - das Perl-Script das die csv am Client parst (=in ein hashtable liest) und in die DB am Server pumpt nutzt nicht DBI oder nen db-treiber sondern ruft einfach nur im Hintergrund psql bzw cqlsh auf. Das wurde nur absolut quick&dirty zusammengenagelt um die Testdatenbanken einmal zu füllen. Da es in beiden Fällen ausreichend schnell lief hab ich da noch nichts "richtiges" gebaut.
Zudem lief das jeweils mitten am Tag übers LAN ohne dass ich auf die aktuellen Netzwerk- und Serverlasten geachtet hab...


Da Cassandra extrem auf Schreib- und Sequentielle Lesezugriffe auf einzelne Zeilen bzw innerhalb einer Partition optimiert ist (basiert auf google bigtable) wird sich wohl auch erst mit entsprechendem denormalisierungsgrad und wachsender Datenmenge wirklich ein (größerer) Unterschied zeigen. Baut man 1:1 flache Tabellenstrukturen nach wie man sie aus RDBMs gewohnt ist und versucht diese ahnlich wie mit JOINS bei der abfrage zu verknüpfen säuft man komplett ab - Lesen über Partitionsgrenzen hinaus sind in Cassandra (und ähnlichen NoSQL-Varianten) ziemlich teuer, JOINS kennt CQL nicht und Suche in beliebigen Spalten ist nicht möglich; dafür gibt es aber sekundäre indexes die dann wieder extrem schnell sind.
Man muss sich also wirklich auf das andere Datenmodell einlassen und von compound-keys, clustering, _viel_ denormalisierung und "query-driven design" gebrauch machen, dann dürfte das aber jede RDBM locker hinter sich lassen speziell wenns dann ans eingemachte geht mit richtig großen Tabellen (bis weit in die dutzende mio zeilen/spalten) und Datemengen (TB++). Da skaliert Cassandra wie z.B. Hadoop dann auch ganz locker horizontal beliebig groß ohne wirklichen Aufwand und ohne dass die Anwendung speziell dafür angepasst werden muss. Da machts dann auch nichts wenn man evtl die Datenmenge durch denormalisierung deutlich erhöht hat, Speicher(platz) ist sowieso mit abstand die billigste Ressource...

Wahrscheinlich erschießt man damit zwar meistens Spatzen mit Interkontinentalraketen wenn man sich anschaut wo Cassandra eingesetzt wird: Apple (mit >100.000 nodes ), twitter, netflix, ebay, reddit... Aber weder am Footprint noch der Einrichtung hat man einen Mehraufwand gegenüber einer RDBM - bei der Skalierung sogar deutlich weniger weils ein essentieller Bestandteil und kein aus der Not entstandenes Feature ist. Also warum nicht Gebrauch davon machen
Ich bin bisher absolut begeistert wie steil die Lernkurve ist - wenn ich daran zurückdenke wie langwierig und Nervenraubend die ersten Kontakte mit RDBMs (mySQL mit PHP) waren


Als kurzer Überblick ist IMHO dieses Video recht gut (habe ich mir auch vorm kauf des ebooks angeschaut): https://www.youtube.com/watch?v=B_HTdrTgGNs
Datastax vertreibt den kommerziellen Ableger von Cassandra - von denen gibts auch viele Tutorials und Vorträge u.a. auf youtube und ein repo für .deb-pakete inkl einigen Tools die nicht in den apache-repos enthalten sind . Um rauszufinden ob Cassandra überhaupt zum Anwendungsfall passt sind die kurzen Einführungsvideos auf jeden Fall empfehlenswert.
Auch die englischsprachige Wikipediaseite gibt nen knappen Einblick und ist (wie so oft) deutlich informativer als die deutsche Ausgabe: https://en.wikipedia.org/wiki/Apache_Cassandra

[Colttt]

Warum Cassandra und nicht hadoop oder mongodb, couchdb etc?

Zumal wir hier vom Thema ab schweifen

[r4pt0r]

hadoop kann auch cassandra als DB nutzen

Cassandra ist mehr auf Echtzeitanwendungen zugeschnitten als HBase, das eher für batchanwendung optimiert ist (also für "typische" big-data Anwendungen wo massiv datamining und datenanalyse betrieben wird). Deshalb ist Cassandra eben auch für "live-Anwendungen" so interessant.

Was ich noch ganz vergessen hatte und Cassandra so extrem flexibel macht: Cassandra kann in Feldern auch mehrdimensionale Datentypen aufnehmen - arrays, listen, hashes usw - und diese effektiv und ohne aufwändiges vorhergehendes lesen/locking ändern und erweitern. Wenn man z.B. in Perl oft mit komplexen datenstrukturen ("hashes of hashes" usw) arbeitet fühlt man sich damit sofort zuhause...

Aber um wieder zum HA zurück zu kommen: ich setze gerade nodes nr 2,3 und 4 in meiner Testumgebung auf. Je 2 sitzen auf dem selben Virtualisierungs-Host, die Hosts sind an unterschiedlichen Standorten und per VPN verbunden. Werd mich dann etwas ausgiebiger mit der Replikation und konkurrierenden Zugriffen beschäftigen, speziell wie das mit den hohen Latenzen durch VPN hinhaut.

[Colttt]

OT: hättest du dir auch mal das hstore von Postgres angeguckt, das soll ja auch ähnlich zu NoSQL sein?!

Zum Topic: wenn du soviele Server hast, guck dir mal postgre-xc oder postgres-xl an, das sollte das sein was du suchst

[heisenberg]

Ich hänge mich mal da dran, weil ich gerade fast die gleiche Aufgabenstellung habe:

Ich will kein HA, bzw. sehe nicht dass das so einfach geht. Postgres-XC2 (Der Nachfolger von Postgres-XC) wäre nett, wenn ich mit MultiMaster und Loadbalancer selber steuern kann, welcher aktiv ist und ausnahmsweise bei einem manuellen Schwenk 2 Server gleichzeitig beschreiben könnte. Aber so wie das auf github aussieht, ist bei dem Projekt seit ca. 2 Jahren die Luft raus, da seitdem die Anzahl der Commits drastisch gesunken sind. Aussagen wie produktionsreif die Software ist habe ich bisher auch noch nicht wirklich gefunden.

Mir geht es eher um eine Möglichkeit kontrolliert Master und Slave schwenken zu können, um vielleicht mal ohne grossen organisatorischen Aufwand eine Wartung durchführen zu können. Eine der aktuellen Kisten hat eine Uptime von 4 Jahren. Da muss man mit rechnen, dass der nach reboot oder ausschalten nicht mehr hochkommt. Weiterhin nett wäre es, den Slave, wenn er denn verfügbar ist, einen Teil der Anfragen bearbeiten zu lassen. Da stand was davon in der News auf ProLinux: PostgreSQL 9.6 freigegeben.

Für mich ist die Vorgabe PostgreSQL fest. Da ist nix dran zu rütteln. Ich habe auch an die im Eröffnungsposting angedachte Vorgehensweise gedacht:

1. Ausgangslage ist Master + Slave als Hot-Standby(läuft derzeit so)
2. Bei einem manuellen Schwenk lasse ich die Verbindungen zum Master zunächst auslaufen und nehme keine neuen auf dem Master an. Evtl. müssen auch langlaufende Berechnungsläufe auf diversen Clients runtergefahren werden.
3. Wenn keine Verbindungen mehr da sind, wird der Slave hochgestuft.
4. Der bisherige Master wird mit dem letzten BaseBackup neu aufgesetzt und holt dann via Redo-Logs(WAL-Files) auf bis auf den Stand des neuen Masters. Ich meine das müsste auch kein BaseBackup des neuen Masters sein, sondern kann auch das letzte sein, als der Master, der jetzt Slave werden soll, noch Master war. Bin mir aber nicht ganz sicher.

Einen speziellen PG-Loadbalancer habe ich noch nicht gefunden - habe auch noch nicht grossartig danach gesucht.

Falls damit irgend jemand neuere Erkenntnisse hat, würde ich mich freuen.

[Colttt]

[...]
Postgres-XC2 (Der Nachfolger von Postgres-XC) wäre nett, wenn ich mit MultiMaster und Loadbalancer selber steuern kann[...]

guck dir mal Postgres-XL an, das wird aktiv entwickelt, dort solltest du dein glück finden..

anaonsten sollte doch hier eigentlich alles stehen: https://www.postgresql.org/docs/9.5/sta ... ility.html.
durch pg_rewind sollte es mit dem "einfachen" schwenken und (vor allem) wieder zurück um einiges einfacher sein

[heisenberg]

Danke für die Lesetipps Colttt!

[Milbret]

@Colttt
Um die Daten möglichst schnell zu importieren, kannst du deine csv auch mit psql selbst in die db schieben.
Mit dem Befehl COPY FROM kannst du dann auch mit den entsprechenden Optionen direkt die csv einlesen, parsen und in die Tabellen schieben lassen.
Das dürfte dann auch den Import um einiges beschleunigen.
Oder wird dies durch dein Perl Zeug schon so gemacht?

Ansonsten gehe ich auch davon aus, dass du deine postgresql.conf getunt hast
Ich empfehle dafür pgtune:
http://pgtune.leopard.in.ua/

Ich habe hier mit Debian Jessie ein paar Testläufe gemacht, ohne Replikation, und da kann man mit guten Tuning selbst auf einfacher Hardware schon ordentliche Performance bekommen.
Ggf. auch mit pgbench etwas rumtesten.
Gibt es bei Debian im postgresql-contrib Paket.

Martin

[smiler]

Hallo,

für postgresql gibt es auch noch pgpool (http://www.pgpool.net/mediawiki/index.php/Main_Page )als loadbalancer für ein "richtiges" HA-Setup.
Ich selber hab es noch nicht aufgesetzt, aber in folghendem Blogpos ist eine (auf den ersten Blick) ausführliche anleitung:

http://linux.xvx.cz/2014/10/loadbalanci ... bases.html

Thomas