Kürzlich haben wir Alexei Lesovsky von Data Egret eingeladen, Zinc Sale zu übertragen . Das Gespräch erwies sich als interessant und informativ, daher biete ich Ihnen die Niederschrift dieser Ausgabe an. Aufgrund des beeindruckenden Volumens war es notwendig, den Text in Teile zu zerlegen. Wenn Sie zu faul sind, um auf die Fortsetzung zu warten, können Sie sich hier einfach die Audioversion anhören.
Hallo allerseits, dies ist die vierzigste Ausgabe des Zinc Prod-Podcasts, und Anton Okolelov, Nikita Vasilchenko und Oleg Gritsak sind ständige Gastgeber bei uns im Studio.
Anton : Also, heute haben wir einen Gast, Alexey Lesovsky. Lesha, bitte stell dich vor, wer du bist, was du tust und so weiter.
Alexei : Hallo zusammen, mein Name ist Alexei Lesovsky, wie Antokha mich bereits vorgestellt hat. Ich verwalte Postgres, ich bin PostgreSQL DBA (Datenbankadministrator), ich arbeite jeden Tag, 7 Tage die Woche mit dem Login und verwalte Client-Datenbanken. Wir haben ein Büro - es ist ein Beratungsunternehmen, es ist mit Verwaltung, Support und Support beschäftigt. Und sehr unterschiedliche Leute kommen mit ihren Datenbanken zu uns, in der Regel sind dies Unternehmen - klein, groß, klein, ganz unterschiedlich - sie haben Probleme mit der Datenbank, wir analysieren diese Probleme und versuchen sie irgendwie zu beheben. Tatsächlich lösen wir die Probleme anderer Menschen, anderer Unternehmen. Irgendwie so.
Nun, in meiner Freizeit mache ich gerne verschiedene Dinge, gehe durch den Wald, gehe snowboarden, wandern, trinke Bier
Anton : trink geräuchertes Bier
Nikita : Vor der Veröffentlichung sprach Lyokha über geräuchertes Bier
Alexei : Ja, geräuchertes Bier, es gibt so ein leckeres, empfehle ich. Rauchbier Merzen.
Anton : Ok, bitte sag mir, du Dbshnik, du arbeitest schon lange, mehrere Jahre. Wie schwer ist es Sie rufen dich nachts an und bitten dich, die Basis zu reparieren. Ich habe dich vor ungefähr einem oder einem halben Jahr um fünf Uhr morgens angerufen.
Alexei : Ja, es war eine Frage.
Anton : Wie überlebst du? Sag es mir
Alexey : Hör zu, ich arbeite seit 2014. Bis 2014 war ich als Linux-Administrator in der Webentwicklung tätig. Der Administrator hat eine Menge Dinge, wir hatten KVM-Virtualisierung, es gab eine Menge Linux, es gab alle Arten von Ruby-on-Rails, Nginxs, PHP, Rails ...
Oleg : Docker schon?
Alexey : docker hat gerade erst begonnen, wir haben es nirgendwo in der Produktion eingeführt, aber die Tendenzen dafür haben bereits begonnen.
Und es gab viele Postgres in unserem Büro. Dann jagte ich einen langen Rubel und entschied, dass ich gleichzeitig an zwei Jobs arbeiten könnte. Und er begann als Administrator in einem Moskauer Büro zu arbeiten. Ich habe zwei Werke zusammengefasst, da nur die Datenbanken von Postgresql consulting verwaltet wurden. Es gab Max Boguk, Ilya Kosmodemyansky, und als Administrator begann ich, einen Teil der mit der Botschaft verbundenen Aufgaben zu erledigen. Nun, d.h. Ich fing leise an, ihr Brot zu nehmen. Und irgendwann sagt Max zu mir: Hör zu und lass dich mit uns an die Arbeit machen. Sie werden alle Ihre Arbeit verlassen, Teilzeitjobs, Sie werden für Vollzeit zu uns kommen.
Nun, ich stimmte zu, ich zögerte nicht, im Prinzip wurde mir ein vergleichbares Gehalt angeboten, und ich bekam einen Job und fing an, von zu Hause aus zu arbeiten, und nun, seit 2014, stellte sich heraus, arbeite ich seit 5 Jahren, ich arbeite speziell mit dem Vater. Auf die alte Art arbeite ich aus Gewohnheit mit allen möglichen Admin-Themen. Das heißt Wenn es in unserer Firma ein Problem mit etwas gibt, das von der Administratorseite zu verstehen ist, werfen sie mich ab, ich verstehe
Anton : Aber im Allgemeinen ist es notwendig, diese Admin-Sachen zu kennen? Es ist nicht nur da, die Basis befindet sich im luftleeren Raum, es dreht sich irgendwo, Sie müssen das Betriebssystem konfigurieren, oder?
Alexei : Ja, ja, genau deshalb, weil er sich im Allgemeinen stark auf die Betriebssystem-Subsysteme, den virtuellen Speicher und die Datenträgerverwaltung verlässt, d. H. Es ist, als ob er selbst keine Ressourcen direkt bedient, als ob er all diese Arbeiten auf das Betriebssystem entlädt, und er selbst verwaltet die Datenträger-E / A, die Speicherseitenverwaltung, das ist alles, die Prozessumschaltung, und dementsprechend müssen Sie, wenn Sie auf ein Herunterfahren von Postgres stoßen Es gibt auch einen kleinen Hack im Betriebssystem, wie alles dort funktioniert und wie es an der Schnittstelle mit Postgres funktioniert.
Wenn zum Beispiel mit Oracle verglichen wird, hat Oracle zum Beispiel seine eigenen Subsysteme, die mit Eingabe-Ausgabe arbeiten, d.h. Sie sind hinter dem Betriebssystem, sie können direkt mit der Festplatte arbeiten, aber in Posgres ist dies nicht, Sie müssen wissen, wie das Betriebssystem mit der Datenbank funktioniert.
Oleg : Musstest du postgres unter Windows unterstützen?
Alexei : Ja, ich musste, wir haben einen Kunden, sie arbeiten mit Windows, wir haben in einer Art St. Petersburg-Büro gearbeitet und eine Prüfung der Datenbank für sie durchgeführt. Ihre Basis war Windows, es war im Allgemeinen beängstigend, wir haben über das Terminalprotokoll eine Verbindung zu einem Protokoll hergestellt, Remote Desktop geöffnet und dort einige Dinge im Zusammenhang mit der Aufzeichnung der Leistung gestartet. Kurz gesagt, es war schwer, beängstigend, wie ein schrecklicher Traum jetzt erinnert wird. Und jetzt sitzen die Kunden im Grunde alle auf Linux. Praktisch niemand ist unter Windows.
Oleg : Was ist der Hauptschmerz bei Postgre, den jeder bemerken kann?
Alexey : Viele Leute wollen einen Auto-Filer und einen Multi-Master. Na ja, Multimaster natürlich so etwas, unerreichbar. Aber alle haben mit Galera (mit Mysql) gearbeitet und sie sagen: Warum wollen wir auch einen Multimaster im Gange?
Nun, im Fortschritt gibt es solche Dinge, aber nicht im progressiven Kern selbst, es gibt solche Dinge, die den Multimaster-Typ implementieren, aber noch gar nicht produziert wurden. Aber die Leute wollen einen Multimaster. Und die Leute wollen auch einen Auto-Filer. Aber jetzt, Gott sei Dank, ist Patroni aufgetaucht. Auf Patroni können Sie einen Auto-Filer erstellen. Die Leute führen ihn langsam ein. Nun, aus meiner Sicht ist Patroni im Allgemeinen zum De-facto-Standard geworden. Viele große Unternehmen setzen es bereits um. Das gleiche Gitlab, sie haben kürzlich Berichte erstellt, sie verwenden Patroni, sie sind mit allem zufrieden, jeder ist glücklich.
Anton : Hören Sie, können Sie uns auf den Punkt bringen, was Kunden für einfache Programmierer sind? Wir hören hauptsächlich Teamleitern und Programmierern zu
Nikita : Warte, darf ich dich töten, und ich werde Nicht-Programmierer noch mehr bitten, zu erklären, was ein Multimaster ist
Alexei : Sehen Sie, stellen Sie sich jetzt vor, Antokha ist ein Programmierer, er schreibt Anwendungen und die Anwendung muss ihre Daten irgendwo speichern. Er legt sie in die Basis, in die Botschaft. Irgendwann befindet sich die Datenbank auf einem Server und dann einmal auf dem Server - und funktioniert nicht mehr. Das Netzteil ist durchgebrannt und die Anwendung muss mit der Basisstation weiterarbeiten. Und hier ergibt sich die Option, dass wir eine Art Kopie der Datenbank benötigen, um weiter damit arbeiten zu können. Wechseln Sie entweder dorthin, und führen Sie im Idealfall keinen Wechsel durch, damit unsere Anwendung von dieser zweiten Basis weiß und weiterhin darauf schreibt.
Dies ist eigentlich ein Multimaster, wenn wir mehrere Knoten zum Lesen und Schreiben zur Verfügung haben und unsere Anwendung gleichzeitig damit arbeiten und Daten auf einen dieser Knoten schreiben und Daten von diesen Knoten lesen kann, aber die Natur ist so angeordnet, dass es so ist nicht ganz im Idealfall erreicht, und es gibt Vor- und Nachteile, es gibt Nachteile, eigene Anwendungsfälle für die Verwendung des Multimasters. Das häufigste Beispiel ist, dass Sie nicht relativ gesehen dieselben Daten in zwei Instanzen schreiben können, z. B. mit derselben Tabelle arbeiten, über zwei Server in dieselbe Tabelle schreiben, Konflikte auftreten und diese gelöst werden müssen. Dies ist ein Problem Daher ist es notwendig zu schreiben, wenn wir in eine Tabelle schreiben, dann schreiben wir nur über einen Server.
Nikita : und das hängt direkt mit dem Auto-Fan zusammen, ja, ist er verbunden?
Alexei : Ja, und das liegt am Autofeldspieler, hier folgt sozusagen einer aus dem anderen. Wenn wir uns keinen Multimaster leisten können, wollen wir einen transparenten Mechanismus, der den Ersatzknoten in den Master-Modus schaltet, d. H. Wir haben eine Anwendung, die funktioniert, und sobald die Anwendung aus der Datenbank entfernt wurde, möchte der Entwickler die Konfiguration dieser Anwendung nicht ändern und die neue Datenbankadresse dort angeben. Starten Sie die Anwendung neu, insbesondere, wenn viele Anwendungen vorhanden sind. Ich möchte eine Art transparenten Mechanismus, der irgendwo unter der Haube funktioniert, die Datenbank wechselt und unsere Anwendung mit derselben Adresse arbeitet und weiter aus dieser Datenbank liest. Zu diesem Zweck benötigen Sie bereits einen Auto-Filer, der den Ersatzknoten transparent in den Assistentenmodus versetzt. Hierzu wird nur Patroni verwendet
Anton : Ist Patroni ein reiner Schalter oder eine Gabel aus Postgres, eine Art Add-On?
Alexei : Dies ist sozusagen ein separater Dienst, ein separater Prozess, der auf einem Host mit einer Datenbank ausgeführt wird. Und er überwacht den Status des Post-Cluster-Clusters. Dabei werden zwei Ziele verfolgt - Autofailover und Cluster-Management. In diesem Fall erhalten wir jedoch einen verteilten Cluster, der jedoch mehrere Knoten, einen Master und mehrere Replikate enthält. Dementsprechend müssen Sie den Status des Clusters ständig überwachen und feststellen, ob der Master am Leben ist. Wenn er plötzlich stirbt, müssen Sie in die Rolle eines "Masters" eines anderen Servers wechseln. Und dafür gibt es im Allgemeinen zwei Ansätze, wie man diesen Ansichtscluster unterstützt, die Darstellung in dem Cluster, wie er im Moment leben soll. Es gibt eine Option, wenn die Clusterknoten sich gegenseitig überprüfen. Und Sie können diesen Zustand außerhalb speichern, d.h. Außerhalb des Clusters. Und nur Patroni nutzt diesen Ansatz und speichert den Zustand des Clusters im dritten System. Dies ist normalerweise eine Art DCS (Distributed Storage System Configuration). Es kann etcd, consul oder es kann kuberenetesovsky etcd sein. Das heißt je nachdem was die infrastruktur ist. Nun und dementsprechend speichert Patroni einfach einen Clusterstatus in diesem DCS-System und aktualisiert ihn.
Wenn plötzlich einer der Knoten plötzlich ausfällt, wird ein neuer Knoten ausgewählt. Fällt dieser Master beispielsweise aus, wird ein neuer Master ausgewählt und dieser Zustand in DCS erneut aktualisiert. Und hier unterstützt Patroni auf Kosten von DCS die Gesundheit des Clusters.
Anton : Und wenn das Netzwerk zwischen Patroni und der Basis blinzelte?
Alexei : Nun, sehen Sie, es gibt eine Datenbank, es ist entweder eine Art Server, oder es kann, sagen wir, in den Kubernetes eine Art Sub sein. Angenommen, es handelt sich um einen Server. Auf demselben Server wird eine Datenbank ausgeführt, und auf demselben Server wird der Patroni-Agent ausgeführt. Dies ist ein einfacher Prozess, sie arbeiten auf demselben Host und kommunizieren relativ sprechend auf localhost. Unser Netzwerk blinkt möglicherweise zwischen dem DCS-Repository und dem Host, auf dem die Basis und Patroni arbeiten.
Es kann verschiedene Möglichkeiten geben. Abhängig davon, wie stark dieses Netzwerkblinken ist. Wenn es sich um einen Master handelte und sich herausstellte, dass er isoliert war, stellen die anderen Knoten fest, dass der Master nicht mehr vorhanden ist. Sie wählen einfach einen neuen Master aus, und er sieht den alten Master, von dem er isoliert ist, und Patroni startet ihn im schreibgeschützten Modus neu. Nun, damit es kein gespaltenes Gehirn gibt. Es ist schlecht, wenn unsere Anwendung gleichzeitig auf zwei Knoten schreibt. Dann müssen die Entwickler die Daten rechen, und dies ist eine sehr schwierige Arbeit - um diese Daten in einer konsistenten Form zu sammeln. Daher startet das Spannfutter den Knoten nur mit Lesezugriff neu und das wars und es funktioniert. Sobald das Netzwerk wiederhergestellt ist, wird Patroni in der Lage sein, DCS zu erreichen, die Cluster-Ansicht dort weiter zu koordinieren und eine vereinbarte Lösung zu finden. Höchstwahrscheinlich wird dieser isolierte Knoten, der ein alter Master war, als Replikat mit dem neuen Master verbunden ...
Anton . Wie funktioniert das in der Praxis? Gibt es irgendwelche Probleme, Fallstricke. Damit Oleg beispielsweise Patroni übernehmen und umsetzen kann, muss er eine Entscheidung treffen.
Oleg . Ja, sofort
Alexey . Schauen Sie, wir setzen Patroni seit letztem Jahr bei Kunden ein. Wir haben den ersten Kunden meiner Meinung nach im November 2018 erschienen. Und zu diesem Zeitpunkt hatten wir noch keine sehr gute Vorstellung davon, wie wir damit arbeiten sollten, aber für das Jahr, in dem wir gearbeitet haben, passt im Prinzip alles zu uns. Wir haben gelernt, wie man es kocht. Grundsätzlich sind, um es in Erinnerung zu rufen, nicht viele Schritte erforderlich, buchstäblich zwei oder drei Aktionen von der Seite von postgres, von der Seite der Benutzerkonfigurationen, und all dies funktioniert ziemlich gut.
Das Stück ist zuverlässig. Es ist zunächst einfach, es ist in Python geschrieben, es verbraucht wenig Speicher und arbeitet im Prinzip zuverlässig. Das einzige in der Infrastruktur sollte dieses DCS sein. Aber in der Regel ist entweder Consul oder etcd notwendig. Aber für viele Unternehmen wird dieses Ding bereits für die unterschiedlichsten Service-Discovery-Vorgänge verwendet, daher gibt es in der Regel keine Probleme damit.
Und was für Probleme entstehen: Das grundlegendste Problem, das die Leute nicht sofort haben, ist, dass wir mit dem Auto-Filer einen Teil der Daten verlieren können
Oleg : wegen der Replikationsverzögerung?
Alexei : Stellen Sie sich eine Situation vor, in der ein Auto-Filer während der Replikation auftritt. Der alte Master ist offline gegangen, aber wir haben immer noch einen Teil der Daten in ihn geschrieben. Angenommen, es liegt eine Replikationsverzögerung vor, ein neuer Master wird aus anderen Replikaten ausgewählt. Ein neuer Master wird ausgelöst, und wenn Patroni so konfiguriert ist, dass der ausgefallene Knoten automatisch in den Cluster aufgenommen wird, z. B., dass der Autostart von Diensten aktiviert wird. Wenn der alte Master ausgelöst wird, stellt er fest, dass er kein Master mehr ist und sich mit dem neuen Master verbindet und werde sein Stichwort. In diesem Moment führt er den Befehl pg_rewind aus.
Dieser Befehl spult das Transaktionsprotokoll auf dem alten Knoten (dem alten Master) zurück, bis eine Verbindung zum neuen Master hergestellt werden kann, dh das Transaktionsprotokoll wird überschrieben. An diesem Punkt können wir einige der Daten verlieren. In Patroni selbst gibt es wenig Schutz, es gibt einige Wendungen, die es Repliken ermöglichen, nicht an Wahlen mit großem Rückstand teilzunehmen. Wenn beispielsweise alle Replikate eine große Verzögerung aufweisen, werden die Wahlen einfach nicht eingeleitet, und der Administrator muss manuell eingreifen, damit der Administrator die automatische Datei von Hand starten kann. Oder sie warten alle, bis der alte Meister aufsteht. Bis seine Arbeit wiederhergestellt ist. Und sie werden bereits damit verbunden sein und es weiterhin fangen.
Nun, das heißt, in Patroni gibt es Mechanismen, die es Ihnen ermöglichen, keine Daten zu verlieren, aber es gibt ein Risiko, also müssen Sie vorsichtig sein
Anton : Was ist mit der synchronen Replikation?
Alexei : Sie sehen, wenn wir die synchrone Replikation verwenden, verlieren wir die Leistung. Nicht jeder kann diesen Deal machen. Wenn wir jedoch die synchrone Replikation verwenden, wird das Risiko eines Datenverlusts verringert. Wenn wir jedoch mehrere Knoten verwenden, z. B. mehr als zwei, müssen wir die Option weiterhin in Betracht ziehen, wenn sowohl auf dem Master als auch auf dem synchronen Replikat ein Unfall aufgetreten ist. Und wir haben noch eine zweite Replik, und es könnte sich herausstellen, dass wir sie einfangen und einige Daten wieder verlieren können. Verschiedene Optionen sind möglich, sie müssen bewertet, betrachtet und verstanden werden, ob ein solches Verhalten zu uns passt oder nicht.
Anton : Hör zu, nur zwei Server fallen ab - es ist wie eine Invasion von Außerirdischen
Aleksey : und die alte Frau hat einen Slammer
Oleg : Erinnern Sie sich noch an denselben Anruf um fünf Uhr morgens nach Lesha zum letzten Mal, mit dem es interessanterweise zu tun hatte, Anton, und nicht, dass wir sofort zwei Stützpunkte verloren haben?
Anton : Es war ein menschlicher Faktor. Nun ja, das passiert.
Alexey : Ich kann mich übrigens nicht an den Grund für den Anruf erinnern
Anton : Wir haben zwei Server dorthin transferiert, sie haben parallel gearbeitet, Daten aufgezeichnet, das ist egal. Und die Systeme könnten auf einem funktionieren, aber eines wurde in ein anderes Rechenzentrum übertragen und eingeschaltet. Der zweite wurde so weit transportiert, und dort wurde zum Zeitpunkt der Installation eine Art Verkabelung berührt, und der alte wurde ebenfalls abgeschnitten - sie mischten etwas durch. Im Allgemeinen fielen wir zwei Server aus, begannen zu steigen, und da sie für die Aufzeichnung starr konfiguriert waren, hatten sie sehr seltene Checkpoints oder ähnliches. Es hat lange angefangen, wir haben nicht verstanden, was geschah
Oleg : einhundert Gigs Wal-Logs
Anton : Wir haben nicht verstanden, was passiert ist, warum es nicht gestartet ist, und deshalb musste ich einen Anruf tätigen. Naja, eigentlich gab es nichts besonderes zu tun ...
Alexei : Nun, es gibt das Einzige, was wir wahrscheinlich verbunden haben. Wir haben gesehen, dass alles in Ordnung ist
Oleg : bestätigte den Tod des Patienten
Anton : Tatsächlich musstest du im Großen und Ganzen nur warten.
Alexey . Ja, das ist ein bekanntes Problem. Bei einigen Einstellungen sind die Prüfpunkte lang. Es gibt so ein Problem.
Aber wenn Sie sich an diesen Nachtanruf erinnern, haben wir in der Praxis selten einen Nachtanruf, sondern eine spezielle Automatisierung eingerichtet - im Einsatz ist alles so, wie es sein sollte, ausgewählt nach einem speziellen Zeitplan. Also, wenn Sie sich erinnern, wird vielleicht einmal alle sechs Monate jemand anrufen
Oleg : Alles aus unserer Firma ist wahrscheinlich
Alexey : Nein, anders
Anton : Oleg, ruf öfter an
Oleg : Wir werden heute umstellen. Ich werde wahrscheinlich anrufen
Alexey : Wir haben Leute, ihre Abendzeit geht zu Ende, sie werden einfach arbeiten
Anton : Hör zu, Lech, du hast gesagt, Patroni hat einige Analoga. Wie unterscheiden sie sich, was sind sie?
Alexey : Grundsätzlich gibt es zwei Möglichkeiten, es gibt repmgr, diese Sache ist vor langer Zeit aufgetaucht, vor ungefähr 10 Jahren. Es implementiert einen Mechanismus, wenn die Knoten eines Post-Grace-Clusters sich gegenseitig überprüfen, wer lebt, wer nicht lebt. Aber meiner Meinung nach ist das nicht sehr, ich mag dieses Arbeitsschema nicht wirklich.
Und es ist kein Auto-Filer im Auslieferungszustand, repmgr wurde ursprünglich speziell für die Verwaltung des Clusters und für die manuelle Umschaltung für die Umschaltung geschärft. Und wenn Sie direkt automatisch filern möchten, müssen Sie die Demoversion repmgrd separat installieren, und, wie sich herausstellt, wird die automatische Datei hier gestartet. Die Sache ist praktisch, gut, aber ja - wir haben keinen Auto-Filer im Auslieferungszustand. Sie müssen es separat setzen. Im Allgemeinen ist das Ding gut, praktisch, in dem Sinne, dass es gut konfigurierbar ist, es ist praktisch, clusterbasierte Cluster zu verwalten. Sie ist so flexibel, anpassbar. Repliken können auf verschiedene Arten gegossen werden. Von Backups, von Replikaten bis zu anderen, vom Master. Kurz gesagt, so eine flexible Sache, weil 10 Jahre. Und viele verschiedene Features wurden eingebaut, es ist sehr gut.
Eine weitere Option ist Stolon. Er erschien ungefähr zur gleichen Zeit wie Patroni, etwas später. Es ist auf Go geschrieben.
Aber es hat eine verzweigtere Architektur. Wenn Sie die Projektwebsite öffnen, werden Bilder angezeigt, und Stolon selbst besteht aus mehreren Komponenten. Er hat Keeper-Knoten, die mit Datenbanken arbeiten, die Postges auslösen. Dann gibt es die sogenannten Sentinel-Knoten. Sie überwachen den Status des Clusters, überprüfen dessen Verfügbarkeit und stellen sicher, dass die Knoten aktiv oder nicht aktiv sind. Sie verwalten den Status des Clusters und konfigurieren ihn neu, wenn etwas passiert.
Und es gibt sogenannte Proxy-Knoten, über die der gesamte Datenverkehr läuft. Die Client-Anwendung arbeitet mit Proxys. -, - , . Das heißt . , , Stolon DCS, consul, etcd. - .
, - , bare metal , , - , . . ( -) , , .
, . . , . , . oltp- . Stolon , .
, 6 8, . , , . , — wal_keep_segments — - , , , . , - . , . . Das heißt , . , , . , — . .
: , , - Citus? , .
: Citus — . Citus , CitusDB, -. , , ,
: ?
: , , . . , pg autofailover. , . , , . , , . , , . , , . Das heißt .
: Citus. , , . — , ...
: , ,
: , , , , ,
: , , . , , , . "in the wild" . , .
, " " , !