{"id":90103,"date":"2020-07-29T13:42:32","date_gmt":"2020-07-29T11:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij"},"modified":"2020-07-29T13:42:32","modified_gmt":"2020-07-29T11:42:32","slug":"patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij","title":{"rendered":"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/6404cba13214f499d1f347cca0aacbe7.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Das Hauptziel von Patroni ist die Gew\u00e4hrleistung der Hochverf\u00fcgbarkeit f\u00fcr PostgreSQL. Aber Patroni ist nur eine Vorlage und kein fertiges Werkzeug (was in der Dokumentation auch erw\u00e4hnt wird). Auf den ersten Blick mag es so erscheinen, als sei Patroni in einer Testumgebung ein hervorragendes Werkzeug, das unsere Versuche, den Cluster zu zerst\u00f6ren, m\u00fchelos verarbeitet. Doch in der Praxis, in einer Produktionsumgebung, l\u00e4uft nicht immer alles so glatt und elegant wie im Testlabor.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/ff445e6d76a2ad46a232b705e104446f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ein bisschen \u00fcber mich: Ich habe als Systemadministrator angefangen. Ich habe in der Webentwicklung gearbeitet. Seit 2014 bin ich bei Data Egret t\u00e4tig. Das Unternehmen besch\u00e4ftigt sich mit Beratung im Bereich PostgreSQL. Wir betreuen ausschlie\u00dflich PostgreSQL und arbeiten jeden Tag damit, weshalb wir \u00fcber umfangreiche Expertise im Betrieb verf\u00fcgen. <\/p>\n<p><\/p>\n<p>Ende 2018 haben wir begonnen, Patroni schrittweise einzusetzen. Und es hat sich eine bestimmte Erfahrung angesammelt. Wir haben es diagnostiziert, optimiert und sind zu unseren Best Practices gelangt. In diesem Vortrag werde ich dar\u00fcber berichten.<\/p>\n<p><\/p>\n<p>Neben Postgres liebe ich Linux. Ich besch\u00e4ftige mich gerne damit, erkunde es und baue Kerne zusammen. Virtualisierung, Container, Docker, Kubernetes \u2013 das alles interessiert mich, denn es spiegelt meine alten Admin-Gewohnheiten wider. Ich besch\u00e4ftige mich auch gerne mit Monitoring-Systemen. Zudem liebe ich alles, was mit der Verwaltung von Postgres zu tun hat, d.h. Replikation, Backup. In meiner Freizeit programmiere ich in Go. Ich bin kein Software Engineer, programmiere einfach nur f\u00fcr mich selbst in Go. Es macht mir Freude. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/02cfd9293af5a8410c91e39afe2c75e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Ich denke, viele von Ihnen wissen, dass Postgres standardm\u00e4\u00dfig kein HA (High Availability) bietet. Um HA zu erhalten, muss man etwas installieren, einrichten und Aufwand betreiben, um es zu bekommen. <\/li>\n<li>Es gibt mehrere Werkzeuge und eines davon ist Patroni, das HA ziemlich gut und effektiv l\u00f6st. Wenn wir dies alles in einer Testumgebung installieren und starten, k\u00f6nnen wir sehen, dass es alles funktioniert. Wir k\u00f6nnen Probleme nachstellen und beobachten, wie Patroni damit umgeht. Und wir werden sehen, dass alles hervorragend funktioniert. <\/li>\n<li>Aber in der Praxis sind wir auf verschiedene Probleme gesto\u00dfen. Und \u00fcber diese Probleme werde ich berichten.<\/li>\n<li>Ich werde erz\u00e4hlen, wie wir diese diagnostiziert haben, was wir angepasst haben \u2013 ob es uns geholfen hat oder nicht. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/7126b45b40dd08521e80a3c150382bec.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Ich werde nicht erkl\u00e4ren, wie man Patroni installiert, denn das kann man leicht online finden. Man kann die Konfigurationsdateien einsehen, um zu verstehen, wie alles gestartet und konfiguriert wird. Es ist m\u00f6glich, sich in die Schemen und Architekturen einzuarbeiten, indem man diesbez\u00fcglich Informationen im Internet sucht. <\/li>\n<li>Ich werde nicht \u00fcber die Erfahrungen anderer sprechen. Ich teile nur die Probleme, mit denen wir konkret konfrontiert waren. <\/li>\n<li>Ich werde auch nicht \u00fcber Probleme au\u00dferhalb von Patroni und PostgreSQL berichten. Wenn es beispielsweise um Probleme mit der Lastverteilung geht, als unser Cluster scheiterte, werde ich dar\u00fcber nicht sprechen. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/3f8d179e7c78ce83e8842ef5c72fe30d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Und ein kleiner Disclaimer, bevor wir mit unserem Vortrag beginnen. <\/p>\n<p><\/p>\n<p>All diese Probleme, mit denen wir konfrontiert waren, traten in den ersten 6-7-8 Monaten unserer Nutzung auf. Im Laufe der Zeit haben wir unsere internen Best Practices entwickelt, und diese Probleme sind verschwunden. Daher wurde der Vortrag vor etwa sechs Monaten angek\u00fcndigt, als alles noch frisch in meinem Ged\u00e4chtnis war und ich mich gut daran erinnerte. <\/p>\n<p><\/p>\n<p>W\u00e4hrend der Vorbereitung des Berichts habe ich bereits alte Post-Mortems durchgesehen und Protokolle \u00fcberpr\u00fcft. Dabei k\u00f6nnten einige Details vergessen worden sein oder es k\u00f6nnten einige Aspekte w\u00e4hrend der Problemanalyse nicht ausreichend untersucht worden sein. Daher kann es in manchen Punkten den Anschein erwecken, dass die Probleme nicht vollst\u00e4ndig behandelt wurden oder dass es an Informationen mangelt. Ich bitte Sie daher um Verst\u00e4ndnis f\u00fcr diesen Punkt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/30d414284a41fcbc3bf417c9da28ca52.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Was ist Patroni?<\/p>\n<p><\/p>\n<ul>\n<li>Es ist ein Framework f\u00fcr den Aufbau von Hochverf\u00fcgbarkeitsl\u00f6sungen. So steht es in der Dokumentation. Ich finde, das ist eine sehr treffende Ausf\u00fchrung. Patroni ist keine universelle L\u00f6sung, die alle Ihre Probleme l\u00f6sen wird; es erfordert M\u00fche, damit es funktioniert und Nutzen bringt. <\/li>\n<li>Es handelt sich um einen Agenten, der auf jedem Service mit einer Datenbank installiert wird und der eine Art Init-System f\u00fcr Ihre PostgreSQL-Datenbank darstellt. Er startet, stoppt und startet PostgreSQL neu, \u00e4ndert die Konfiguration und passt die Topologie Ihres Clusters an. <\/li>\n<li>Um den Zustand eines Clusters zu speichern, ben\u00f6tigt man ein geeignetes Speichersystem. In dieser Hinsicht verfolgt Patroni den Ansatz, den State in einem externen System zu speichern. Dabei handelt es sich um ein verteiltes Konfigurationsspeichersystem. Dies k\u00f6nnen Etcd, Consul, ZooKeeper oder der Kubernetes-Etcd sein, also eine dieser Optionen. <\/li>\n<li>Ein besonderes Merkmal von Patroni ist, dass Sie die automatische Failover-Funktion direkt nach der Konfiguration erhalten. Im Vergleich zu Repmgr ist das Failover dort im Paket enthalten. Mit Repmgr erhalten wir einen Switchover, aber wenn wir ein automatisches Failover w\u00fcnschen, muss dies zus\u00e4tzlich konfiguriert werden. Bei Patroni ist das automatische Failover jedoch bereits integriert.<\/li>\n<li>Es gibt noch viele weitere Aspekte, wie die Verwaltung von Konfigurationen, das Hinzuf\u00fcgen neuer Replikate, Backups usw. Aber das geht \u00fcber diesen Bericht hinaus, dar\u00fcber werde ich nicht sprechen. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/fed0f1ce931df99ca76ae1116f8098cc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Zusammenfassend l\u00e4sst sich sagen, dass die Hauptaufgabe von Patroni darin besteht, ein zuverl\u00e4ssiges automatisches Failover zu gew\u00e4hrleisten, sodass der Cluster funktionsf\u00e4hig bleibt und die Anwendung keine \u00c4nderungen in der Cluster-Topologie bemerkt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/fac52620957efa47ced330e7cc8084e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Doch wenn wir beginnen, Patroni zu verwenden, wird unser System etwas komplexer. Hatten wir vorher nur Postgres, so erhalten wir mit Patroni auch Patroni selbst, ein DCS, in dem der Zustand gespeichert wird. Und das Ganze muss irgendwie funktionieren. Also, was kann kaputtgehen?<\/p>\n<p><\/p>\n<p>Folgendes kann kaputtgehen:<\/p>\n<p><\/p>\n<ul>\n<li>Postgres kann ausfallen. Es kann entweder der Master oder die Replikat sein, eines von beiden kann ausfallen. <\/li>\n<li>Auch Patroni kann ausfallen. <\/li>\n<li>Das DCS, in dem der Zustand gespeichert ist, kann ebenfalls kaputtgehen.<\/li>\n<li>Und auch das Netzwerk kann ausfallen. <\/li>\n<\/ul>\n<p><\/p>\n<p>Diese Punkte werde ich in meinem Vortrag behandeln. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/1aeaf46d37bf1935b514b0581e0dbd0b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ich werde die F\u00e4lle nach ihrer Komplexit\u00e4t betrachten, jedoch nicht aus der Perspektive, dass der Fall viele Komponenten betrifft. Vielmehr werde ich meine subjektiven Empfindungen schildern, dass ein bestimmter Fall f\u00fcr mich kompliziert war und schwer zu analysieren\u2026 und umgekehrt, dass ein anderer Fall klar und einfach zu verstehen war. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/65b0c98bf2284610e955ced5eb998f39.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Der erste Fall ist der einfachste. Das ist der Fall, wenn wir einen Datenbankcluster genommen und auf demselben Cluster unser DCS gespeichert haben. Das ist der h\u00e4ufigste Fehler \u2013 ein architektonischer Fehler, d. h. das Zusammenf\u00fchren verschiedener Komponenten an einem Ort. <\/p>\n<p><\/p>\n<p>So, es gab einen Fehler in der Datei, und jetzt gehen wir dem nach, was passiert ist. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/244b69d623fe2205c2d9ed2aa4620067.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hier interessiert uns der Zeitpunkt, an dem der Failover stattfand. Das hei\u00dft, wir wollen diesen Moment wissen, als sich der Status des Clusters ge\u00e4ndert hat. <\/p>\n<p><\/p>\n<p>Aber der Failover ist nicht immer sofort, das hei\u00dft, er dauert nicht immer einen bestimmten Zeitraum, er kann sich \u00fcber l\u00e4ngere Zeit ziehen. Er kann ein langanhaltendes Ereignis sein.<\/p>\n<p><\/p>\n<p>Deshalb gibt es einen Anfangs- und Endzeitpunkt, das hei\u00dft, es handelt sich um ein fortlaufendes Ereignis. Wir teilen alle Ereignisse in drei Abschnitte: die Zeit vor dem Failover, w\u00e4hrend des Failovers und nach dem Failover. Das hei\u00dft, wir betrachten alle Ereignisse auf dieser Zeitachse. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/a0ed61afe55d1a157147e0d80b17e5d1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Als Erstes, wenn der Failover stattgefunden hat, suchen wir nach der Ursache, was passiert ist und was zu dem Failover gef\u00fchrt hat. <\/p>\n<p><\/p>\n<p>Wenn wir uns die Protokolle ansehen, sind dies die klassischen Protokolle von Patroni. Diese geben uns an, dass der Server zum Master wurde und die Master-Rolle auf diesen Knoten \u00fcbergegangen ist. Das ist hier hervorgehoben. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/9998c69f7d0d4358b277f4e0e7b4350f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nun m\u00fcssen wir verstehen, warum ein Failover aufgetreten ist, d. h. welche Ereignisse dazu gef\u00fchrt haben, dass die Masterrolle von einem Knoten auf einen anderen wechselt. In diesem Fall ist es ganz einfach. Wir haben einen Fehler bei der Interaktion mit dem Speichersystem. Der Master hat erkannt, dass er nicht mehr mit DCS arbeiten kann, d. h. es gab ein Problem bei der Interaktion. Er sagt, dass er nicht l\u00e4nger Master sein kann und legt seine Befugnisse nieder. Diese Zeile \u201edemoted self\u201c beschreibt genau das. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/4a8eca27689546b4b0fc3c666a3c37c4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wenn wir die Ereignisse betrachten, die dem Failover vorausgingen, sehen wir die Ursachen, die das Problem f\u00fcr die Weiterarbeit des Masters verursacht haben. <\/p>\n<p><\/p>\n<p>Ein Blick auf die Patroni-Logs zeigt uns eine Vielzahl von Fehlern und Zeit\u00fcberschreitungen, d. h. der Patroni-Agent kann nicht mit DCS arbeiten. In diesem Fall handelt es sich um den Consul-Agenten, mit dem \u00fcber Port 8500 kommuniziert wird. <\/p>\n<p><\/p>\n<p>Das Problem hier ist, dass Patroni und die Datenbank auf demselben Host ausgef\u00fchrt werden. Und auf demselben Knoten wurden auch Consul-Server betrieben. Durch die Belastung des Servers haben wir Probleme sowohl f\u00fcr <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/de\/server\/\"   title=\"Server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1515\">Server<\/a> Consul geschaffen. Sie konnten nicht ordnungsgem\u00e4\u00df kommunizieren. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/0d8dba6641809560e6b32825d481e30b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nach einer gewissen Zeit, als die Last nachgelassen hatte, konnte unser Patroni wieder mit den Agenten kommunizieren. Der normale Betrieb wurde wieder aufgenommen, und derselbe Server Pgdb-2 wurde erneut zum Master. Das hei\u00dft, es gab einen kurzen Flip, bei dem der Knoten seine Master-Rechte ablegte und sie dann wieder annahm, also alles kehrte zu dem zur\u00fcck, was es war. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/131b93e0bd83099e1b99b53742419e13.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Das kann als Fehlalarm gewertet werden, oder man kann argumentieren, dass Patroni alles richtig gemacht hat. Das hei\u00dft, er erkannte, dass er den Zustand des Clusters nicht aufrechterhalten konnte und legte seine Master-Rechte nieder.<\/p>\n<p><\/p>\n<p>Das Problem entstand hier, weil sich die Consul-Server auf demselben Equipment wie die Datenbanken befinden. Jede Last, sei es auf die Festplatten oder Prozessoren, wirkt sich daher auch auf die Interaktion mit dem Consul-Cluster aus.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/142c7cf839c8da078451f7ba9d5499e5.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Und wir haben entschieden, dass dies nicht zusammen existieren sollte, daher haben wir einen separaten Cluster f\u00fcr Consul eingerichtet. Patroni arbeitete bereits mit einem separaten Consul, d.h. es gab einen separaten Postgres-Cluster und einen separaten Consul-Cluster. Dies ist eine grundlegende Anleitung, wie man all diese Dinge auseinanderhalten und verwalten sollte, damit sie nicht zusammen leben. <\/p>\n<p><\/p>\n<p>Eine M\u00f6glichkeit w\u00e4re, die Parameter ttl, loop_wait und retry_timeout anzupassen, also zu versuchen, durch Erh\u00f6hung dieser Parameter diesen tempor\u00e4ren Lastspitzen standzuhalten. Allerdings ist das nicht die beste L\u00f6sung, da diese Last auch l\u00e4ngere Zeit andauern kann. Wir k\u00f6nnten einfach \u00fcber die Grenzen dieser Parameter hinausgehen, und das k\u00f6nnte nicht wirklich helfen. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/c51f35dcd88b1c792acec231c0c6c66c.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Das erste Problem ist, wie Sie verstanden haben, einfach. Wir haben DCS zusammen mit der Datenbank platziert und dadurch ein Problem erhalten. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/cc2a98d9790441577fb4080406cbc53f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Das zweite Problem \u00e4hnelt dem ersten. Es hat \u00c4hnlichkeiten, da wir erneut Probleme mit der Interaktion mit dem DCS-System haben.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/e5c01b105adca48cc620085db8dd2d2b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wenn wir die Protokolle betrachten, sehen wir, dass erneut ein Kommunikationsfehler vorliegt. Und Patroni sagt, dass er nicht mit DCS kommunizieren kann, weshalb der aktuelle Master in den Replikationsmodus wechselt.<\/p>\n<p><\/p>\n<p>Der alte Master wird zur Replik, hier arbeitet Patroni wie vorgesehen. Er startet pg_rewind, um das Transaktionsprotokoll zur\u00fcckzusetzen und sich dann mit dem neuen Master zu verbinden, um den neuen Master wieder einzuholen. Patroni h\u00e4lt sich hier an die vorgesehenen Abl\u00e4ufe. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/29255f4790abb15b64dbf9ee0b41c7fc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hier m\u00fcssen wir den Punkt finden, der dem Failover vorausging, d.h. die Fehler, die dazu f\u00fchrten, dass unser Failover stattfand. In dieser Hinsicht sind die Logs von Patroni recht praktisch. Er schreibt in bestimmten Intervallen dieselben Nachrichten. Wenn wir diese Logs schnell durchscrollen, sehen wir, dass sich die Logs ge\u00e4ndert haben, was bedeutet, dass Probleme aufgetreten sind. Wir kehren schnell an diesen Punkt zur\u00fcck und schauen, was passiert. <\/p>\n<p><\/p>\n<p>In einer normalen Situation sehen die Logs ungef\u00e4hr so aus: Der Besitzer der Sperre wird \u00fcberpr\u00fcft. Wenn der Besitzer beispielsweise gewechselt hat, k\u00f6nnen bestimmte Ereignisse eintreten, auf die Patroni reagieren muss. In diesem Fall haben wir jedoch alles in Ordnung. Wir suchen den Punkt, an dem die Fehler auftraten. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/f48ebd22a405f5b2900621451c68f543.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wenn wir bis zu dem Punkt zur\u00fcckscrollen, an dem die Fehler zu erscheinen begannen, sehen wir, dass ein automatisches Failover stattgefunden hat. Da die Fehler mit der Interaktion mit DCS zusammenhingen und wir in unserem Fall Consul verwendeten, schauen wir auch in die Logs von Consul, um zu sehen, was dort passiert ist. <\/p>\n<p><\/p>\n<p>Wenn wir die Zeit des File Servers und die Zeit in den Consul-Protokollen vergleichen, sehen wir, dass unsere Nachbarn im Consul-Cluster anfangen, an der Existenz anderer Teilnehmer des Consul-Clusters zu zweifeln.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/63b02ac5b4f5a34a2822f1eee2b1f2f8.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wenn wir uns die Protokolle anderer Consul-Agenten ansehen, erkennen wir ebenfalls, dass es dort zu einem Netzwerkzusammenbruch kommt. Alle Teilnehmer des Consul-Clusters zweifeln an der Existenz voneinander, und dies war der Ansto\u00df f\u00fcr den File Server. <\/p>\n<p><\/p>\n<p>Wenn man betrachtet, was vor diesen Fehlern passiert ist, kann man verschiedene Fehler feststellen, zum Beispiel Deadline-Ausf\u00e4lle, RPC-Fehler. Das deutet eindeutig auf ein Problem bei der Interaktion der Teilnehmer im Consul-Cluster hin. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/b15c912f2afb49d9d85e7bb9361ce449.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Die einfachste Antwort w\u00e4re, das Netzwerk zu reparieren. Aber es ist leicht, das von meinem Standpunkt aus zu sagen. Die Umst\u00e4nde sind jedoch so, dass der Kunde nicht immer in der Lage ist, das Netzwerk zu reparieren. Er k\u00f6nnte in einem Rechenzentrum leben und m\u00f6glicherweise keine M\u00f6glichkeit haben, das Netzwerk zu reparieren oder das Equipment zu beeinflussen. Daher sind alternative L\u00f6sungen notwendig. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/1dbdb66233acc3bc321a30a1c5fe14f9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Es gibt Alternativen:<\/p>\n<p><\/p>\n<ul>\n<li>Die einfachste M\u00f6glichkeit, die, meiner Meinung nach, sogar in der Dokumentation beschrieben ist, besteht darin, die Consul-\u00dcberpr\u00fcfungen zu deaktivieren, das hei\u00dft, einfach ein leeres Array zu \u00fcbergeben. Damit sagen wir dem Consul-Agenten, dass er keine \u00dcberpr\u00fcfungen durchf\u00fchren soll. Dadurch k\u00f6nnen wir diese Netzwerkst\u00f6rungen ignorieren und brauchen keine Datei\u00fcbertragungen zu initiieren. <\/li>\n<li>Eine andere M\u00f6glichkeit besteht darin, den raft_multiplier zu \u00fcberpr\u00fcfen. Dies ist ein Parameter des Consul-Servers. Standardm\u00e4\u00dfig ist er auf den Wert 5 eingestellt. Dieser Wert wird in der Dokumentation f\u00fcr Staging-Umgebungen empfohlen. Grunds\u00e4tzlich beeinflusst dies die Frequenz des Nachrichtenaustauschs zwischen den Mitgliedern des Consul-Netzwerks. Dieser Parameter wirkt sich auf die Geschwindigkeit der Kommunikation zwischen den Mitgliedern des Consul-Clusters aus. F\u00fcr die Produktionsumgebung wird empfohlen, den Wert zu verringern, damit die Knoten h\u00e4ufiger Nachrichten austauschen. <\/li>\n<li>Eine weitere Vorgehensweise, die wir implementiert haben, besteht darin, die Priorit\u00e4t der Consul-Prozesse im Vergleich zu anderen Prozessen f\u00fcr den Prozess-Scheduler des Betriebssystems zu erh\u00f6hen. Es gibt einen Parameter namens \"nice\", der genau die Priorit\u00e4t der Prozesse bestimmt, die der Betriebssystem-Scheduler bei der Planung ber\u00fccksichtigt. Wir haben den Wert f\u00fcr unsere Consul-Agenten gesenkt, das hei\u00dft, ihre Priorit\u00e4t erh\u00f6ht, damit das Betriebssystem den Consul-Prozessen mehr Zeit f\u00fcr die Ausf\u00fchrung ihrer Aufgaben und Codes einr\u00e4umt. In unserem Fall hat dies unser Problem gel\u00f6st. <\/li>\n<li>Eine andere Option ist, Consul nicht zu verwenden. Ich habe einen Kollegen, der ein gro\u00dfer Fan von Etcd ist. Wir diskutieren regelm\u00e4\u00dfig dar\u00fcber, was besser ist: Etcd oder Consul. In der Regel sind wir uns jedoch einig, dass Consul einen Agenten ben\u00f6tigt, der auf jedem Knoten mit der Datenbank ausgef\u00fchrt wird. Das hei\u00dft, die Interaktion von Patroni mit dem Consul-Cluster erfolgt \u00fcber diesen Agenten. Dieser Agent kann zum Engpass werden. Wenn mit dem Agenten etwas schiefgeht, kann Patroni nicht mehr mit dem Consul-Cluster arbeiten. Das ist das Problem. Bei Etcd gibt es keinen solchen Agenten. Patroni kann direkt mit der Liste der Etcd-Server arbeiten und kommunizieren. In dieser Hinsicht w\u00e4re Etcd wahrscheinlich die bessere Wahl als Consul, wenn Sie es in Ihrem Unternehmen verwenden. Allerdings sind wir bei unseren Kunden in der Regel an das gebunden, was der Kunde gew\u00e4hlt hat und verwendet. \u00dcberwiegend setzen unsere Kunden Consul ein. <\/li>\n<li>Der letzte Punkt ist, die Parameterwerte zu \u00fcberpr\u00fcfen. Wir k\u00f6nnen diese Parameter erh\u00f6hen in der Hoffnung, dass unsere kurzzeitigen Netzwerkprobleme kurz bleiben und nicht den Zeitraum dieser Parameter \u00fcberschreiten. So k\u00f6nnen wir die Aggressivit\u00e4t von Patroni bei der automatischen Failover-Funktion verringern, falls Netzwerkprobleme auftreten.<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/f0043050da20f6368dabf66ec9a4eade.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ich denke, viele, die Patroni verwenden, sind mit diesem Befehl vertraut. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/9f78f59dab166e47ac78436802156d04.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dieser Befehl zeigt den aktuellen Zustand des Clusters an. Auf den ersten Blick k\u00f6nnte dieses Bild normal erscheinen. Wir haben einen Master, wir haben eine Replik, und es gibt keine Replikationsverz\u00f6gerung. Aber dieses Bild ist nur dann normal, wenn wir wissen, dass in diesem Cluster drei Knoten und nicht zwei vorhanden sein sollten. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/a39c891f8620ba210b6bce0727e0fa8b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Entsprechend gab es ein automatisches Failover. Nach diesem Failover ist unsere Replik verschwunden. Wir m\u00fcssen herausfinden, warum sie verschwunden ist und sie zur\u00fcckholen, wiederherstellen. Und wir gehen erneut in die Logs und schauen, warum das Failover aufgetreten ist.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/e6e67d46cb20c8d7e58c7505157f68e1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In diesem Fall ist die zweite Replik zum Master geworden. Hier ist alles in Ordnung. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/b86ccea68b0c6013a23bbd2804e48320.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir m\u00fcssen uns die Replikat ansehen, die getrennt ist und nicht im Cluster ist. Wir \u00f6ffnen die Patroni-Logs und sehen, dass ein Problem beim Verbindungsaufbau zum Cluster in der Phase pg_rewind aufgetreten ist. Um sich mit dem Cluster zu verbinden, muss das Transaktionsprotokoll zur\u00fcckgedreht werden, das ben\u00f6tigte Transaktionsprotokoll vom Master angefordert und dann mit dem Master synchronisiert werden. <\/p>\n<p><\/p>\n<p>In diesem Fall haben wir kein Transaktionsprotokoll, und die Replikat kann nicht gestartet werden. Daher stoppen wir Postgres mit einem Fehler. Aus diesem Grund ist sie nicht im Cluster. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/dadbd44b766674b719d85781ef7f0caa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Es ist wichtig zu verstehen, warum sie nicht im Cluster ist und warum keine Logs vorhanden sind. Wir schauen uns den neuen Master an und \u00fcberpr\u00fcfen die Logs. Es stellt sich heraus, dass w\u00e4hrend des pg_rewind ein Checkpoint stattfand. Ein Teil der alten Transaktionsprotokolle wurde einfach umbenannt. Als der alte Master versuchte, sich mit dem neuen Master zu verbinden und diese Logs anzufordern, waren sie bereits umbenannt, sie waren einfach nicht mehr da.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/f2d5c37324f9436b2bdad1290612d86f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ich habe die Zeitstempel verglichen, als diese Ereignisse stattfanden. Die Differenz betrug nur 150 Millisekunden, d. h. der Checkpoint wurde in 369 Millisekunden abgeschlossen, die WAL-Segmente wurden umbenannt. Und nur 150 Millisekunden sp\u00e4ter, also nach 517 Millisekunden, startete das Rewind auf der alten Replik. Das hei\u00dft, wir hatten buchst\u00e4blich 150 Millisekunden, in denen die Replik keine Verbindung herstellen und nicht funktionieren konnte. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/99dd80deb8466bfc3aff568456e07102.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Welche Optionen gibt es?<\/p>\n<p><\/p>\n<p>Wir haben zun\u00e4chst Replikationsslots verwendet. Wir dachten, das w\u00e4re gut. Obwohl wir in der ersten Phase des Betriebs die Slots deaktiviert haben. Wir hatten das Gef\u00fchl, dass, wenn die Slots zu viele WAL-Segmente anh\u00e4ufen, wir den Master gef\u00e4hrden k\u00f6nnten. Er k\u00f6nnte ausfallen. Wir haben eine Weile ohne Slots gek\u00e4mpft und festgestellt, dass wir die Slots brauchen, also haben wir sie zur\u00fcckgebracht. <\/p>\n<p><\/p>\n<p>Aber hier gibt es ein Problem: Wenn der Master zur Replik wechselt, l\u00f6scht er die Slots und damit auch die WAL-Segmente. Um diese Problematik zu vermeiden, haben wir beschlossen, den Parameter wal_keep_segments zu erh\u00f6hen. Der Standardwert betr\u00e4gt 8 Segmente. Wir haben ihn auf 1.000 erh\u00f6ht und geschaut, wie viel Freiraum wir haben. Und wir haben 16 Gigabyte f\u00fcr wal_keep_segments reserviert. Das hei\u00dft, bei einem Switch haben wir immer auf allen Knoten einen Puffer von 16 Gigabyte an Transaktionsprotokollen.<\/p>\n<p><\/p>\n<p>Und das ist auch relevant f\u00fcr langfristige Wartungsaufgaben. Angenommen, wir m\u00fcssen eine der Replikate aktualisieren. Wir m\u00f6chten sie ausschalten. Wir m\u00fcssen die Software aktualisieren, m\u00f6glicherweise das Betriebssystem oder etwas anderes. Wenn wir das Replikat ausschalten, wird auch der Slot f\u00fcr dieses Replikat entfernt. Und wenn wir nur eine kleine Anzahl von wal_keep_segments verwenden, k\u00f6nnen bei l\u00e4ngerer Abwesenheit des Replikats die Transaktionsprotokolle wiedergegeben werden. Wir starten das Replikat neu, es fordert die Transaktionsprotokolle an, an dem Punkt, an dem es gestoppt wurde, aber vielleicht gibt es diese auf dem Master nicht mehr. Und dann kann sich das Replikat auch nicht verbinden. Daher halten wir eine gro\u00dfe Menge an Protokollen bereit.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/dad55c828128ce92f649a99cc53ce54b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/63e70f0b098567f3a6d4fd66a0c293bb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir haben eine Produktionsdatenbank. Dort laufen bereits Projekte. <\/p>\n<p><\/p>\n<p>Ein Dateisystemfehler ist aufgetreten. Wir haben nachgesehen und festgestellt, dass alles in Ordnung ist, die Replikate an Ort und Stelle sind, und es gibt keine Verz\u00f6gerung bei der Replikation. Auch keine Fehler in den Protokollen, alles ist in Ordnung. <\/p>\n<p><\/p>\n<p>Das Produktteam sagt, dass es irgendwie Daten geben sollte, aber wir sehen sie nur an einer Quelle und nicht in der Datenbank. Wir m\u00fcssen herausfinden, was mit ihnen passiert ist. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/568ca9aa31680d5e0c9d4ed9693b14e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Es ist klar, dass pg_rewind sie \u00fcberschrieben hat. Das haben wir sofort erkannt, aber wir sind gegangen, um zu sehen, was passiert ist. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/a8fee389201d96e81761cd276c5265c3.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In den Logs k\u00f6nnen wir immer feststellen, wann der Failover stattgefunden hat, wer der neue Master wurde und k\u00f6nnen bestimmen, wer der alte Master war und wann er repliziert werden wollte. Das hei\u00dft, wir ben\u00f6tigen diese Logs, um das Volumen der verlorenen Transaktionsprotokolle zu ermitteln.<\/p>\n<p><\/p>\n<p>Unser alter Master wurde neu gestartet. Im Autostart war Patroni eingetragen. Patroni wurde gestartet. Daraufhin startete er Postgres. Genauer gesagt, vor dem Start von Postgres und bevor er ihn replizierte, startete Patroni den Prozess pg_rewind. Dementsprechend hat er einen Teil der Transaktionsprotokolle gel\u00f6scht, die neuen heruntergeladen und sich verbunden. Hier hat Patroni hervorragend funktioniert, genau wie es sein sollte. Unser Cluster wurde wiederhergestellt. Wir hatten 3 Nodes, nach dem Failover hatten wir 3 Nodes \u2013 alles gro\u00dfartig. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/b747a24f53e20ed098c2dc0afc79bead.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir haben einen Teil der Daten verloren. Und wir m\u00fcssen herausfinden, wie viel wir verloren haben. Wir suchen genau nach dem Zeitpunkt, an dem der Rewind stattgefunden hat. Das k\u00f6nnen wir an solchen Eintr\u00e4gen im Log erkennen. Der Rewind wurde gestartet, hat etwas dort gemacht und wurde abgeschlossen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/5b7bacffb52e3ccd529a3a734c441295.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir m\u00fcssen die Position im Transaktionsprotokoll finden, an der der alte Master gestoppt hat. In diesem Fall ist das dieser Punkt. Und wir ben\u00f6tigen einen zweiten Punkt, also den Abstand, um den sich der alte Master vom neuen unterscheidet. <\/p>\n<p><\/p>\n<p>Wir nehmen die gew\u00f6hnliche pg_wal_lsn_diff und vergleichen diese beiden Markierungen. In diesem Fall erhalten wir 17 Megabyte. Ob das viel oder wenig ist, entscheidet jeder f\u00fcr sich. Denn f\u00fcr manche sind 17 Megabyte wenig, f\u00fcr andere viel und inakzeptabel. Hier muss jeder individuell gem\u00e4\u00df den Bed\u00fcrfnissen seines Unternehmens entscheiden. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/55335fce85961e159459c38300a0ad12.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Aber was haben wir f\u00fcr uns herausgefunden? <\/p>\n<p><\/p>\n<p>Zun\u00e4chst m\u00fcssen wir f\u00fcr uns kl\u00e4ren \u2013 brauchen wir immer den automatischen Start von Patroni nach einem Neustart des Systems? Oftmals ist es so, dass wir auf den alten Master zugreifen m\u00fcssen, um zu sehen, wie weit er fortgeschritten ist. M\u00f6glicherweise m\u00fcssen wir die Segmente des Transaktionsprotokolls inspizieren und herausfinden, was dort vor sich geht. Und verstehen, ob wir diese Daten verlieren k\u00f6nnen oder ob wir den alten Master im Standalone-Modus starten m\u00fcssen, um diese Daten zu extrahieren. <\/p>\n<p><\/p>\n<p>Erst danach sollten wir entscheiden, ob wir diese Daten verwerfen oder ob wir sie wiederherstellen k\u00f6nnen, indem wir diesen Knoten als Replik in unser Cluster einbinden.<\/p>\n<p><\/p>\n<p>Dar\u00fcber hinaus gibt es den Parameter \u201emaximum_lag_on_failover\u201c. Standardm\u00e4\u00dfig hat dieser Parameter, wenn ich mich nicht irre, den Wert von 1 Megabyte. <\/p>\n<p><\/p>\n<p>Wie funktioniert es? Wenn unser Replikat bei der Replikationsverz\u00f6gerung um 1 Megabyte hinterherh\u00e4ngt, nimmt es nicht an Wahlen teil. Und wenn es zu einem Failover kommt, schaut Patroni, welche Replikate hinterherh\u00e4ngen. Wenn sie bei einer gro\u00dfen Anzahl an Transaktionsprotokollen zur\u00fcckliegen, k\u00f6nnen sie nicht zum Master werden. Das ist eine hervorragende Schutzfunktion, die hilft, den Verlust von Daten zu vermeiden. <\/p>\n<p><\/p>\n<p>Es gibt jedoch ein Problem: Die Replikationsverz\u00f6gerung im Patroni-Cluster und DCS wird in bestimmten Intervallen aktualisiert. Meines Wissens betr\u00e4gt der Standardwert f\u00fcr ttl 30 Sekunden.<\/p>\n<p><\/p>\n<p>Daher kann es Situationen geben, in denen die Replikationsverz\u00f6gerung in DCS eine ist, w\u00e4hrend die tats\u00e4chliche Verz\u00f6gerung entweder ganz anders oder sogar nicht vorhanden sein kann. Das bedeutet, es handelt sich nicht um Echtzeit. Es spiegelt nicht immer das tats\u00e4chliche Bild wider. Daher sollte man keine komplizierten Logiken darauf basieren. <\/p>\n<p><\/p>\n<p>Das Risiko von Datenverlust bleibt immer bestehen. Im schlimmsten Fall gilt eine Formel, im Durchschnitt eine andere. Das hei\u00dft, wenn wir die Implementierung von Patroni planen und bewerten, wie viele Daten wir verlieren k\u00f6nnen, m\u00fcssen wir mit diesen Formeln rechnen und eine Vorstellung davon haben, wie viele Daten wir m\u00f6glicherweise verlieren. <\/p>\n<p><\/p>\n<p>Die gute Nachricht ist, dass, wenn der alte Master vorgegangen ist, er dies m\u00f6glicherweise durch einige Hintergrundprozesse tun konnte. Das bedeutet, dass ein Autovakuum lief, es wurden Daten geschrieben und im Transaktionsprotokoll gespeichert. Diese Daten k\u00f6nnen wir problemlos ignorieren und verlieren. Das stellt kein Problem dar. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/a86e8971ab4ef41b89af9cf0bdf519ba.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>So sehen die Protokolle aus, wenn maximum_lag_on_failover festgelegt ist und ein Failover stattgefunden hat, und ein neuer Master ausgew\u00e4hlt werden muss. Die Replik bewertet sich selbst als unf\u00e4hig, an den Wahlen teilzunehmen, und zieht sich vom Rennen um die F\u00fchrerschaft zur\u00fcck. Sie wartet darauf, dass ein neuer Master gew\u00e4hlt wird, um sich dann mit ihm zu verbinden. Dies ist eine zus\u00e4tzliche Ma\u00dfnahme zur Vermeidung von Datenverlust.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/f760788e5951facdd08b2069037830fa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/c32f26e7526e1873f3bfd7d3693fcc72.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hier hat unser Produktteam geschrieben, dass ihr Produkt Probleme mit Postgres hat. Der Master selbst ist jedoch nicht erreichbar, da er \u00fcber SSH nicht verf\u00fcgbar ist. Au\u00dferdem findet kein automatisches Failover statt. <\/p>\n<p><\/p>\n<p>Dieser Host wurde gezwungen, neu gestartet zu werden. Aufgrund des Neustarts fand ein automatisches Failover statt, obwohl man auch manuelles Failover h\u00e4tte durchf\u00fchren k\u00f6nnen, wie ich jetzt verstehe. Nach dem Neustart schauen wir uns an, was mit unserem aktuellen Master passiert ist. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/95efb82e0647a396a21683cd53a69547.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dabei wussten wir bereits im Voraus, dass wir Probleme mit den Festplatten hatten, d.h. wir kannten anhand der \u00dcberwachung bereits den Bereich, in dem wir nachforschen mussten und wonach wir suchen sollten. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/367aaab607d833d96a573ddbbbced502.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir haben die Postgres-Protokolle durchgesehen und geschaut, was dort vor sich geht. Wir haben Commit-Operationen gesehen, die jeweils ein bis drei Sekunden dauerten, was v\u00f6llig unnormal war. Wir stellten fest, dass der Autovacuum-Prozess sehr lange und merkw\u00fcrdig gestartet wurde. Zudem entdeckten wir tempor\u00e4re Dateien auf der Festplatte. Das alles sind Anzeichen f\u00fcr Festplattenprobleme. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/7e0cfce7a81901ef9ef736c3fefc8dce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir haben uns die Systemdmesg (Kernmeldungen) angesehen und festgestellt, dass wir ein Problem mit einer der Festplatten haben. Das Festplattensystem stellte ein Software-RAID dar. Wir schauten in \/proc\/mdstat und bemerkten, dass eine Festplatte fehlte. Konkret handelt es sich um ein RAID aus 8 Festplatten, wobei eine nicht vorhanden ist. Wenn man sich die Folie genau betrachtet, kann man im Ausgabeprotokoll sehen, dass sde fehlt. Mit anderen Worten, eine Festplatte ist ausgefallen. Das hat die Festplattenprobleme ausgel\u00f6st, und die Anwendungen hatten ebenfalls Schwierigkeiten mit dem Postgres-Cluster.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/4b09b3aa761cb504fa79173ef280faac.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In diesem Fall h\u00e4tte uns Patroni nicht geholfen, da Patroni nicht daf\u00fcr verantwortlich ist, den Zustand des Servers oder der Festplatten zu \u00fcberwachen. Diese Situationen m\u00fcssen wir mit externem Monitoring \u00fcberwachen. Wir haben das externe Monitoring um eine \u00dcberwachung der Festplatten erg\u00e4nzt. <\/p>\n<p><\/p>\n<p>Es kam der Gedanke auf \u2013 k\u00f6nnte uns ein Fence oder ein Software-Watchdog helfen? Wir dachten, dass das in diesem Fall wahrscheinlich nicht helfen w\u00fcrde, da Patroni w\u00e4hrend der Probleme weiterhin mit dem DCS-Cluster interagierte und keine Probleme feststellte. Das hei\u00dft, aus der Sicht von DCS und Patroni war im Cluster alles in Ordnung, obwohl tats\u00e4chlich Probleme mit der Festplatte und der Datenbankverf\u00fcgbarkeit bestanden. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/15fdac78535355d4eb889efcc27efc46.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Meiner Meinung nach ist das eines der seltsamsten Probleme, die ich lange untersucht habe. Ich habe viele Logs durchgelesen und analysiert und nannte es den Cluster-Simulanten. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/b5259774931c290eda6673deb14b6c48.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Das Problem war, dass der alte Master nicht zu einer normalen Replik werden konnte. Patroni startete ihn, und es wurde angezeigt, dass dieser Knoten als Replik vorhanden ist, aber gleichzeitig war er keine echte Replik. Jetzt werden Sie sehen, warum. Das habe ich aus der Analyse dieses Problems behalten. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/c35a5d102a46764bbf96e5a75ee88171.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Und wie alles begann? Es begann, \u00e4hnlich wie beim vorherigen Problem, mit den Festplattenspeichern. Wir hatten ein bis zwei Commits pro Sekunde. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/435c1b350a89f288e0e10ca9d5a2ec6e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Es gab Verbindungsabbr\u00fcche, das hei\u00dft, die Kunden wurden getrennt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/920cb1f3f3b40578e15e6ff711e85c50.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Es gab Blockierungen unterschiedlicher Schwere. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/285d6292d89b928a85e95602ee57d38a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Demzufolge war das Speichersystem nicht sehr reaktionsschnell. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/ebe71d49360e7f604ecd6a3c8276cb73.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Und das Mysteri\u00f6seste f\u00fcr mich war der eingehende Immediate Shutdown Request. Postgres hat drei Abschaltmodi:<\/p>\n<p><\/p>\n<ul>\n<li>Der erste ist graceful, wenn wir darauf warten, dass sich alle Clients selbstst\u00e4ndig abmelden. <\/li>\n<li>Es gibt fast, wenn wir die Clients zum Abmelden zwingen, weil wir das System herunterfahren. <\/li>\n<li>Und immediate. In diesem Fall informiert immediate nicht einmal die Clients, dass sie sich abmelden sollen, es schaltet einfach ohne Vorwarnung ab. Allen Clients wird von der Betriebssystemnachricht RST (TCP-Nachricht, dass die Verbindung unterbrochen wurde und es f\u00fcr den Client nichts mehr zu holen gibt) gesendet. <\/li>\n<\/ul>\n<p><\/p>\n<p>Wer dieses Signal gesendet hat? Hintergrundprozesse von Postgres senden sich solche Signale nicht, das hei\u00dft, es ist ein kill-9. Sie senden sich solche Signale nicht, sie reagieren nur darauf, das hei\u00dft, es handelt sich um einen Notfallneustart von Postgres. Wer es gesendet hat, wei\u00df ich nicht. <\/p>\n<p><\/p>\n<p>Ich habe mir das Team \"last\" angeschaut und gesehen, dass eine Person ebenfalls auf diesen Server eingeloggt war, aber ich habe mich nicht getraut zu fragen. Vielleicht war es ein kill -9. Ich h\u00e4tte kill -9 in den Logs gesehen, da Postgres meldet, dass kill -9 empfangen wurde, aber ich habe es in den Logs nicht gefunden. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/fe8e844649cea3384ebfde86e36eba44.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Als ich weiter nachforschte, fiel mir auf, dass Patroni ziemlich lange nicht in die Logs geschrieben hat \u2013 54 Sekunden. Wenn ich die beiden Zeitstempel vergleiche, gab es etwa 54 Sekunden lang keine Meldungen. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/ffb1c4db3d7de591d77d56ed2fcc4f2a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In dieser Zeit kam es zu einem automatischen Failover. Patroni hat hier wieder hervorragend funktioniert. Unser alter Master war nicht erreichbar, es gab etwas mit ihm. Und es begannen die Wahlen eines neuen Masters. Das lief alles gut ab. Unser pgsql01 wurde zum neuen Leader. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/6b2457653e9f77af44cd64b4aff021a0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir haben eine Replik, die zum Master geworden ist. Und es gibt eine zweite Replik. Und bei der zweiten Replik gab es Probleme. Sie versuchte, sich neu zu konfigurieren. Soweit ich verstehe, wollte sie die recovery.conf \u00e4ndern, Postgres neu starten und sich mit dem neuen Master verbinden. Alle 10 Sekunden schreibt sie Meldungen, dass sie es versucht, aber es klappt nicht. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/381818f189e19c3e1154074b4652f837.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>W\u00e4hrend dieser Versuche hat der alte Master ein immediate-shutdown-Signal erhalten. Der Master startet neu. Auch die Wiederherstellung wird unterbrochen, da der alte Master neu gestartet wird. Das bedeutet, die Replica kann sich nicht mit ihm verbinden, da er im abgeschalteten Zustand ist. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/d8a8cde925fa8fe601d44ab908ae69dc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Irgendwann hat es funktioniert, aber die Replikation wurde nicht gestartet. <\/p>\n<p><\/p>\n<p>Ich habe nur eine Hypothese: Im recovery.conf war die Adresse des alten Masters gespeichert. Als der neue Master auftauchte, versuchte die zweite Replica weiterhin, sich mit dem alten Master zu verbinden. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/425ea3af1f1e186f4760e1fb1f5419fa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Als Patroni auf der zweiten Replica gestartet wurde, ist der Knoten hochgefahren, konnte sich jedoch nicht mit der Replikation verbinden. Dadurch entstand ein Replikationsverzug, der etwa so aussah. Das bedeutet, alle drei Knoten waren vorhanden, aber der zweite Knoten hatte R\u00fcckstand. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/f564eacd9944666c9a3f5bea634ede6b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wenn man sich die protokollierten Logs ansieht, konnte man feststellen, dass die Replikation nicht gestartet werden konnte, weil die Transaktionsprotokolle unterschiedlich waren. Die von dem Master angebotenen Transaktionsprotokolle, die in recovery.conf angegeben sind, passen einfach nicht zu unserem aktuellen Knoten. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/6b09947d157c9ef0a190da2df2cb5892.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Und hier habe ich einen Fehler gemacht. Ich h\u00e4tte nachsehen m\u00fcssen, was im recovery.conf steht, um meine Hypothese zu \u00fcberpr\u00fcfen, dass wir uns nicht mit dem richtigen Master verbinden. Aber ich habe mich damals gerade erst in dieses Thema eingearbeitet und es ist mir nicht eingefallen, oder ich habe gesehen, dass die Replikation hinterherhinkt und sie neu aufgesetzt werden m\u00fcsste, also habe ich das mehr oder weniger schlampig erledigt. Das war mein Fehler. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/159f2256fd81428fd0d82a255528887d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nach 30 Minuten kam der Admin, ich hatte Patroni auf der Replik gestartet. Ich hatte schon mit ihr abgeschlossen und dachte, dass ich sie neu aufsetzen m\u00fcsste. Und dann dachte ich \u2013 ich starte Patroni erneut, vielleicht klappt ja etwas Positives. Der Recovery-Prozess startete. Und die Datenbank \u00f6ffnete sich sogar, sie war bereit, Verbindungen anzunehmen. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/aeac98750386c8389d39e006a229cc85.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Die Replikation wurde gestartet. Aber nach einer Minute fiel sie mit dem Fehler aus, dass die Transaktionsprotokolle nicht passen. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/17eaba000a79c80c29d1bc3902de05e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ich dachte, ich starte es nochmal neu. Ich habe Patroni erneut gestartet, und ich habe nicht Postgres neu gestartet, sondern speziell Patroni in der Hoffnung, dass er die Datenbank auf magische Weise aktivieren w\u00fcrde. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/a85b38e033c45ad73da317f41e0ef24a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Die Replikation wurde erneut gestartet, jedoch waren die Eintr\u00e4ge im Transaktionsprotokoll unterschiedlich; sie stimmten nicht mit denen bei dem vorherigen Versuch \u00fcberein. Die Replikation stoppte wieder. Und die Nachricht war bereits etwas anders. Sie war f\u00fcr mich nicht besonders informativ. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/fd90d708230bd54af685786c7e361ee1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Und da kam mir der Gedanke \u2013 was w\u00e4re, wenn ich Postgres neu starte und w\u00e4hrenddessen auf dem aktuellen Master einen Checkpoint mache, um den Punkt im Transaktionsprotokoll ein wenig nach vorne zu verschieben, sodass die Wiederherstellung zu einem anderen Zeitpunkt beginnt? Au\u00dferdem hatten wir noch einige WAL-Reservoirs. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/19e67f95d1a74141a013947c9aa39e38.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ich habe Patroni neu gestartet, ein paar Checkpoints auf dem Master gemacht und einige Restart-Punkte auf der Replik, als sie ge\u00f6ffnet wurde. Und das hat geholfen. Ich habe lange dar\u00fcber nachgedacht, warum das geholfen hat und wie es funktioniert hat. Und die Replikation lief. Und die Replikation riss nicht mehr ab. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/418ca59a681be84f51ed374a73a759c9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ein solches Problem geh\u00f6rt f\u00fcr mich zu den r\u00e4tselhaftesten, \u00fcber das ich immer noch nachdenke, was dort tats\u00e4chlich passiert ist. <\/p>\n<p><\/p>\n<p>Was sind die Erkenntnisse hier? Patroni kann wie vorgesehen funktionieren, ohne Fehler. Das bedeutet jedoch nicht, dass alles perfekt ist. Eine Replikation kann aktiviert werden, k\u00f6nnte sich jedoch im halbfertigen Zustand befinden, was bedeutet, dass die Anwendung nicht mit einer solchen Replikation arbeiten kann, da dort veraltete Daten vorhanden sind. <\/p>\n<p><\/p>\n<p>Nach jedem Failover sollten wir unbedingt \u00fcberpr\u00fcfen, ob alles in Ordnung mit dem Cluster ist, d.h. ob die erforderliche Anzahl an Replikaten vorhanden ist und kein Replikationsverzug besteht.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/aca7047ff33d3efe14071b798b554091.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>W\u00e4hrend ich diese Probleme diskutieren werde, werde ich Empfehlungen formulieren. Ich habe versucht, sie in zwei Folien zu b\u00fcndeln. Wahrscheinlich h\u00e4tten alle Geschichten in zwei Folien zusammengefasst werden k\u00f6nnen, die man dann einfach erz\u00e4hlt.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/d4ad31b26d83c8846fe4097a11d70849.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wenn Sie Patroni verwenden, ist eine \u00dcberwachung unerl\u00e4sslich. Sie m\u00fcssen immer wissen, wann ein Auto-Failover stattgefunden hat, denn wenn Sie nicht wissen, dass ein Auto-Failover passiert ist, haben Sie den Cluster nicht im Griff. Und das ist schlecht.<\/p>\n<p><\/p>\n<p>Nach jedem Failover sollten wir den Cluster immer manuell \u00fcberpr\u00fcfen. Wir m\u00fcssen sicherstellen, dass wir immer die aktuelle Anzahl an Replikaten haben, kein Replikationsverzug besteht und dass die Protokolle keine Fehler im Zusammenhang mit der Streaming-Replikation, Patroni oder dem DCS-System aufweisen.<\/p>\n<p><\/p>\n<p>Automatisierung kann erfolgreich funktionieren, Patroni ist ein hervorragendes Werkzeug. Es kann arbeiten, aber das wird den Cluster nicht in den gew\u00fcnschten Zustand versetzen. Und wenn wir das nicht wissen, haben wir ein Problem.<\/p>\n<p><\/p>\n<p>Und Patroni ist kein Allheilmittel. Wir m\u00fcssen immer noch verstehen, wie Postgres funktioniert, wie die Replikation abl\u00e4uft und wie Patroni mit Postgres zusammenarbeitet, sowie wie die Interaktion zwischen den Knoten gew\u00e4hrleistet wird. Dies ist notwendig, um Probleme manuell beheben zu k\u00f6nnen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/ea4162df3561d2ea7001f2ef6788eaaa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wie gehe ich an die Diagnose heran? Es stellt sich heraus, dass wir mit verschiedenen Kunden arbeiten und niemand das ELK-Stack hat, sodass wir in den Logs nachsehen m\u00fcssen, indem wir 6 Konsolen und 2 Tabs \u00f6ffnen. In einem Tab sind die Logs von Patroni f\u00fcr jeden Knoten, im anderen Tab die Logs von Consul oder, falls notwendig, von Postgres. Das Diagnostizieren ist sehr schwierig. <\/p>\n<p><\/p>\n<p>Welche Ans\u00e4tze habe ich entwickelt? Zum einen schaue ich immer, wann der Failover eingetreten ist. F\u00fcr mich ist dies ein entscheidender Moment. Ich achte darauf, was vor dem Failover, w\u00e4hrend des Failovers und nach dem Failover passiert ist. Der Failover hat zwei Zeitmarken: den Beginn und das Ende. <\/p>\n<p><\/p>\n<p>Als n\u00e4chstes schaue ich in den Logs nach den Ereignissen vor dem Failover, also suche ich nach den Ursachen, warum das Failover stattgefunden hat. <\/p>\n<p><\/p>\n<p>Das gibt mir ein Bild davon, was passiert ist und was ich in der Zukunft tun kann, um solche Umst\u00e4nde zu vermeiden und somit ein erneutes Failover zu verhindern.<\/p>\n<p><\/p>\n<p>Und wohin schauen wir normalerweise? Ich schaue:<\/p>\n<p><\/p>\n<ul>\n<li>Zuerst in die Patroni-Logs. <\/li>\n<li>Dann \u00fcberpr\u00fcfe ich die Postgres-Logs oder die DCS-Logs, je nachdem, was ich in den Patroni-Logs gefunden habe. <\/li>\n<li>Auch die Systemlogs k\u00f6nnen manchmal Aufschluss dar\u00fcber geben, was die Ursache f\u00fcr das Failover war. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/a53618e366020e1a550d852fc308c188.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wie denke ich \u00fcber Patroni? Ich halte sehr viel von Patroni. Meiner Meinung nach ist es das Beste, was es zurzeit gibt. Ich kenne viele andere Produkte: Stolon, Repmgr, Pg_auto_failover, PAF. Insgesamt vier Tools. Ich habe sie alle ausprobiert. Patroni hat mir am besten gefallen. <\/p>\n<p><\/p>\n<p>Wenn man mich fragt: \u201eEmpfehle ich Patroni?\u201c, sage ich ja, denn Patroni gef\u00e4llt mir und ich habe das Gef\u00fchl, dass ich gelernt habe, es effektiv zu nutzen. <\/p>\n<p><\/p>\n<p>Wenn Sie interessiert sind, welche weiteren Probleme mit Patroni auftreten k\u00f6nnen, abgesehen von den, die ich erw\u00e4hnt habe, k\u00f6nnen Sie jederzeit die Seite besuchen <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/zalando\/patroni\/issues\/\">issues<\/a><\/noindex> auf GitHub. Dort gibt es viele verschiedene Geschichten und interessante Diskussionen zu Problemen. Am Ende wurden einige Bugs erfasst und gel\u00f6st, d. h. es ist eine spannende Lekt\u00fcre. <\/p>\n<p><\/p>\n<p>Dort gibt es interessante Geschichten dar\u00fcber, wie Menschen sich ins Bein schie\u00dfen. Sehr lehrreich. Man liest und versteht, dass man so etwas vermeiden sollte. Ich habe mir eine Notiz gemacht. <\/p>\n<p><\/p>\n<p>Ich m\u00f6chte ein gro\u00dfes Dankesch\u00f6n an die Firma Zalando aussprechen, insbesondere an Alexander Kukushkin und Alexey Klyukin, f\u00fcr die Unterst\u00fctzung dieses Projekts. Alexey Klyukin ist einer der Mitwirkenden, der nicht mehr bei Zalando arbeitet, aber das sind die zwei Personen, die mit diesem Produkt angefangen haben. <\/p>\n<p><\/p>\n<p>Ich halte Patroni f\u00fcr ein ganz tolles Tool. Ich bin froh, dass es existiert; es ist sehr interessant. Und ein gro\u00dfes Dankesch\u00f6n an alle Mitwirkenden, die Patches f\u00fcr Patroni schreiben. Ich hoffe, dass Patroni mit der Zeit reifer, besser und leistungsf\u00e4higer wird. Es funktioniert schon gut, aber ich hoffe, es wird noch besser. Wenn Sie also planen, Patroni zu verwenden, haben Sie keine Angst. Es ist eine gute L\u00f6sung, die Sie implementieren und verwenden k\u00f6nnen. <\/p>\n<p><\/p>\n<p>Das war's. Wenn Sie Fragen haben, stellen Sie diese bitte.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni-Fehlergeschichten oder Wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovsky\" src=\"\/wp-content\/uploads\/2020\/07\/85c2fef2455999b48413c9fc3b235ed6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Fragen<\/p>\n<p><\/p>\n<p><em>Danke f\u00fcr den Bericht! Wenn wir nach der automatischen Filesicherung trotzdem genau hinschauen m\u00fcssen, warum brauchen wir dann einen automatischen Filesicherer?<\/em> <\/p>\n<p><\/p>\n<p>Weil es sich um etwas Neues handelt. Wir arbeiten erst seit einem Jahr damit. Es ist besser, auf Nummer sicher zu gehen. Wir m\u00f6chten \u00fcberpr\u00fcfen, ob alles tats\u00e4chlich so funktioniert hat, wie es sollte. Das ist ein Zeichen von gesundem Misstrauen \u2013 besser noch einmal nachpr\u00fcfen. <\/p>\n<p><\/p>\n<p><em>Zum Beispiel haben wir morgens nachgesehen, richtig?<\/em><\/p>\n<p><\/p>\n<p>Nicht morgens, wir erfahren normalerweise fast sofort \u00fcber die automatische Filesicherung. Wir erhalten Benachrichtigungen und sehen, dass die automatische Filesicherung stattgefunden hat. Wir schauen fast sofort nach. Aber all diese \u00dcberpr\u00fcfungen sollten in das Monitoring \u00fcbertragen werden. Wenn man \u00fcber die REST API auf Patroni zugreift, gibt es eine Historie. Anhand dieser Historie kann man die Zeitstempel einsehen, wann die Filesicherung stattfand. Darauf basierend kann man das Monitoring einrichten. Man kann sehen, wie viele Ereignisse dort vorhanden sind. Wenn es mehr Ereignisse gibt, hat eine automatische Filesicherung stattgefunden. Man kann nachschauen. Oder unser Monitoring-System hat \u00fcberpr\u00fcft, dass alle Replikate vorhanden sind, keine Lag besteht und alles gut ist. <\/p>\n<p><\/p>\n<p><em>Danke!<\/em><\/p>\n<p><\/p>\n<p><em>Vielen Dank f\u00fcr die gro\u00dfartige Erz\u00e4hlung! Wenn wir den DCS-Cluster von dem Postgres-Cluster entfernen, muss dieser Cluster dann auch regelm\u00e4\u00dfig gewartet werden? Welche Best Practices gibt es in Bezug darauf, dass Teile des DCS-Clusters deaktiviert werden, was man damit machen sollte usw.? Wie funktioniert das gesamte System dabei? Und wie sollte man diese Aufgaben erledigen?<\/em><\/p>\n<p><\/p>\n<p>F\u00fcr ein Unternehmen war es notwendig, eine Problemmatrix zu erstellen, die beschreibt, was passiert, wenn einer oder mehrere Komponenten ausfallen. Anhand dieser Matrix gehen wir alle Komponenten durch und entwickeln Szenarien f\u00fcr den Ausfall dieser Komponenten. Entsprechend f\u00fcr jedes Ausfall-Szenario gibt es einen Aktionsplan zur Wiederherstellung. Im Fall von DCS ist dies Teil der Standardinfrastruktur. Der Administrator verwaltet dies, und wir verlassen uns bereits auf die Administratoren, die dies \u00fcberwachen, und auf ihre F\u00e4higkeiten, im Falle eines Ausfalls Reparaturen vorzunehmen. Wenn DCS nicht vorhanden ist, k\u00fcmmern wir uns um dessen Bereitstellung, aber wir \u00fcberwachen es nicht besonders, da wir nicht f\u00fcr die Infrastruktur verantwortlich sind, geben jedoch Empfehlungen, was und wie \u00fcberwacht werden sollte. <\/p>\n<p><\/p>\n<p><em>Das hei\u00dft, habe ich richtig verstanden, dass wir Patroni, den Fileserver und alles andere deaktivieren m\u00fcssen, bevor wir etwas mit den Hosts machen?<\/em><\/p>\n<p><\/p>\n<p>Das h\u00e4ngt davon ab, wie viele Knoten wir im DCS-Cluster haben. Wenn es viele Knoten gibt und wir nur einen Knoten (Replikat) au\u00dfer Betrieb nehmen, bleibt das Quorum im Cluster erhalten. Patroni bleibt funktionsf\u00e4hig und es wird nichts ausgel\u00f6st. Wenn wir jedoch komplexe Operationen durchf\u00fchren, die mehr Knoten betreffen und deren Abwesenheit das Quorum gef\u00e4hrden k\u00f6nnte, macht es vielleicht Sinn, Patroni vor\u00fcbergehend anzuhalten. Daf\u00fcr gibt es einen entsprechenden Befehl \u2013 patronictl pause, patronictl resume. Wir setzen es einfach auf Pause, und der Auto-Failover wird in dieser Zeit nicht aktiviert. Wir f\u00fchren dann Wartungsarbeiten am DCS-Cluster durch, heben die Pause auf und machen weiter.<\/p>\n<p><\/p>\n<p><em>Vielen Dank!<\/em><\/p>\n<p><\/p>\n<p><em>Vielen Dank f\u00fcr die Pr\u00e4sentation! Wie steht das Produktteam dazu, dass Daten verloren gehen k\u00f6nnten?<\/em> <\/p>\n<p><\/p>\n<p>Das Produktteam ist das egal, aber die Teamleiter machen sich Sorgen. <\/p>\n<p><\/p>\n<p><em>Welche Garantien gibt es daf\u00fcr?<\/em><\/p>\n<p><\/p>\n<p>Mit Garantien ist es sehr schwierig. Es gibt einen Bericht von Alexander Kukushkin mit dem Titel \u201eWie man RPO und RTO berechnet\u201c, also die Wiederherstellungszeit und wie viele Daten wir verlieren k\u00f6nnen. Ich denke, wir sollten diese Folien finden und sie studieren. Soweit ich mich erinnere, gibt es spezifische Schritte, wie man diese Dinge berechnet. Wie viele Transaktionen k\u00f6nnen wir verlieren, wie viele Daten k\u00f6nnen verloren gehen? Eine M\u00f6glichkeit w\u00e4re die Verwendung von synchroner Replikation auf der Stufe von Patroni, aber das ist ein zweischneidiges Schwert: Wir haben entweder Datenzuverl\u00e4ssigkeit oder verlieren an Geschwindigkeit. Es gibt zwar synchrone Replikation, aber sie garantiert auch keinen 100%-igen Schutz vor Datenverlust.<\/p>\n<p><\/p>\n<p><em>Alexey, danke f\u00fcr den gro\u00dfartigen Vortrag! Gibt es Erfahrungen mit der Verwendung von Patroni f\u00fcr den Zero-Level-Schutz? Also in Kombination mit einem synchronen Standby? Das ist die erste Frage. Und die zweite Frage: Sie haben verschiedene L\u00f6sungen genutzt. Wir haben Repmgr verwendet, aber ohne Auto-Failover und planen jetzt, Auto-Failover zu integrieren. Wir betrachten Patroni als alternative L\u00f6sung. Was k\u00f6nnen Sie als Vorteile im Vergleich zu Repmgr sagen?<\/em><\/p>\n<p><\/p>\n<p>Die erste Frage betraf die synchronen Replikate. Bei uns nutzt niemand die synchrone Replikation, weil die meisten Bedenken haben (einige Kunden verwenden sie bereits, und wir haben grunds\u00e4tzlich keine Leistungsprobleme bemerkt \u2014 <em>Hinweis des Referenten<\/em>). Aber wir haben f\u00fcr uns die Regel aufgestellt, dass in einem Cluster mit synchroner Replikation mindestens drei Knoten vorhanden sein sollten. Wenn wir nur zwei Knoten haben und ein Master- oder Replikat ausf\u00e4llt, versetzt Patroni diesen Knoten in den Standalone-Modus, damit die Anwendung weiterarbeiten kann. In diesem Fall gibt es Risiken f\u00fcr den Datenverlust.<\/p>\n<p><\/p>\n<p>Bez\u00fcglich der zweiten Frage haben wir Repmgr verwendet und setzen es aus historischen Gr\u00fcnden weiterhin bei einigen Clients ein. Was kann man dazu sagen? In Patroni gibt es den Auto-Failover standardm\u00e4\u00dfig, w\u00e4hrend bei Repmgr der Auto-Failover als zus\u00e4tzliche Funktion aktiviert werden muss. Es muss der Repmgr-Daemon auf jedem Knoten gestartet werden, und dann k\u00f6nnen wir den Auto-Failover einrichten. <\/p>\n<p><\/p>\n<p>Repmgr \u00fcberpr\u00fcft, ob die PostgreSQL-Knoten aktiv sind. Die Repmgr-Prozesse kontrollieren sich gegenseitig, was jedoch kein sehr effektiver Ansatz ist, da es komplexe F\u00e4lle von Netzwerktrennung geben kann, bei denen ein gro\u00dfer Repmgr-Cluster in mehrere kleine zerf\u00e4llt und weiterhin funktioniert. Ich habe schon lange nichts mehr \u00fcber Repmgr verfolgt; vielleicht wurde das behoben... vielleicht auch nicht. Die \u00dcbertragung von Informationen \u00fcber den Zustand des Clusters in DCS, wie es Stolon oder Patroni machen, ist jedoch die tragf\u00e4higste L\u00f6sung. <\/p>\n<p><\/p>\n<p><em>Alexej, ich habe eine vielleicht etwas naive Frage. In einem der ersten DCS-Beispiele haben Sie von einem lokalen Rechner auf einen Remote-Knoten \u00fcbertragen. Wir wissen, dass das Netzwerk Eigenschaften hat, die es einzigartig machen, es lebt f\u00fcr sich. Was passiert, wenn aus irgendeinem Grund der DCS-Cluster nicht mehr verf\u00fcgbar ist? Gr\u00fcnde m\u00f6chte ich nicht nennen, es kann viele geben: von ungeschickten Netzwerkadministratoren bis hin zu echten Problemen.<\/em> <\/p>\n<p><\/p>\n<p>Ich habe es nicht laut gesagt, aber der DCS-Cluster muss ebenfalls ausfallsicher sein, d. h. es sollte eine ungerade Anzahl von Knoten vorhanden sein, damit ein Quorum erreicht werden kann. Was passiert, wenn der DCS-Cluster nicht mehr verf\u00fcgbar ist oder das Quorum nicht erreicht werden kann, beispielsweise durch ein Netzwerk-Partition oder den Ausfall von Knoten? In diesem Fall wechselt der Patroni-Cluster in den Nur-Lesen-Modus. Der Patroni-Cluster kann den Zustand des Clusters und die erforderlichen Ma\u00dfnahmen nicht bestimmen. Er kann nicht mit dem DCS kommunizieren und den neuen Zustand des Clusters speichern, weshalb der gesamte Cluster in den Nur-Lesen-Modus wechselt. Er wartet entweder auf manuelles Eingreifen des Operators oder darauf, dass das DCS wiederhergestellt wird.<\/p>\n<p><\/p>\n<p><em>Um es einfach auszudr\u00fccken, wird DCS f\u00fcr uns zu einem Dienst, der ebenso wichtig ist wie die Datenbank selbst?<\/em><\/p>\n<p><\/p>\n<p>Ja, genau. In vielen modernen Unternehmen ist Service Discovery ein fester Bestandteil der Infrastruktur. Es wird sogar noch bevor eine Datenbank in der Infrastruktur vorhanden ist, implementiert. Um es vereinfacht zu sagen: Wir haben die Infrastruktur gestartet, uns im Rechenzentrum eingerichtet, und schon haben wir Service Discovery. Wenn es sich um Consul handelt, kann darauf auch DNS aufgebaut werden. Wenn es Etcd ist, k\u00f6nnte es Teil eines Kubernetes-Clusters sein, in dem dann alles andere bereitgestellt wird. Ich denke, dass Service Discovery bereits ein unverzichtbarer Bestandteil moderner Infrastrukturen ist. Dar\u00fcber wird oft viel fr\u00fcher nachgedacht als \u00fcber Datenbanken. <\/p>\n<p><\/p>\n<p><em>Danke!<\/em><\/p>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/512768\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041e\u0441\u043d\u043e\u0432\u043d\u0430\u044f \u0446\u0435\u043b\u044c Patroni \u2014 \u044d\u0442\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u0435 High Availability \u0434\u043b\u044f PostgreSQL. \u041d\u043e Patroni \u2014 \u044d\u0442\u043e \u043b\u0438\u0448\u044c template, \u0430 \u043d\u0435 \u0433\u043e\u0442\u043e\u0432\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 (\u0447\u0442\u043e, \u0432 \u043e\u0431\u0449\u0435\u043c, \u0438 \u0441\u043a\u0430\u0437\u0430\u043d\u043e \u0432 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438). \u041d\u0430 \u043f\u0435\u0440\u0432\u044b\u0439 \u0432\u0437\u0433\u043b\u044f\u0434, \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0432 Patroni \u0432 \u0442\u0435\u0441\u0442\u043e\u0432\u043e\u0439 \u043b\u0430\u0431\u0435, \u043c\u043e\u0436\u043d\u043e \u0443\u0432\u0438\u0434\u0435\u0442\u044c, \u043a\u0430\u043a\u043e\u0439 \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0438 \u043a\u0430\u043a \u043e\u043d \u043b\u0435\u0433\u043a\u043e \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043d\u0430\u0448\u0438 \u043f\u043e\u043f\u044b\u0442\u043a\u0438 \u0440\u0430\u0437\u0432\u0430\u043b\u0438\u0442\u044c \u043a\u043b\u0430\u0441\u0442\u0435\u0440. \u041e\u0434\u043d\u0430\u043a\u043e \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0432 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":90104,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-90103","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041e\u0441\u043d\u043e\u0432\u043d\u0430\u044f \u0446\u0435\u043b\u044c Patroni \u2014 \u044d\u0442\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u0435 High Availability \u0434\u043b\u044f PostgreSQL. \u041d\u043e Patroni \u2014 \u044d\u0442\u043e \u043b\u0438\u0448\u044c template, \u0430 \u043d\u0435 \u0433\u043e\u0442\u043e\u0432\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 (\u0447\u0442\u043e, \u0432 \u043e\u0431\u0449\u0435\u043c, \u0438 \u0441\u043a\u0430\u0437\u0430\u043d\u043e \u0432 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438). \u041d\u0430 \u043f\u0435\u0440\u0432\u044b\u0439 \u0432\u0437\u0433\u043b\u044f\u0434, \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0432 Patroni \u0432 \u0442\u0435\u0441\u0442\u043e\u0432\u043e\u0439 \u043b\u0430\u0431\u0435, \u043c\u043e\u0436\u043d\u043e \u0443\u0432\u0438\u0434\u0435\u0442\u044c, \u043a\u0430\u043a\u043e\u0439 \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0438 \u043a\u0430\u043a \u043e\u043d \u043b\u0435\u0433\u043a\u043e \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043d\u0430\u0448\u0438 \u043f\u043e\u043f\u044b\u0442\u043a\u0438 \u0440\u0430\u0437\u0432\u0430\u043b\u0438\u0442\u044c \u043a\u043b\u0430\u0441\u0442\u0435\u0440. \u041e\u0434\u043d\u0430\u043a\u043e \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0432 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041e\u0441\u043d\u043e\u0432\u043d\u0430\u044f \u0446\u0435\u043b\u044c Patroni \u2014 \u044d\u0442\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u0435 High Availability \u0434\u043b\u044f PostgreSQL. \u041d\u043e Patroni \u2014 \u044d\u0442\u043e \u043b\u0438\u0448\u044c template, \u0430 \u043d\u0435 \u0433\u043e\u0442\u043e\u0432\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 (\u0447\u0442\u043e, \u0432 \u043e\u0431\u0449\u0435\u043c, \u0438 \u0441\u043a\u0430\u0437\u0430\u043d\u043e \u0432 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438). \u041d\u0430 \u043f\u0435\u0440\u0432\u044b\u0439 \u0432\u0437\u0433\u043b\u044f\u0434, \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0432 Patroni \u0432 \u0442\u0435\u0441\u0442\u043e\u0432\u043e\u0439 \u043b\u0430\u0431\u0435, \u043c\u043e\u0436\u043d\u043e \u0443\u0432\u0438\u0434\u0435\u0442\u044c, \u043a\u0430\u043a\u043e\u0439 \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0438 \u043a\u0430\u043a \u043e\u043d \u043b\u0435\u0433\u043a\u043e \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043d\u0430\u0448\u0438 \u043f\u043e\u043f\u044b\u0442\u043a\u0438 \u0440\u0430\u0437\u0432\u0430\u043b\u0438\u0442\u044c \u043a\u043b\u0430\u0441\u0442\u0435\u0440. \u041e\u0434\u043d\u0430\u043a\u043e \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0432 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-07-29T11:42:32+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-07-29T11:42:32+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Patroni Failure Stories oder wie man seinen PostgreSQL-Cluster zum Absturz bringt. Alexey Lesovski | ProHoster","description":"Das Hauptziel von Patroni ist die Gew\u00e4hrleistung der hohen Verf\u00fcgbarkeit f\u00fcr PostgreSQL. Aber Patroni ist nur eine Vorlage und kein fertiges Werkzeug (was auch in der Dokumentation erw\u00e4hnt wird). Auf den ersten Blick kann man, nachdem man Patroni in einer Testumgebung konfiguriert hat, sehen, wie gro\u00dfartig dieses Werkzeug ist und wie einfach es unsere Versuche zur Zerschlagung des Clusters bew\u00e4ltigt. In der Praxis jedoch in der Produktionsumgebung...","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439 | ProHoster","og:description":"\u041e\u0441\u043d\u043e\u0432\u043d\u0430\u044f \u0446\u0435\u043b\u044c Patroni \u2014 \u044d\u0442\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u0435 High Availability \u0434\u043b\u044f PostgreSQL. \u041d\u043e Patroni \u2014 \u044d\u0442\u043e \u043b\u0438\u0448\u044c template, \u0430 \u043d\u0435 \u0433\u043e\u0442\u043e\u0432\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 (\u0447\u0442\u043e, \u0432 \u043e\u0431\u0449\u0435\u043c, \u0438 \u0441\u043a\u0430\u0437\u0430\u043d\u043e \u0432 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438). \u041d\u0430 \u043f\u0435\u0440\u0432\u044b\u0439 \u0432\u0437\u0433\u043b\u044f\u0434, \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0432 Patroni \u0432 \u0442\u0435\u0441\u0442\u043e\u0432\u043e\u0439 \u043b\u0430\u0431\u0435, \u043c\u043e\u0436\u043d\u043e \u0443\u0432\u0438\u0434\u0435\u0442\u044c, \u043a\u0430\u043a\u043e\u0439 \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0438 \u043a\u0430\u043a \u043e\u043d \u043b\u0435\u0433\u043a\u043e \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043d\u0430\u0448\u0438 \u043f\u043e\u043f\u044b\u0442\u043a\u0438 \u0440\u0430\u0437\u0432\u0430\u043b\u0438\u0442\u044c \u043a\u043b\u0430\u0441\u0442\u0435\u0440. \u041e\u0434\u043d\u0430\u043a\u043e \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0432 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-07-29T11:42:32+00:00","article:modified_time":"2020-07-29T11:42:32+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"90103","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:58:48","updated":"2026-02-09 16:50:35"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/90103","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=90103"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/90103\/revisions"}],"predecessor-version":[{"id":158759,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/90103\/revisions\/158759"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/90104"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=90103"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=90103"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=90103"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}