Patroni-Fehlergeschichten oder So stürzen Sie Ihren PostgreSQL-Cluster ab. Alexey Lesovsky

Das Hauptziel von Patroni ist die Bereitstellung hoher Verfügbarkeit für PostgreSQL. Aber Patroni ist nur eine Vorlage, kein fertiges Tool (was im Allgemeinen in der Dokumentation gesagt wird). Nachdem Sie Patroni im Testlabor installiert haben, können Sie auf den ersten Blick erkennen, was für ein großartiges Werkzeug es ist und wie problemlos es unsere Versuche, den Cluster zu durchbrechen, bewältigt. Allerdings läuft in der Praxis in einer Produktionsumgebung nicht immer alles so schön und elegant ab wie in einem Testlabor.

Ich erzähle dir ein wenig über mich. Ich habe als Systemadministrator angefangen. Arbeitete in der Webentwicklung. Ich arbeite seit 2014 bei Data Egret. Das Unternehmen ist in der Beratung im Bereich Postgres tätig. Und wir bedienen genau Postgres und arbeiten jeden Tag mit Postgres zusammen, sodass wir über unterschiedliche Fachkenntnisse in Bezug auf den Betrieb verfügen.

Und Ende 2018 begannen wir langsam, Patroni zu nutzen. Und es wurden einige Erfahrungen gesammelt. Wir haben es irgendwie diagnostiziert, optimiert und sind zu unseren Best Practices gekommen. Und in diesem Bericht werde ich darüber sprechen.

Abgesehen von Postgres liebe ich Linux. Ich stöbere gerne darin herum und erkunde, ich sammle gerne Kerne. Ich liebe Virtualisierung, Container, Docker, Kubernetes. Das alles interessiert mich, weil die alten Verwaltungsgewohnheiten Auswirkungen haben. Ich beschäftige mich gerne mit Überwachung. Und ich liebe Postgres-Dinge im Zusammenhang mit der Verwaltung, also Replikation, Backup. Und in meiner Freizeit schreibe ich in Go. Ich bin kein Softwareentwickler, ich schreibe nur für mich selbst in Go. Und es macht mir Freude.

• Ich denke, viele von Ihnen wissen, dass Postgres nicht standardmäßig über HA (High Availability) verfügt. Um HA zu erhalten, müssen Sie etwas installieren, konfigurieren, sich anstrengen und es erhalten.
• Es gibt mehrere Tools und Patroni ist eines davon, das HA ziemlich cool und sehr gut löst. Aber indem wir alles in ein Testlabor stellen und laufen lassen, können wir sehen, dass alles funktioniert, wir können einige Probleme reproduzieren und sehen, wie Patroni ihnen hilft. Und wir werden sehen, dass alles großartig funktioniert.
• Aber in der Praxis standen wir vor anderen Problemen. Und ich werde über diese Probleme sprechen.
• Ich erzähle Ihnen, wie wir es diagnostiziert haben, was wir optimiert haben – ob es uns geholfen hat oder nicht.

• Ich werde Ihnen nicht sagen, wie Sie Patroni installieren, da Sie im Internet googeln und sich die Konfigurationsdateien ansehen können, um zu verstehen, wie alles beginnt und wie es konfiguriert ist. Sie können die Schemata und Architekturen verstehen und Informationen dazu im Internet finden.
• Ich werde nicht über die Erfahrungen anderer sprechen. Ich werde nur über die Probleme sprechen, mit denen wir konfrontiert waren.
• Und ich werde nicht über Probleme sprechen, die außerhalb von Patroni und PostgreSQL liegen. Wenn es zum Beispiel Probleme im Zusammenhang mit dem Balancing gibt, wenn unser Cluster zusammengebrochen ist, werde ich nicht darüber sprechen.

Und ein kleiner Haftungsausschluss, bevor wir mit unserem Bericht beginnen.

Alle diese Probleme, auf die wir gestoßen sind, hatten wir in den ersten 6-7-8 Betriebsmonaten. Im Laufe der Zeit kamen wir zu unseren internen Best Practices. Und unsere Probleme verschwanden. Deshalb wurde der Bericht vor etwa sechs Monaten angekündigt, als alles noch frisch in meinem Kopf war und ich mich perfekt daran erinnern konnte.

Im Zuge der Erstellung des Berichts habe ich bereits alte Obduktionen erstellt und mir die Protokolle angesehen. Und einige Details könnten vergessen werden oder einige Details könnten bei der Analyse der Probleme nicht vollständig untersucht werden, so dass es an manchen Stellen so aussehen könnte, als ob die Probleme nicht vollständig berücksichtigt würden oder es an Informationen mangele. Und deshalb bitte ich Sie, mich für diesen Moment zu entschuldigen.

Was heißt Patroni?

• Dies ist eine Vorlage zum Erstellen von HA. So steht es in der Dokumentation. Und aus meiner Sicht ist das eine sehr richtige Klarstellung. Patroni ist kein Allheilmittel, das alle Ihre Probleme löst. Das heißt, Sie müssen sich anstrengen, damit es funktioniert und Vorteile bringt.
• Dabei handelt es sich um einen Agentendienst, der auf jedem Datenbankdienst installiert wird und eine Art Init-System für Ihr Postgres darstellt. Es startet Postgres, stoppt, startet neu, konfiguriert es neu und ändert die Topologie Ihres Clusters.
• Um den Zustand des Clusters, seine aktuelle Darstellung, so wie er aussieht, zu speichern, ist dementsprechend eine Art Speicher erforderlich. Und aus dieser Sicht ging Patroni den Weg der Zustandsspeicherung in einem externen System. Es handelt sich um ein verteiltes Konfigurationsspeichersystem. Es kann Etcd, Consul, ZooKeeper oder Kubernetes Etcd sein, also eine dieser Optionen.
• Und eine der Besonderheiten von Patroni besteht darin, dass Sie den Autofiler sofort nach dem Auspacken erhalten, indem Sie ihn nur einrichten. Nehmen wir zum Vergleich Repmgr, dann ist der Filer dort enthalten. Mit Repmgr bekommen wir eine Umstellung, aber wenn wir einen Autofiler wollen, dann müssen wir ihn zusätzlich konfigurieren. Patroni verfügt bereits über einen automatischen Filer.
• Und es gibt noch viele andere Dinge. Zum Beispiel die Wartung von Konfigurationen, das Gießen neuer Replikate, Backups usw. Aber das würde den Rahmen des Berichts sprengen, ich werde nicht darüber sprechen.

Und ein kleines Ergebnis ist, dass die Hauptaufgabe von Patroni darin besteht, eine automatische Datei gut und zuverlässig durchzuführen, damit unser Cluster betriebsbereit bleibt und die Anwendung keine Änderungen in der Cluster-Topologie bemerkt.

Aber wenn wir anfangen, Patroni zu verwenden, wird unser System etwas komplizierter. Wenn wir früher Postgres hatten, erhalten wir bei der Verwendung von Patroni Patroni selbst, wir erhalten DCS, in dem der Status gespeichert ist. Und es muss alles irgendwie funktionieren. Was kann also schief gehen?

Kann brechen:

• Postgres könnte kaputt gehen. Es kann sich um einen Master oder eine Replik handeln, einer von ihnen kann ausfallen.
• Der Patroni selbst kann brechen.
• Das DCS, in dem der Status gespeichert ist, kann kaputt gehen.
• Und das Netzwerk kann kaputt gehen.

All diese Punkte werde ich im Bericht berücksichtigen.

Ich werde Fälle betrachten, wenn sie komplexer werden, und nicht unter dem Gesichtspunkt, dass der Fall viele Komponenten umfasst. Und aus der Sicht des subjektiven Empfindens war dieser Fall für mich schwierig, es war schwierig, ihn zu zerlegen ... und umgekehrt war ein Fall leicht und es war leicht, ihn zu zerlegen.

Und der erste Fall ist der einfachste. Dies ist der Fall, wenn wir einen Datenbankcluster genommen und unseren DCS-Speicher auf demselben Cluster bereitgestellt haben. Dies ist der häufigste Fehler. Dies ist ein Fehler bei der Gebäudearchitektur, also der Kombination verschiedener Komponenten an einem Ort.

Da gab es also einen Aktenvermittler, lasst uns uns darum kümmern, was passiert ist.

Und hier interessiert uns, wann der Filer passiert ist. Das heißt, wir interessieren uns für den Zeitpunkt, an dem sich der Clusterzustand änderte.

Der Filer ist jedoch nicht immer augenblicklich, d. h. er benötigt keine Zeiteinheit, sondern kann verzögert werden. Es kann langlebig sein.

Daher hat es eine Startzeit und eine Endzeit, es handelt sich also um ein kontinuierliches Ereignis. Und wir unterteilen alle Ereignisse in drei Intervalle: Wir haben Zeit vor dem Filer, während des Filer und nach dem Filer. Das heißt, wir berücksichtigen alle Ereignisse in dieser Zeitleiste.

Und als erstes, wenn ein Filer passiert ist, suchen wir nach der Ursache dessen, was passiert ist, was die Ursache dafür war, was zum Filer geführt hat.

Wenn wir uns die Protokolle ansehen, handelt es sich um klassische Patroni-Protokolle. Er teilt uns darin mit, dass der Server zum Master geworden ist und die Rolle des Masters auf diesen Knoten übergegangen ist. Hier ist es hervorgehoben.

Als nächstes müssen wir verstehen, warum der Filer passiert ist, d. h. welche Ereignisse aufgetreten sind, die dazu geführt haben, dass die Master-Rolle von einem Knoten auf einen anderen verschoben wurde. Und in diesem Fall ist alles einfach. Bei der Interaktion mit dem Speichersystem ist ein Fehler aufgetreten. Der Meister erkannte, dass er mit DCS nicht arbeiten konnte, das heißt, es gab ein Problem mit der Interaktion. Und er sagt, dass er kein Meister mehr sein kann und tritt zurück. Diese Zeile „degradiertes Selbst“ sagt genau das.

Wenn wir uns die Ereignisse ansehen, die dem Filer vorausgingen, können wir dort genau die Gründe erkennen, die das Problem verursacht haben, den Assistenten fortzusetzen.

Wenn wir uns die Patroni-Protokolle ansehen, werden wir feststellen, dass wir viele Fehler und Zeitüberschreitungen haben, d. h. der Patroni-Agent kann nicht mit DCS arbeiten. In diesem Fall handelt es sich um den Consul-Agenten, der über Port 8500 kommuniziert.

Und das Problem dabei ist, dass Patroni und die Datenbank auf demselben Host laufen. Und die Consul-Server wurden auf demselben Knoten gestartet. Indem wir den Server überlasteten, verursachten wir auch Probleme für die Consul-Server. Sie konnten nicht richtig kommunizieren.

Nach einiger Zeit, als die Belastung nachließ, konnte unser Patroni wieder mit den Agenten kommunizieren. Die normale Arbeit wurde wieder aufgenommen. Und derselbe Pgdb-2-Server wurde wieder zum Master. Das heißt, es gab einen kleinen Umschwung, aufgrund dessen der Knoten die Befugnisse des Meisters aufgab und sie dann wieder übernahm, das heißt, alles kehrte zurück, wie es war.

Und das kann als falscher Alarm angesehen werden, oder man kann davon ausgehen, dass Patroni alles richtig gemacht hat. Das heißt, er erkannte, dass er den Status des Clusters nicht aufrechterhalten konnte und entzog ihm seine Autorität.

Und hier entstand das Problem aufgrund der Tatsache, dass die Consul-Server auf derselben Hardware wie die Stützpunkte basieren. Dementsprechend wirkt sich jede Belastung aus: Ob es sich um die Belastung von Festplatten oder Prozessoren handelt, sie wirkt sich auch auf die Interaktion mit dem Consul-Cluster aus.

Und wir haben beschlossen, dass es nicht zusammenleben sollte, und haben dem Konsul einen separaten Cluster zugewiesen. Und Patroni arbeitete bereits mit einem separaten Konsul, das heißt, es gab einen separaten Postgres-Cluster, einen separaten Konsul-Cluster. Dies ist eine grundlegende Anleitung zum Tragen und Aufbewahren all dieser Dinge, damit sie nicht zusammenleben.

Optional können Sie die Parameter ttl, loop_wait, retry_timeout verdrehen, d.h. versuchen, diese kurzfristigen Lastspitzen durch Erhöhen dieser Parameter zu überstehen. Dies ist jedoch nicht die geeignetste Option, da diese Belastung lange dauern kann. Und wir werden einfach über diese Grenzen dieser Parameter hinausgehen. Und das hilft vielleicht nicht wirklich.

Das erste Problem ist, wie Sie verstehen, einfach. Wir haben das DCS mit der Basis genommen und zusammengebaut, da ist ein Problem aufgetreten.

Das zweite Problem ähnelt dem ersten. Ähnlich verhält es sich, dass wir erneut Interoperabilitätsprobleme mit dem DCS-System haben.

Wenn wir uns die Protokolle ansehen, werden wir feststellen, dass erneut ein Kommunikationsfehler vorliegt. Und Patroni sagt, ich kann nicht mit DCS interagieren, sodass der aktuelle Master in den Replikatmodus wechselt.

Der Altmeister wird zum Nachbau, hier gelingt Patroni, wie es sein soll. Es führt pg_rewind aus, um das Transaktionsprotokoll zurückzuspulen und dann eine Verbindung zum neuen Master herzustellen, um mit dem neuen Master Schritt zu halten. Hier funktioniert Patroni, wie er sollte.

Hier müssen wir die Stelle finden, die dem Filer vorausging, d. h. die Fehler, die dazu führten, dass wir einen Filer hatten. Und in dieser Hinsicht ist die Arbeit mit Patroni-Protokollen recht praktisch. Er schreibt in bestimmten Abständen die gleichen Nachrichten. Und wenn wir schnell anfangen, durch diese Protokolle zu scrollen, werden wir anhand der Protokolle erkennen, dass sich die Protokolle geändert haben, was bedeutet, dass einige Probleme aufgetreten sind. Wir kehren schnell an diesen Ort zurück und sehen, was passiert.

Und im Normalfall sehen die Protokolle etwa so aus. Der Besitzer des Schlosses wird überprüft. Und wenn beispielsweise der Besitzer gewechselt hat, kann es zu Ereignissen kommen, auf die Patroni reagieren muss. Aber in diesem Fall geht es uns gut. Wir suchen nach dem Ort, an dem die Fehler begannen.

Und nachdem wir bis zu dem Punkt gescrollt haben, an dem die Fehler auftraten, sehen wir, dass es zu einer automatischen Dateiübernahme gekommen ist. Und da unsere Fehler mit der Interaktion mit DCS zusammenhingen und wir in unserem Fall Consul verwendet haben, schauen wir uns auch die Consul-Protokolle an, was dort passiert ist.

Wenn wir die Zeit des Filers und die Zeit in den Consul-Protokollen grob vergleichen, sehen wir, dass unsere Nachbarn im Consul-Cluster begannen, an der Existenz anderer Mitglieder des Consul-Clusters zu zweifeln.

Und wenn man sich auch die Protokolle anderer Consul-Agenten ansieht, kann man auch erkennen, dass dort eine Art Netzwerkzusammenbruch stattfindet. Und alle Mitglieder des Konsul-Clusters zweifeln gegenseitig an der Existenz. Und das war der Anstoß für den Antragsteller.

Wenn Sie sich ansehen, was vor diesen Fehlern passiert ist, können Sie feststellen, dass es alle möglichen Fehler gibt, z. B. Frist oder RPC-Fehler, d. h. es liegt eindeutig ein Problem in der Interaktion der Mitglieder des Consul-Clusters untereinander vor .

Die einfachste Antwort besteht darin, das Netzwerk zu reparieren. Aber wenn ich auf dem Podium stehe, fällt es mir leicht, das zu sagen. Die Umstände sind jedoch so, dass sich der Kunde eine Reparatur des Netzwerks nicht immer leisten kann. Er lebt möglicherweise in einem DC und ist möglicherweise nicht in der Lage, das Netzwerk zu reparieren oder die Ausrüstung zu beeinträchtigen. Daher sind einige andere Optionen erforderlich.

Es gibt Optionen:

• Die einfachste Möglichkeit, die meiner Meinung nach sogar in der Dokumentation geschrieben steht, besteht darin, Consul-Prüfungen zu deaktivieren, also einfach ein leeres Array zu übergeben. Und wir weisen den Konsulagenten an, keine Schecks zu verwenden. Mit diesen Prüfungen können wir diese Netzwerkstürme ignorieren und keinen Filer einleiten.
• Eine andere Möglichkeit besteht darin, „raft_multiplier“ noch einmal zu überprüfen. Dies ist ein Parameter des Consul-Servers selbst. Standardmäßig ist er auf 5 eingestellt. Dieser Wert wird in der Dokumentation für Staging-Umgebungen empfohlen. Tatsächlich wirkt sich dies auf die Häufigkeit der Nachrichtenübermittlung zwischen Mitgliedern des Consul-Netzwerks aus. Tatsächlich beeinflusst dieser Parameter die Geschwindigkeit der Dienstkommunikation zwischen Mitgliedern des Consul-Clusters. Und für die Produktion empfiehlt es sich bereits, diese zu reduzieren, damit die Knoten häufiger Nachrichten austauschen.
• Eine weitere Option, die wir uns ausgedacht haben, besteht darin, die Priorität von Consul-Prozessen gegenüber anderen Prozessen für den Prozessplaner des Betriebssystems zu erhöhen. Es gibt so einen „netten“ Parameter, er bestimmt lediglich die Priorität von Prozessen, die vom Betriebssystem-Scheduler bei der Planung berücksichtigt werden. Wir haben auch den netten Wert für Konsul-Agenten reduziert, d. h. Die Priorität wurde erhöht, sodass das Betriebssystem Consul-Prozessen mehr Zeit zum Arbeiten und Ausführen ihres Codes gibt. In unserem Fall hat dies unser Problem gelöst.
• Eine andere Möglichkeit besteht darin, Consul nicht zu verwenden. Ich habe einen Freund, der ein großer Unterstützer von Etcd ist. Und wir streiten uns regelmäßig mit ihm, was Etcd oder Consul besser ist. Aber in Bezug auf die Frage, was besser ist, stimmen wir normalerweise mit ihm überein, dass Consul über einen Agenten verfügt, der auf jedem Knoten mit einer Datenbank ausgeführt werden sollte. Das heißt, die Interaktion von Patroni mit dem Consul-Cluster erfolgt über diesen Agenten. Und dieser Agent wird zum Flaschenhals. Wenn dem Agenten etwas passiert, kann Patroni nicht mehr mit dem Consul-Cluster zusammenarbeiten. Und das ist das Problem. Im Etcd-Plan ist kein Agent enthalten. Patroni kann direkt mit einer Liste von Etcd-Servern arbeiten und bereits mit diesen kommunizieren. Wenn Sie Etcd in Ihrem Unternehmen verwenden, ist Etcd in dieser Hinsicht wahrscheinlich die bessere Wahl als Consul. Aber wir bei unseren Kunden sind immer durch die Auswahl und Verwendung des Kunden eingeschränkt. Und wir haben größtenteils für alle Kunden einen Konsul.
• Und der letzte Punkt ist die Überarbeitung der Parameterwerte. Wir können diese Parameter erhöhen, in der Hoffnung, dass unsere kurzfristigen Netzwerkprobleme nur von kurzer Dauer sind und nicht außerhalb des Bereichs dieser Parameter liegen. Auf diese Weise können wir die Aggressivität von Patroni bei der automatischen Dateiablage verringern, wenn Netzwerkprobleme auftreten.

Ich denke, dass viele, die Patroni verwenden, mit diesem Befehl vertraut sind.

Dieser Befehl zeigt den aktuellen Status des Clusters an. Und auf den ersten Blick mag dieses Bild normal erscheinen. Wir haben einen Master, wir haben eine Replik, es gibt keine Replikationsverzögerung. Aber dieses Bild ist genau so normal, bis wir wissen, dass dieser Cluster drei Knoten haben sollte, nicht zwei.

Dementsprechend gab es eine Autodatei. Und nach dieser Autodatei verschwand unsere Replik. Wir müssen herausfinden, warum sie verschwunden ist, und sie zurückbringen und wiederherstellen. Und wir gehen noch einmal zu den Protokollen und sehen nach, warum wir eine automatische Dateiübernahme hatten.

In diesem Fall wurde die zweite Replik zum Master. Hier ist alles in Ordnung.

Und wir müssen uns die Replik ansehen, die heruntergefallen ist und sich nicht im Cluster befindet. Wir öffnen die Patroni-Protokolle und sehen, dass beim Herstellen einer Verbindung zum Cluster in der pg_rewind-Phase ein Problem aufgetreten ist. Um eine Verbindung zum Cluster herzustellen, müssen Sie das Transaktionsprotokoll zurückspulen, das erforderliche Transaktionsprotokoll vom Master anfordern und es verwenden, um mit dem Master Schritt zu halten.

In diesem Fall haben wir kein Transaktionsprotokoll und das Replikat kann nicht gestartet werden. Dementsprechend stoppen wir Postgres mit einem Fehler. Und deshalb ist es nicht im Cluster.

Wir müssen verstehen, warum es nicht im Cluster ist und warum es keine Protokolle gab. Wir gehen zum neuen Master und schauen uns an, was er in den Protokollen hat. Es stellte sich heraus, dass beim Ausführen von pg_rewind ein Prüfpunkt aufgetreten ist. Und einige der alten Transaktionsprotokolle wurden einfach umbenannt. Als der alte Master versuchte, eine Verbindung zum neuen Master herzustellen und diese Protokolle abzufragen, waren sie bereits umbenannt, sie existierten einfach nicht.

Ich habe die Zeitstempel verglichen, als diese Ereignisse passierten. Und dort beträgt der Unterschied buchstäblich 150 Millisekunden, das heißt, der Checkpoint war in 369 Millisekunden abgeschlossen, die WAL-Segmente wurden umbenannt. Und buchstäblich im Jahr 517, nach 150 Millisekunden, begann der Rücklauf bei der alten Replik. Das heißt, buchstäblich 150 Millisekunden reichten für uns aus, damit die Replik keine Verbindung herstellen und verdienen konnte.

Was sind die Möglichkeiten?

Wir haben zunächst Replikationsslots verwendet. Wir fanden es gut. Obwohl wir in der ersten Betriebsphase die Slots ausgeschaltet haben. Es schien uns, dass wir den Master fallen lassen können, wenn die Slots viele WAL-Segmente ansammeln. Er wird fallen. Wir haben einige Zeit ohne Slots gelitten. Und uns wurde klar, dass wir Slots brauchen, wir haben die Slots zurückgegeben.

Hier gibt es jedoch ein Problem: Wenn der Master zum Replikat geht, löscht er die Slots und löscht die WAL-Segmente zusammen mit den Slots. Und um dieses Problem zu beseitigen, haben wir beschlossen, den Parameter wal_keep_segments zu erhöhen. Der Standardwert beträgt 8 Segmente. Wir haben es auf 1 erhöht und geschaut, wie viel freien Speicherplatz wir hatten. Und wir haben 000 Gigabyte für wal_keep_segments gespendet. Das heißt, wir haben beim Wechsel immer eine Reserve von 16 Gigabyte an Transaktionsprotokollen auf allen Knoten.

Und außerdem ist es für langfristige Wartungsaufgaben immer noch relevant. Nehmen wir an, wir müssen eines der Replikate aktualisieren. Und wir wollen es ausschalten. Wir müssen die Software aktualisieren, vielleicht das Betriebssystem, etwas anderes. Und wenn wir ein Replikat ausschalten, wird auch der Steckplatz für dieses Replikat entfernt. Und wenn wir ein kleines wal_keep_segments verwenden, gehen die Transaktionsprotokolle bei längerem Fehlen eines Replikats verloren. Wir werden ein Replikat erstellen, das die Transaktionsprotokolle anfordert, bei denen es aufgehört hat, diese befinden sich jedoch möglicherweise nicht auf dem Master. Und das Replikat wird auch keine Verbindung herstellen können. Deshalb führen wir einen großen Vorrat an Zeitschriften.

Wir haben eine Produktionsbasis. Es sind bereits Projekte in Bearbeitung.

Es gab einen Filer. Wir gingen hinein und schauten – alles ist in Ordnung, die Replikate sind vorhanden, es gibt keine Replikationsverzögerung. Auch in den Protokollen sind keine Fehler zu finden, alles ist in Ordnung.

Das Produktteam sagt, dass es einige Daten geben sollte, aber wir sehen sie aus einer Quelle, aber wir sehen sie nicht in der Datenbank. Und wir müssen verstehen, was mit ihnen passiert ist.

Es ist klar, dass pg_rewind sie übersehen hat. Wir haben das sofort verstanden, sind aber hingegangen, um zu sehen, was los ist.

In den Protokollen können wir immer herausfinden, wann der Filer aufgetreten ist, wer der Master wurde, und wir können feststellen, wer der alte Master war und wann er ein Replikat werden wollte, d. h. wir benötigen diese Protokolle, um herauszufinden, wie viele Transaktionsprotokolle es gibt war verloren.

Unser alter Meister hat neu gestartet. Und Patroni wurde im Autorun registriert. Patroni ins Leben gerufen. Anschließend startete er Postgres. Genauer gesagt startete Patroni vor dem Start von Postgres und vor der Erstellung einer Replik den pg_rewind-Prozess. Dementsprechend löschte er einen Teil der Transaktionsprotokolle, lud neue herunter und stellte eine Verbindung her. Hier hat Patroni klug gearbeitet, also wie erwartet. Der Cluster wurde wiederhergestellt. Wir hatten 3 Knoten, nach dem Filer 3 Knoten – alles ist cool.

Wir haben einige Daten verloren. Und wir müssen verstehen, wie viel wir verloren haben. Wir suchen genau den Moment, in dem wir zurückspulen konnten. Wir können es in solchen Tagebucheinträgen finden. Der Rücklauf begann, tat dort etwas und endete.

Wir müssen die Position im Transaktionsprotokoll finden, an der der alte Master aufgehört hat. In diesem Fall ist dies die Markierung. Und wir brauchen eine zweite Markierung, nämlich den Abstand, um den sich der alte Meister vom neuen unterscheidet.

Wir nehmen das übliche pg_wal_lsn_diff und vergleichen diese beiden Markierungen. Und in diesem Fall erhalten wir 17 Megabyte. Viel oder wenig, das entscheidet jeder für sich. Denn für jemanden sind 17 Megabyte nicht viel, für jemanden ist es viel und inakzeptabel. Dabei bestimmt jeder individuell nach den Bedürfnissen des Unternehmens.

Aber was haben wir selbst herausgefunden?

Zuerst müssen wir selbst entscheiden: Brauchen wir Patroni immer, um nach einem Systemneustart automatisch zu starten? Es kommt oft vor, dass wir zum alten Meister gehen müssen, um zu sehen, wie weit er gegangen ist. Überprüfen Sie möglicherweise Segmente des Transaktionsprotokolls und sehen Sie, was dort steht. Und um zu verstehen, ob wir diese Daten verlieren können oder ob wir den alten Master im Standalone-Modus ausführen müssen, um diese Daten abzurufen.

Und erst danach müssen wir entscheiden, ob wir diese Daten verwerfen oder wiederherstellen können, indem wir diesen Knoten als Replikat mit unserem Cluster verbinden.

Darüber hinaus gibt es einen Parameter „maximum_lag_on_failover“. Wenn mein Speicher reicht, hat dieser Parameter standardmäßig einen Wert von 1 Megabyte.

Wie funktioniert er? Liegt unser Replikat in der Replikationsverzögerung um 1 Megabyte an Daten zurück, dann nimmt dieses Replikat nicht an den Wahlen teil. Und wenn es plötzlich zu einem Fileover kommt, schaut Patroni, welche Replikate hinterherhinken. Wenn sie eine große Anzahl von Transaktionsprotokollen hinter sich haben, können sie nicht zum Master werden. Dies ist eine sehr gute Sicherheitsfunktion, die verhindert, dass Sie viele Daten verlieren.

Es besteht jedoch ein Problem darin, dass die Replikationsverzögerung im Patroni-Cluster und DCS in einem bestimmten Intervall aktualisiert wird. Ich denke, 30 Sekunden ist der Standard-TTL-Wert.

Dementsprechend kann es vorkommen, dass es eine Replikationsverzögerung für Replikate in DCS gibt, tatsächlich aber eine völlig andere Verzögerung oder überhaupt keine Verzögerung vorliegt, d. h. die Sache ist nicht in Echtzeit. Und es spiegelt nicht immer das wahre Bild wider. Und es lohnt sich nicht, dabei eine ausgefallene Logik anzustellen.

Und das Verlustrisiko bleibt immer bestehen. Und im schlimmsten Fall eine Formel und im Durchschnitt eine andere Formel. Das heißt, wenn wir die Implementierung von Patroni planen und bewerten, wie viele Daten wir verlieren können, müssen wir uns auf diese Formeln verlassen und uns grob vorstellen, wie viele Daten wir verlieren können.

Und es gibt gute Nachrichten. Wenn der Altmeister weitergemacht hat, kann er aufgrund einiger Hintergrundprozesse weitermachen. Das heißt, es gab eine Art Autovakuum, er schrieb die Daten und speicherte sie im Transaktionsprotokoll. Und wir können diese Daten leicht ignorieren und verlieren. Das ist kein Problem.

Und so sehen die Protokolle aus, wenn „maximum_lag_on_failover“ festgelegt ist, ein Filer aufgetreten ist und Sie einen neuen Master auswählen müssen. Die Replik schätzt sich als unfähig ein, an den Wahlen teilzunehmen. Und sie weigert sich, am Rennen um den Spitzenreiter teilzunehmen. Und sie wartet darauf, dass ein neuer Master ausgewählt wird, damit sie sich dann mit diesem verbinden kann. Dies ist eine zusätzliche Maßnahme gegen Datenverlust.

Hier haben wir ein Produktteam, das geschrieben hat, dass sein Produkt Probleme mit Postgres hat. Gleichzeitig ist der Master selbst nicht erreichbar, da dieser nicht über SSH erreichbar ist. Und das Autofile passiert auch nicht.

Dieser Host musste neu starten. Aufgrund des Neustarts kam es zu einer automatischen Dateierstellung, obwohl es, wie ich jetzt weiß, möglich war, eine manuelle automatische Dateierstellung durchzuführen. Und nach dem Neustart werden wir bereits sehen, was wir mit dem aktuellen Master hatten.

Gleichzeitig wussten wir im Voraus, dass wir Probleme mit Festplatten hatten, das heißt, wir wussten bereits durch die Überwachung, wo wir graben und wonach wir suchen mussten.

Wir gingen in das Postgres-Protokoll und begannen zu sehen, was dort passierte. Wir haben Commits gesehen, die dort eine, zwei, drei Sekunden dauern, was überhaupt nicht normal ist. Wir haben gesehen, dass unser Autovakuum sehr langsam und seltsam startet. Und wir haben temporäre Dateien auf der Festplatte gesehen. Das heißt, dies sind alles Indikatoren für Probleme mit Festplatten.

Wir haben uns das System-Dmesg (Kernel-Protokoll) angesehen. Und wir haben gesehen, dass wir Probleme mit einer der Festplatten haben. Das Festplattensubsystem war Software Raid. Wir haben uns /proc/mdstat angesehen und festgestellt, dass uns ein Laufwerk fehlte. Das heißt, es gibt einen Raid mit 8 Festplatten, uns fehlt eine. Wenn Sie sich die Folie genau ansehen, können Sie in der Ausgabe sehen, dass wir dort kein SDE haben. Bei uns ist bedingt gesehen die Diskette ausgefallen. Dies führte zu Festplattenproblemen und auch bei der Arbeit mit dem Postgres-Cluster traten bei Anwendungen Probleme auf.

Und in diesem Fall würde uns Patroni in keiner Weise helfen, da Patroni nicht die Aufgabe hat, den Zustand des Servers, den Zustand der Festplatte, zu überwachen. Und wir müssen solche Situationen durch externe Überwachung überwachen. Wir haben die Festplattenüberwachung schnell zur externen Überwachung hinzugefügt.

Und da kam so ein Gedanke: Könnte uns eine Zaun- oder Überwachungssoftware helfen? Wir dachten, dass er uns in diesem Fall kaum geholfen hätte, da Patroni während der Probleme weiterhin mit dem DCS-Cluster interagierte und kein Problem sah. Das heißt, aus Sicht von DCS und Patroni war mit dem Cluster alles in Ordnung, obwohl es tatsächlich Probleme mit der Festplatte gab, gab es Probleme mit der Verfügbarkeit der Datenbank.

Meiner Meinung nach ist dies eines der seltsamsten Probleme, mit denen ich seit langem recherchiere. Ich habe viele Protokolle gelesen, sie erneut ausgewählt und als Cluster-Simulator bezeichnet.

Das Problem war, dass der alte Master kein normales Replikat werden konnte, d.h. Patroni startete es, Patroni zeigte, dass dieser Knoten als Replik vorhanden war, aber gleichzeitig war es kein normales Replikat. Jetzt werden Sie sehen, warum. Das ist es, was ich aus der Analyse dieses Problems herausgehalten habe.

Und wie hat alles angefangen? Es begann, wie beim vorherigen Problem, mit Scheibenbremsen. Wir hatten Commits für eine Sekunde, zwei.

Es kam zu Verbindungsabbrüchen, d.h. Kunden wurden abgerissen.

Es kam zu Verstopfungen unterschiedlicher Schwere.

Und dementsprechend reagiert das Festplattensubsystem nicht sehr schnell.

Und das Mysteriöseste für mich ist die sofortige Aufforderung zur Abschaltung, die eintraf. Postgres verfügt über drei Abschaltmodi:

• Es ist angenehm, wenn wir darauf warten, dass alle Clients von selbst die Verbindung trennen.
• Es kommt schnell vor, dass wir Clients dazu zwingen, die Verbindung zu trennen, weil wir sie herunterfahren müssen.
• Und zwar sofort. In diesem Fall werden die Clients bei der Funktion „Immediate“ nicht einmal zum Herunterfahren aufgefordert, sondern einfach ohne Vorwarnung heruntergefahren. Und an alle Clients sendet das Betriebssystem bereits eine RST-Nachricht (eine TCP-Nachricht, dass die Verbindung unterbrochen ist und der Client nichts mehr abzufangen hat).

Wer hat dieses Signal gesendet? Postgres-Hintergrundprozesse senden solche Signale nicht untereinander, d. h. dies ist Kill-9. Sie senden sich solche Dinge nicht gegenseitig, sie reagieren nur auf solche Dinge, d. h. dies ist ein Notfall-Neustart von Postgres. Wer es geschickt hat, weiß ich nicht.

Ich habe mir den „letzten“ Befehl angesehen und eine Person gesehen, die sich ebenfalls bei diesem Server bei uns angemeldet hat, aber ich war zu schüchtern, um eine Frage zu stellen. Vielleicht war es kill -9. Ich würde kill -9 in den Protokollen sehen, weil Postgres sagt, dass es kill -9 brauchte, aber ich habe es nicht in den Protokollen gesehen.

Als ich weiter schaute, sah ich, dass Patroni ziemlich lange nicht in das Protokoll schrieb – 54 Sekunden. Und wenn wir zwei Zeitstempel vergleichen, gab es etwa 54 Sekunden lang keine Nachrichten.

Und während dieser Zeit gab es eine Autodatei. Patroni hat auch hier wieder einen tollen Job gemacht. Unser alter Herr war nicht erreichbar, ihm ist etwas passiert. Und die Wahl eines neuen Meisters begann. Hier hat alles gut geklappt. Unser pgsql01 ist der neue Anführer geworden.

Wir haben eine Replik, die zum Meister geworden ist. Und es gibt eine zweite Antwort. Und beim zweiten Nachbau gab es Probleme. Sie versuchte, sich neu zu konfigurieren. Soweit ich weiß, hat sie versucht, die Datei „recovery.conf“ zu ändern, Postgres neu zu starten und eine Verbindung zum neuen Master herzustellen. Sie schreibt alle 10 Sekunden Nachrichten, die sie versucht, aber es gelingt ihr nicht.

Und bei diesen Versuchen kommt beim Altmaster ein Sofort-Abschaltsignal an. Der Master wird neu gestartet. Und auch die Wiederherstellung stoppt, weil der alte Master einen Neustart durchführt. Das heißt, das Replikat kann keine Verbindung herstellen, da es sich im Shutdown-Modus befindet.

Irgendwann funktionierte es, aber die Replikation startete nicht.

Meine einzige Vermutung ist, dass es in der Datei „recovery.conf“ eine alte Master-Adresse gab. Und als ein neuer Master erschien, versuchte die zweite Replik immer noch, eine Verbindung zum alten Master herzustellen.

Als Patroni auf dem zweiten Replikat startete, startete der Knoten, konnte aber nicht replizieren. Und es entstand eine Replikationsverzögerung, die in etwa so aussah. Das heißt, alle drei Knoten waren vorhanden, der zweite Knoten blieb jedoch zurück.

Wenn Sie sich gleichzeitig die geschriebenen Protokolle ansehen, können Sie feststellen, dass die Replikation nicht gestartet werden konnte, weil die Transaktionsprotokolle unterschiedlich waren. Und die Transaktionsprotokolle, die der Master anbietet und die in der Recovery.conf angegeben sind, passen einfach nicht zu unserem aktuellen Knoten.

Und hier habe ich einen Fehler gemacht. Ich musste vorbeikommen und nachsehen, was in der Datei „recovery.conf“ stand, um meine Hypothese zu testen, dass wir uns mit dem falschen Master verbunden hatten. Aber dann habe ich mich gerade damit befasst und es ist mir nicht in den Sinn gekommen, oder ich habe gesehen, dass die Nachbildung hinterherhinkt und nachgefüllt werden muss, das heißt, ich habe irgendwie nachlässig gearbeitet. Das war mein Joint.

Nach 30 Minuten kam bereits der Admin, d.h. ich habe Patroni auf der Replika neu gestartet. Ich habe es schon aufgegeben, ich dachte, es müsste wieder aufgefüllt werden. Und ich dachte - ich werde Patroni neu starten, vielleicht wird etwas Gutes dabei herauskommen. Die Wiederherstellung hat begonnen. Und die Basis öffnete sich sogar, sie war bereit, Verbindungen aufzunehmen.

Die Replikation wurde gestartet. Doch eine Minute später brach sie mit der Fehlermeldung ab, dass Transaktionsprotokolle für sie nicht geeignet seien.

Ich dachte, ich würde noch einmal von vorne beginnen. Ich habe Patroni erneut gestartet, und ich habe Postgres nicht neu gestartet, sondern Patroni in der Hoffnung, dass es die Datenbank auf magische Weise starten würde.

Die Replikation wurde erneut gestartet, aber die Markierungen im Transaktionsprotokoll waren anders, sie waren nicht dieselben wie beim vorherigen Startversuch. Die Replikation wurde erneut gestoppt. Und die Botschaft war schon etwas anders. Und es war für mich nicht sehr informativ.

Und dann fällt mir ein: Was wäre, wenn ich Postgres neu starte und zu diesem Zeitpunkt einen Prüfpunkt auf dem aktuellen Master erstelle, um den Punkt im Transaktionsprotokoll ein wenig nach vorne zu verschieben, damit die Wiederherstellung zu einem anderen Zeitpunkt beginnt? Außerdem hatten wir noch WAL-Vorräte.

Ich habe Patroni neu gestartet, ein paar Kontrollpunkte auf dem Master und ein paar Neustartpunkte auf dem Replikat durchgeführt, als es geöffnet wurde. Und es hat geholfen. Ich habe lange darüber nachgedacht, warum es hilft und wie es funktioniert. Und die Replik begann. Und die Replikation war nicht mehr zerrissen.

Ein solches Problem ist für mich eines der mysteriöseren, bei dem ich immer noch darüber rätsele, was dort wirklich passiert ist.

Was sind hier die Implikationen? Patroni kann wie vorgesehen und fehlerfrei arbeiten. Aber gleichzeitig ist dies keine hundertprozentige Garantie dafür, dass bei uns alles in Ordnung ist. Das Replikat wird möglicherweise gestartet, befindet sich jedoch möglicherweise in einem halb funktionsfähigen Zustand, und die Anwendung kann mit einem solchen Replikat nicht arbeiten, da alte Daten vorhanden sind.

Und nach dem Filer müssen Sie immer überprüfen, ob mit dem Cluster alles in Ordnung ist, das heißt, ob die erforderliche Anzahl von Replikaten vorhanden ist und keine Replikationsverzögerung auftritt.

Und während wir uns mit diesen Themen befassen, werde ich Empfehlungen aussprechen. Ich habe versucht, sie in zwei Folien zu kombinieren. Wahrscheinlich könnten alle Geschichten in zwei Folien zusammengefasst und nur erzählt werden.

Wenn Sie Patroni verwenden, müssen Sie über eine Überwachung verfügen. Sie sollten immer wissen, wann ein Autofileover stattgefunden hat, denn wenn Sie nicht wissen, dass ein Autofileover stattgefunden hat, haben Sie keine Kontrolle über den Cluster. Und das ist schlecht.

Nach jedem Filer müssen wir den Cluster immer manuell überprüfen. Wir müssen sicherstellen, dass wir immer über eine aktuelle Anzahl von Replikaten verfügen, dass es keine Replikationsverzögerungen gibt und dass es keine Fehler in den Protokollen im Zusammenhang mit der Streaming-Replikation, mit Patroni und dem DCS-System gibt.

Automatisierung kann erfolgreich funktionieren, Patroni ist ein sehr gutes Werkzeug. Es kann funktionieren, aber dadurch wird der Cluster nicht in den gewünschten Zustand gebracht. Und wenn wir es nicht herausfinden, geraten wir in Schwierigkeiten.

Und Patroni ist kein Allheilmittel. Wir müssen noch verstehen, wie Postgres funktioniert, wie die Replikation funktioniert und wie Patroni mit Postgres funktioniert und wie die Kommunikation zwischen Knoten bereitgestellt wird. Dies ist notwendig, um Probleme mit den Händen beheben zu können.

Wie gehe ich an die Frage der Diagnose heran? Es kam vor, dass wir mit verschiedenen Clients arbeiten und niemand über einen ELK-Stack verfügt und wir die Protokolle sortieren müssen, indem wir 6 Konsolen und 2 Registerkarten öffnen. Auf einer Registerkarte sind dies die Patroni-Protokolle für jeden Knoten, auf der anderen Registerkarte sind dies die Consul-Protokolle oder bei Bedarf Postgres. Es ist sehr schwierig, dies zu diagnostizieren.

Welche Ansätze habe ich entwickelt? Zuerst schaue ich immer, wenn der Filer angekommen ist. Und für mich ist das ein Wendepunkt. Ich schaue mir an, was vor dem Filer, während des Filers und nach dem Filer passiert ist. Das Fileover hat zwei Markierungen: Dies ist die Start- und Endzeit.

Als nächstes suche ich in den Protokollen nach Ereignissen vor dem Filer, die dem Filer vorausgingen, d. h. ich suche nach den Gründen, warum der Filer passiert ist.

Und dies vermittelt ein Bild davon, was passiert ist und was in Zukunft getan werden kann, damit solche Umstände nicht eintreten (und es daher keinen Filer gibt).

Und wo suchen wir normalerweise? Ich schaue:

• Zunächst zu den Patroni-Protokollen.
• Als nächstes schaue ich mir die Postgres-Protokolle oder die DCS-Protokolle an, je nachdem, was in den Patroni-Protokollen gefunden wurde.
• Und die Systemprotokolle geben manchmal auch Aufschluss darüber, was den Filer verursacht hat.

Was denke ich über Patroni? Ich habe ein sehr gutes Verhältnis zu Patroni. Meiner Meinung nach ist das das Beste, was es heute gibt. Ich kenne viele andere Produkte. Dies sind Stolon, Repmgr, Pg_auto_failover, PAF. 4 Werkzeuge. Ich habe sie alle ausprobiert. Patroni ist mein Favorit.

Wenn sie mich fragen: „Kann ich Patroni empfehlen?“ Ich sage ja, weil ich Patroni mag. Und ich glaube, ich habe gelernt, wie man es kocht.

Wenn Sie wissen möchten, welche anderen Probleme es mit Patroni neben den von mir genannten Problemen gibt, können Sie jederzeit einen Blick auf die Seite werfen Probleme auf GitHub. Es gibt viele verschiedene Geschichten und viele interessante Themen werden dort besprochen. Infolgedessen wurden einige Fehler eingeführt und behoben, das heißt, dies ist eine interessante Lektüre.

Es gibt einige interessante Geschichten über Menschen, die sich selbst ins Bein schießen. Sehr informativ. Sie haben gelesen und verstanden, dass dies nicht erforderlich ist. Ich habe mich selbst getickt.

Und ich möchte mich ganz herzlich bei Zalando für die Entwicklung dieses Projekts bedanken, nämlich bei Alexander Kukushkin und Alexey Klyukin. Aleksey Klyukin ist einer der Co-Autoren, er arbeitet nicht mehr bei Zalando, aber das sind zwei Leute, die angefangen haben, mit diesem Produkt zu arbeiten.

Und ich finde, dass Patroni eine sehr coole Sache ist. Ich bin froh, dass es sie gibt, es ist interessant mit ihr. Und ein großes Dankeschön an alle Mitwirkenden, die Patroni Patches schreiben. Ich hoffe, dass Patroni mit zunehmendem Alter reifer, cooler und leistungsfähiger wird. Es ist bereits funktionsfähig, aber ich hoffe, dass es noch besser wird. Wenn Sie also planen, Patroni zu verwenden, dann haben Sie keine Angst. Das ist eine gute Lösung, sie lässt sich umsetzen und nutzen.

Das ist alles. Wenn Sie Fragen haben, fragen Sie.

Fragen

Danke für den Bericht! Wenn man nach einem Filer noch sehr genau hinschauen muss, wozu braucht man dann einen automatischen Filer?

Weil es neues Zeug ist. Wir sind erst seit einem Jahr bei ihr. Es ist besser, auf Nummer sicher zu gehen. Wir wollen vorbeikommen und sehen, dass wirklich alles so geklappt hat, wie es sollte. Dies ist der Grad des Misstrauens von Erwachsenen – es ist besser, es noch einmal zu überprüfen und zu sehen.

Wir sind zum Beispiel morgens hingegangen und haben nachgeschaut, oder?

Nicht morgens, wir erfahren normalerweise fast sofort von der Autodatei. Wir erhalten Benachrichtigungen und sehen, dass eine Autodatei aufgetreten ist. Wir gehen fast sofort hin und schauen. Aber alle diese Kontrollen sollten auf die Überwachungsebene gebracht werden. Wenn Sie über die REST-API auf Patroni zugreifen, gibt es eine Historie. Im Verlauf können Sie die Zeitstempel sehen, wann der Filer aufgetreten ist. Auf dieser Grundlage kann eine Überwachung erfolgen. Sie können die Geschichte sehen, wie viele Ereignisse es gab. Wenn wir mehr Ereignisse haben, ist eine Autodatei aufgetreten. Sie können hingehen und sehen. Oder unsere Überwachungsautomatisierung hat überprüft, ob alle Replikate vorhanden sind, es keine Verzögerungen gibt und alles in Ordnung ist.

Vielen Dank!

Vielen Dank für die tolle Geschichte! Wenn wir den DCS-Cluster irgendwo weit weg vom Postgres-Cluster verschoben haben, muss dieser Cluster dann auch regelmäßig gewartet werden? Was sind die Best Practices dafür, dass einige Teile des DCS-Clusters ausgeschaltet werden müssen, was damit zu tun ist usw.? Wie überlebt diese ganze Struktur? Und wie macht man diese Dinge?

Für ein Unternehmen war es notwendig, eine Problemmatrix zu erstellen, was passiert, wenn eine der Komponenten oder mehrere Komponenten ausfallen. Gemäß dieser Matrix gehen wir nacheinander alle Komponenten durch und erstellen Szenarien für den Fall eines Ausfalls dieser Komponenten. Dementsprechend können Sie für jedes Fehlerszenario einen Aktionsplan zur Wiederherstellung erstellen. Und im Fall von DCS ist es Teil der Standardinfrastruktur. Und der Administrator verwaltet es, und wir verlassen uns bereits auf die Administratoren, die es verwalten, und auf ihre Fähigkeit, es bei Unfällen zu beheben. Wenn überhaupt kein DCS vorhanden ist, stellen wir es bereit, überwachen es aber gleichzeitig nicht besonders, da wir nicht für die Infrastruktur verantwortlich sind, sondern geben Empfehlungen, wie und was überwacht werden soll.

Das heißt, habe ich richtig verstanden, dass ich Patroni, den Filer und alles deaktivieren muss, bevor ich etwas mit den Hosts mache?

Es hängt davon ab, wie viele Knoten wir im DCS-Cluster haben. Wenn es viele Knoten gibt und wir nur einen der Knoten (das Replikat) deaktivieren, behält der Cluster ein Quorum bei. Und Patroni bleibt einsatzbereit. Und es wird nichts ausgelöst. Wenn wir einige komplexe Vorgänge haben, die mehr Knoten betreffen und deren Fehlen das Quorum ruinieren kann, dann – ja, es könnte sinnvoll sein, Patroni auf Pause zu setzen. Es gibt einen entsprechenden Befehl: Patronictl Pause, Patronictl Resume. Wir machen einfach eine Pause und der Autofiler funktioniert zu diesem Zeitpunkt nicht. Wir führen Wartungsarbeiten am DCS-Cluster durch, beenden dann die Pause und leben weiter.

Vielen Dank!

Vielen Dank für deinen Bericht! Wie steht das Produktteam zum Datenverlust?

Den Produktteams ist das egal und die Teamleiter sind besorgt.

Welche Garantien gibt es?

Garantien sind sehr schwierig. Alexander Kukushkin hat einen Bericht mit dem Titel „Wie man RPO und RTO berechnet“, also die Wiederherstellungszeit und wie viele Daten wir verlieren können. Ich denke, wir müssen diese Folien finden und studieren. Soweit ich mich erinnere, gibt es bestimmte Schritte zur Berechnung dieser Dinge. Wie viele Transaktionen können wir verlieren, wie viele Daten können wir verlieren. Als Option können wir die synchrone Replikation auf Patroni-Ebene verwenden, aber das ist ein zweischneidiges Schwert: Entweder haben wir die Datenzuverlässigkeit oder wir verlieren an Geschwindigkeit. Es gibt eine synchrone Replikation, die jedoch keinen hundertprozentigen Schutz vor Datenverlust gewährleistet.

Alexey, danke für den tollen Bericht! Gibt es Erfahrungen mit der Verwendung von Patroni für den Zero-Level-Schutz? Das heißt, in Verbindung mit synchronem Standby? Dies ist die erste Frage. Und die zweite Frage. Sie haben unterschiedliche Lösungen verwendet. Wir haben Repmgr verwendet, jedoch ohne Autofiler, und jetzt planen wir, Autofiler einzubinden. Und wir betrachten Patroni als alternative Lösung. Welche Vorteile können Sie gegenüber Repmgr nennen?

Die erste Frage betraf synchrone Replikate. Niemand verwendet hier die synchrone Replikation, weil alle Angst haben (Mehrere Clients verwenden sie bereits, im Prinzip haben sie keine Leistungsprobleme bemerkt - Anmerkung des Redners). Aber wir haben für uns die Regel entwickelt, dass es in einem synchronen Replikationscluster mindestens drei Knoten geben sollte, denn wenn wir zwei Knoten haben und der Master oder das Replikat ausfällt, dann schaltet Patroni diesen Knoten in den Standalone-Modus, damit die Anwendung weiterläuft arbeiten. In diesem Fall besteht die Gefahr eines Datenverlustes.

Was die zweite Frage betrifft, haben wir Repmgr verwendet und tun dies aus historischen Gründen immer noch bei einigen Clients. Was kann man sagen? Patroni verfügt standardmäßig über einen Autofiler, Repmgr verfügt über einen Autofiler als zusätzliche Funktion, die aktiviert werden muss. Wir müssen den Repmgr-Daemon auf jedem Knoten ausführen und können dann den Autofiler konfigurieren.

Repmgr prüft, ob Postgres-Knoten aktiv sind. Repmgr-Prozesse prüfen, ob einander vorhanden ist. Dies ist kein sehr effizienter Ansatz. Es kann komplexe Fälle von Netzwerkisolation geben, bei denen ein großer Repmgr-Cluster in mehrere kleinere zerfallen und weiterarbeiten kann. Ich verfolge Repmgr schon lange nicht mehr, vielleicht wurde es behoben ... oder vielleicht auch nicht. Aber die Entfernung von Informationen über den Status des Clusters in DCS, wie Stolon und Patroni es tun, ist die praktikabelste Option.

Alexey, ich habe eine Frage, vielleicht eine eher langweilige. In einem der ersten Beispiele haben Sie DCS vom lokalen Computer auf einen Remote-Host verschoben. Wir verstehen, dass das Netzwerk etwas ist, das seine eigenen Eigenschaften hat und für sich selbst lebt. Und was passiert, wenn der DCS-Cluster aus irgendeinem Grund nicht verfügbar ist? Ich werde die Gründe nicht nennen, es kann viele davon geben: von den krummen Händen der Netzwerker bis hin zu echten Problemen.

Ich habe es nicht laut gesagt, aber der DCS-Cluster muss auch ein Failover sein, d. h. es handelt sich um eine ungerade Anzahl von Knoten, damit ein Quorum erreicht wird. Was passiert, wenn der DCS-Cluster nicht verfügbar ist oder ein Quorum nicht erreicht werden kann, d. h. es kommt zu einer Netzwerkaufteilung oder einem Knotenausfall? In diesem Fall wechselt der Patroni-Cluster in den schreibgeschützten Modus. Der Patroni-Cluster kann den Status des Clusters und die zu tunden Maßnahmen nicht ermitteln. Es kann keine Verbindung zum DCS herstellen und dort den neuen Clusterstatus speichern, sodass der gesamte Cluster in den schreibgeschützten Zustand wechselt. Und wartet entweder auf den manuellen Eingriff des Bedieners oder auf die Wiederherstellung des DCS.

Grob gesagt wird DCS für uns zu einem Dienst, der genauso wichtig ist wie die Basis selbst?

Ja Ja. In so vielen modernen Unternehmen ist Service Discovery ein integraler Bestandteil der Infrastruktur. Die Implementierung erfolgt bereits, bevor es überhaupt eine Datenbank in der Infrastruktur gab. Relativ gesehen wurde die Infrastruktur gestartet, im DC bereitgestellt und wir haben sofort Service Discovery. Wenn es Consul ist, kann DNS darauf aufgebaut werden. Wenn es sich um Etcd handelt, gibt es möglicherweise einen Teil des Kubernetes-Clusters, in dem alles andere bereitgestellt wird. Mir scheint, dass Service Discovery bereits ein fester Bestandteil moderner Infrastrukturen ist. Und sie denken viel früher darüber nach als über Datenbanken.

Vielen Dank!

Source: habr.com