Ich schlage vor, dass Sie das Transkript des Berichts von Andrey Borodin vom Anfang 2019 „Backups mit WAL-G. Was gibt es im Jahr 2019?“ lesen.
Hallo zusammen! Mein Name ist Andrey Borodin. Ich bin Entwickler bei Yandex. Ich interessiere mich seit 2016 für PostgreSQL, nachdem ich mit den Entwicklern gesprochen hatte und sie sagten, dass alles einfach sei – man nehme den Quellcode und baue ihn, und alles werde klappen. Und seitdem kann ich nicht mehr aufhören – ich schreibe die unterschiedlichsten Dinge.
Eines der Dinge, an denen ich arbeite, ist ein Backup-System. . Generell arbeiten wir bei Yandex schon sehr lange an Backup-Systemen in PostgreSQL. Und im Internet finden Sie eine Reihe von sechs Berichten darüber, wie wir Backup-Systeme herstellen. Und jedes Jahr entwickeln sie sich ein wenig weiter, entwickeln sich ein wenig und werden zuverlässiger.
Aber heute geht es in dem Bericht nicht nur darum, was wir getan haben, sondern auch darum, wie einfach es ist und was es ist. Wie viele von euch haben meine Berichte über WAL-G bereits gesehen? Es ist gut, dass etliche Leute nicht zugeschaut haben, denn ich fange mit der einfachsten Sache an.
Wenn Sie plötzlich einen PostgreSQL-Cluster haben und ich glaube, jeder hat ein paar davon dabei, und plötzlich gibt es noch kein Backup-System, dann müssen Sie sich einen S3-Speicher oder einen Google Cloud-kompatiblen Speicher besorgen.
Kommen Sie zum Beispiel an unseren Stand und holen Sie sich einen Aktionscode für Yandex Object Storage, das S3-kompatibel ist.
Erstellen Sie dann einen Bucket. Es ist nur ein Container für Informationen.
Erstellen Sie einen Dienstbenutzer.
Erstellen Sie einen Zugriffsschlüssel für den Dienstbenutzer: aws-s3-key.
Laden Sie die neueste stabile Version von WAL-G herunter.
Wie unterscheiden sich unsere Vorabversionen von Veröffentlichungen? Ich werde oft gebeten, früher entlassen zu werden. Und wenn die Version über einen ausreichenden Zeitraum hinweg, beispielsweise einen Monat lang, keinen Fehler aufweist, veröffentliche ich sie. Hier ist diese Veröffentlichung vom November. Und das bedeutet, dass wir jeden Monat einen Fehler gefunden haben, normalerweise in unkritischen Funktionen, aber wir haben noch keine Version veröffentlicht. Die vorherige Version ist erst November. Es sind uns keine Fehler darin bekannt, d. h. es wurden im Laufe des Projekts Fehler hinzugefügt.
Sobald Sie WAL-G heruntergeladen haben, können Sie einen einfachen Befehl „Backup-Liste“ ausführen und dabei die Umgebungsvariablen übergeben. Und es stellt eine Verbindung zum Objektspeicher her und teilt Ihnen mit, über welche Backups Sie verfügen. Zunächst sollten Sie natürlich keine Backups haben. Der Sinn dieser Folie besteht darin, zu zeigen, dass alles ganz einfach ist. Dies ist ein Konsolenbefehl, der Umgebungsvariablen akzeptiert und Unterbefehle ausführt.
Danach können Sie Ihr erstes Backup erstellen. Sagen Sie „backup-push“ in WAL-G und geben Sie in WAL-G den pgdata-Speicherort Ihres Clusters an. Und höchstwahrscheinlich wird Ihnen PostgreSQL mitteilen, dass Sie den „Archivmodus“ aktivieren müssen, wenn Sie noch kein Backup-System haben.
Das bedeutet, dass Sie zu den Einstellungen gehen und „archive_mode = on“ aktivieren und „archive_command“ hinzufügen müssen, was auch ein Unterbefehl in WAL-G ist. Aber aus irgendeinem Grund verwenden die Leute zu diesem Thema oft Taktskripte und wickeln es um WAL-G. Bitte tun Sie das nicht. Nutzen Sie die Funktionalität von WAL-G. Wenn Ihnen etwas fehlt, schreiben Sie an . WAL-G geht davon aus, dass es das einzige Programm ist, das in archive_command ausgeführt wird.
Wir verwenden WAL-G hauptsächlich zum Erstellen eines Hochverfügbarkeitsclusters in der Yandex-Datenbankverwaltung.
Und es wird normalerweise in einer Topologie aus einem Master und mehreren Replikationen verwendet. Gleichzeitig wird eine Sicherungskopie im Yandex Object Storage erstellt.
Die häufigsten Szenarios sind die Erstellung von Kopien eines Clusters mithilfe der Point-in-Time-Wiederherstellung. In diesem Fall ist die Leistung des Backup-Systems für uns jedoch nicht so wichtig. Wir müssen nur einen neuen Cluster aus dem Backup hochladen.
Normalerweise benötigen wir beim Hinzufügen eines neuen Knotens eine Sicherung der Systemleistung. Warum ist es wichtig? Normalerweise fügen Benutzer einem Cluster einen neuen Knoten hinzu, weil der vorhandene Cluster die Leselast nicht bewältigen kann. Sie müssen eine neue Replik hinzufügen. Wenn wir die Last von pg_basebackup zum Master hinzufügen, kann es sein, dass der Master zusammenbricht. Daher war es für uns sehr wichtig, dass wir schnell einen neuen Knoten aus dem Archiv hochladen können und so den Master nur minimal belasten.
Und noch eine ähnliche Situation. Dies ist die Notwendigkeit, den alten Master neu zu starten, nachdem der Cluster-Master vom Rechenzentrum, mit dem die Verbindung unterbrochen wurde, gewechselt wurde.
- Daher haben wir bei der Formulierung der Anforderungen an das Kopiersystem festgestellt, dass pg_basebackup für uns beim Betrieb in der Cloud nicht geeignet ist.
- Wir wollten unsere Daten komprimieren können. Aber fast jedes Backup-System außer dem, das im Lieferumfang enthalten ist, bietet Datenkomprimierung.
- Wir wollten alles parallelisieren, da ein Benutzer in der Cloud eine große Anzahl von Prozessorkernen kauft. Wenn wir jedoch bei einigen Vorgängen keine Parallelität haben, werden viele Kerne unbrauchbar.
- Wir brauchen eine Verschlüsselung, da die Daten oft nicht uns gehören und nicht im Klartext gespeichert werden können. Unser Beitrag zu WAL-G begann übrigens mit der Verschlüsselung. Wir haben die Verschlüsselung in WAL-G abgeschlossen, woraufhin wir gefragt wurden: „Vielleicht entwickelt einer von uns das Projekt?“ Und seitdem arbeite ich seit mehr als einem Jahr mit WAL-G zusammen.
- Wir brauchten auch eine Ressourcendrosselung, denn im Laufe der Zeit haben wir bei der Nutzung der Cloud herausgefunden, dass Menschen manchmal nachts eine wichtige Menge Lebensmittel einkaufen müssen und diese Belastung nicht beeinträchtigt werden kann. Aus diesem Grund haben wir die Ressourcendrosselung hinzugefügt.
- Sowie Listung und Verwaltung.
- Und Verifizierung.
Wir haben uns viele verschiedene Tools angeschaut. Glücklicherweise haben wir eine riesige Auswahl in PostgreSQL. Und überall fehlte uns etwas, eine kleine Funktion, ein kleines Feature.
Und nachdem wir die bestehenden Systeme untersucht hatten, kamen wir zu dem Schluss, dass wir WAL-G entwickeln werden. Damals war es ein neues Projekt. Es war recht einfach, Einfluss auf die Entwicklung hin zur Cloud-Infrastruktur des Backup-Systems zu nehmen.
Die Hauptideologie, an der wir festhalten, ist, dass WAL-G so einfach wie eine Balalaika sein sollte.
WAL-G hat 4 Befehle. Das:
WAL-PUSH – den Schacht archivieren.
WAL-FETCH – hol dir einen Schaft.
BACKUP-PUSH – Erstellen Sie ein Backup.
BACKUP-FETCH – Holen Sie sich ein Backup vom Backup-System.
Tatsächlich verfügt WAL-G auch über die Verwaltung dieser Backups, d. h. das Auflisten und Löschen von Datensätzen und Backups im Verlauf, die im Moment nicht mehr benötigt werden.
Eine der für uns wichtigen Funktionen ist die Funktion der Erstellung von Deltakopien.
Delta-Kopien bedeuten, dass wir kein vollständiges Backup des gesamten Clusters erstellen, sondern nur die geänderten Seiten der geänderten Dateien im Cluster. Es scheint, dass dies funktional der Fähigkeit zur Wiederherstellung mithilfe von WAL sehr ähnlich ist. Aber wir können parallel ein WAL-Single-Threaded-Delta-Backup durchführen. Wenn wir also am Samstag ein Basis-Backup und täglich Delta-Backups erstellen lassen und es am Donnerstag zu einem Ausfall kommt, müssen wir 4 Delta-Backups und 10 Stunden WAL aufrollen. Es wird ungefähr die gleiche Zeit dauern, da die Delta-Backups parallel laufen.
LSN-basierte Deltas – das bedeutet, dass wir beim Erstellen eines Backups jede Seite kombinieren und ihre LSN mit der LSN des vorherigen Backups überprüfen müssen, um zu verstehen, dass sie sich geändert hat. Jede Seite, die möglicherweise geänderte Daten enthalten könnte, sollte im Delta-Backup vorhanden sein.
Wie gesagt, es wurde sehr viel Wert auf Parallelität gelegt.
Aber die Archiv-API in PostgreSQL ist konsistent. PostgreSQL archiviert eine WAL-Datei und fordert beim Wiederherstellen eine WAL-Datei an. Wenn die Datenbank jedoch mit dem Befehl „WAL-FETCH“ eine WAL-Datei anfordert, rufen wir den Befehl „WAL-PREFETCH“ auf, der die nächsten 8 Dateien vorbereitet, um parallel Daten aus dem Objektspeicher abzurufen.
Und wenn die Datenbank uns auffordert, eine Datei zu archivieren, schauen wir uns archive_status an und prüfen, ob es andere WAL-Dateien gibt. Und wir versuchen parallel auch, WAL herunterzuladen. Dies sorgt für einen erheblichen Leistungsgewinn und verringert den Abstand in der Anzahl der nicht archivierten WALs erheblich. Viele Entwickler von Backup-Systemen glauben, dass dies ein so riskantes System ist, weil wir uns auf unser Wissen über die Interna von Code verlassen, der nicht die PostgreSQL-API ist. PostgreSQL garantiert uns nicht das Vorhandensein des Ordners archive_status und garantiert nicht die Semantik, das Vorhandensein von Bereitschaftssignalen für WAL-Dateien dort. Dennoch studieren wir den Quellcode, sehen, dass dies so ist, und versuchen, ihn auszunutzen. Und wir kontrollieren die Richtung, in die sich PostgreSQL entwickelt; wenn dieser Mechanismus plötzlich kaputt geht, werden wir ihn nicht mehr verwenden.
In seiner reinen Form erfordert das LSN-basierte WAL-Delta das Lesen aller Clusterdateien, deren Moduszeit im Dateisystem sich seit der vorherigen Sicherung geändert hat. Damit haben wir lange gelebt, fast ein Jahr. Und am Ende kamen wir zu dem Schluss, dass wir WAL-Deltas haben.
Das bedeutet, dass wir jedes Mal, wenn wir WAL auf dem Master archivieren, es nicht nur komprimieren, verschlüsseln und an das Netzwerk senden, sondern es auch gleichzeitig lesen. Wir analysieren und lesen die darin enthaltenen Aufzeichnungen. Wir verstehen, welche Blöcke sich geändert haben und sammeln Delta-Dateien.
Eine Delta-Datei beschreibt einen bestimmten Bereich von WAL-Dateien und beschreibt Informationen darüber, welche Blöcke in diesem Bereich von WAL geändert wurden. Und dann werden diese Deltadateien auch archiviert.
Hier stehen wir vor der Tatsache, dass wir alles ziemlich schnell parallelisiert haben, aber wir können den sequentiellen Verlauf nicht parallel lesen, weil wir in einem bestimmten Segment möglicherweise auf das Ende des vorherigen WAL-Datensatzes stoßen, mit dem wir noch nichts zu verbinden haben, weil Paralleles Lesen führte dazu, dass wir zunächst die Zukunft analysieren, die noch keine Vergangenheit hat.
Infolgedessen mussten wir unverständliche Teile in _delta_partial-Dateien einfügen. Wenn wir in die Vergangenheit zurückkehren, werden wir daher die Teile des WAL-Datensatzes zu einem zusammenfügen, ihn anschließend analysieren und verstehen, was sich darin geändert hat.
Wenn es in der Geschichte unserer Schachtanalyse mindestens einen Punkt gibt, an dem wir nicht verstehen, was passiert ist, dann werden wir beim nächsten Backup entsprechend gezwungen sein, den gesamten Cluster erneut zu lesen, genau wie wir es bei einem regulären LSN getan haben -basiertes Delta.
All unser Leid führte dazu, dass wir die WAL-G-Parsing-Bibliothek als Open-Source-Lösung bereitgestellt haben. Soweit ich weiß, verwendet es noch niemand, aber wenn jemand es schreiben und verwenden möchte, ist es gemeinfrei. (Aktualisierter Link )
Dadurch sehen alle Informationsflüsse recht kompliziert aus. Unser Meister archiviert den Schacht und archiviert Deltadateien. Und das Replikat, das die Sicherungskopie erstellt, muss während der zwischen den Sicherungen verstrichenen Zeit Deltadateien erhalten. In diesem Fall müssen Teile des Verlaufs in großen Mengen hinzugefügt und analysiert werden, da nicht der gesamte Verlauf in große Segmente passt. Und erst danach kann das Replikat ein vollständiges Delta-Backup archivieren.
Auf den Grafiken sieht alles viel einfacher aus. Dies ist ein Download von einem unserer echten Cluster. Wir haben LSN-basiert, an einem Tag hergestellt. Und wir sehen, dass das LSN-basierte Delta-Backup von drei Uhr morgens bis fünf Uhr morgens lief. Dies ist die Belastung durch die Anzahl der Prozessorkerne. WAL-delta hat hier etwa 20 Minuten gebraucht, ist also deutlich schneller geworden, gleichzeitig kam es aber zu einem intensiveren Austausch über das Netzwerk.
Da wir Informationen darüber haben, welche Blöcke sich zu welchem Zeitpunkt im Verlauf der Datenbank geändert haben, sind wir noch einen Schritt weiter gegangen und haben uns entschieden, Funktionalität zu integrieren – eine PostgreSQL-Erweiterung namens „pg_prefaulter“.
Das bedeutet, dass die Standby-Basis, wenn sie den Wiederherstellungsbefehl ausführt, WAL-G anweist, die nächste WAL-Datei abzurufen. Wir verstehen ungefähr, auf welche Datenblöcke der WAL-Wiederherstellungsprozess in naher Zukunft zugreifen wird, und initiieren einen Lesevorgang für diese Blöcke. Dies geschah, um die Leistung von SSD-Controllern zu steigern. Weil die WAL-Rolle die Seite erreicht, die geändert werden muss. Diese Seite befindet sich auf der Festplatte und nicht im Seitencache. Und er wird synchron auf das Eintreffen dieser Seite warten. Aber in der Nähe ist WAL-G, das weiß, dass wir in den nächsten paar hundert Megabyte WAL bestimmte Seiten benötigen und gleichzeitig beginnt, sie aufzuwärmen. Initiiert mehrere Festplattenzugriffe, sodass diese parallel ausgeführt werden. Auf SSD-Laufwerken funktioniert das zwar gut, für eine Festplatte ist es aber leider absolut nicht anwendbar, da wir hier nur mit unseren Eingabeaufforderungen eingreifen.
Das steht jetzt im Code.
Es gibt Funktionen, die wir gerne hinzufügen würden.
Dieses Bild zeigt, dass WAL-Delta relativ kurze Zeit benötigt. Dabei werden die Änderungen gelesen, die im Laufe des Tages in der Datenbank aufgetreten sind. Wir könnten WAL-Delta nicht nur nachts durchführen, da es keine nennenswerte Belastungsquelle mehr darstellt. Wir können WAL-Delta jede Minute lesen, weil es billig ist. In einer Minute können wir alle Änderungen scannen, die am Cluster vorgenommen wurden. Und das könnte man als „sofortiges WAL-Delta“ bezeichnen.
Der Punkt ist, dass wir bei der Wiederherstellung des Clusters die Anzahl der Storys reduzieren, die wir nacheinander zusammenfassen müssen. Das heißt, die Menge an WAL, die PostgreSQL rollt, sollte reduziert werden, da dies viel Zeit in Anspruch nimmt.
Aber das ist nicht alles. Wenn wir wissen, dass ein Block bis zur Backup-Konsistenz geändert wird, können wir ihn in der Vergangenheit nicht ändern. Das heißt, jetzt haben wir eine Datei-für-Datei-Optimierung der WAL-Delta-Weiterleitung. Das heißt, wenn beispielsweise am Dienstag eine Tabelle vollständig gelöscht wurde oder einige Dateien vollständig aus der Tabelle gelöscht wurden, werden wir diese Daten bei einem Delta-Rollover am Montag und Samstag, wenn pg_basebackup wiederhergestellt wird, nicht einmal erstellen.
Wir wollen diese Technologie auf die Seitenebene erweitern. Das heißt, wenn sich ein Teil der Datei am Montag ändert, aber am Mittwoch überschrieben wird, müssen wir bei der Wiederherstellung an einem Punkt am Donnerstag die ersten paar Versionen der Seiten nicht auf die Festplatte schreiben.
Dies ist jedoch immer noch eine Idee, die in uns aktiv diskutiert wird, aber noch nicht den Code erreicht hat.
Wir wollen eine weitere Funktion in WAL-G einbauen. Wir möchten es erweiterbar machen, da wir verschiedene Datenbanken unterstützen müssen und die Backup-Verwaltung auf die gleiche Weise angehen möchten. Das Problem besteht jedoch darin, dass die MySQL-APIs grundlegend unterschiedlich sind. In MySQL basiert PITR nicht auf dem physischen WAL-Protokoll, sondern auf dem Binlog. Und wir haben kein Archivierungssystem in MySQL, das einem externen System mitteilen würde, dass dieses Binlog fertig ist und archiviert werden muss. Wir müssen irgendwo in Cron mit der Datenbank stehen und prüfen, ob etwas bereit ist?
Und genauso gibt es bei einer MySQL-Wiederherstellung keinen Wiederherstellungsbefehl, der dem System mitteilen könnte, dass ich diese oder jene Dateien benötige. Bevor Sie mit dem Neuaufbau Ihres Clusters beginnen, müssen Sie wissen, welche Dateien Sie benötigen. Sie müssen selbst erraten, welche Dateien Sie benötigen. Aber diese Probleme könnten vielleicht irgendwie umgangen werden. (Klarstellung: MySQL wird bereits unterstützt)
Im Bericht wollte ich auch über die Fälle sprechen, in denen WAL-G für Sie nicht geeignet ist.
Wenn Sie kein synchrones Replikat haben, garantiert WAL-G nicht, dass das letzte Segment erhalten bleibt. Und wenn die Archivierung hinter den letzten Abschnitten des Verlaufs zurückbleibt, ist das ein Risiko. Wenn es kein synchrones Replikat gibt, würde ich die Verwendung von WAL-G nicht empfehlen. Dennoch ist es hauptsächlich für eine Cloud-Installation konzipiert, was eine Hochverfügbarkeitslösung mit einem synchronen Replikat voraussetzt, das für die Sicherheit der letzten übertragenen Bytes verantwortlich ist.
Ich sehe oft Leute, die versuchen, WAL-G und WAL-E gleichzeitig auszuführen. Wir unterstützen die Abwärtskompatibilität in dem Sinne, dass WAL-G eine Datei von WAL-E wiederherstellen und ein in WAL-E erstelltes Backup wiederherstellen kann. Da diese beiden Systeme jedoch paralleles Wal-Push verwenden, beginnen sie, sich gegenseitig Dateien zu stehlen. Wenn wir es in WAL-G beheben, bleibt es weiterhin in WAL-E. In WAL-E prüft es den Archivstatus, sieht die fertigen Dateien und archiviert sie, während andere Systeme einfach nicht wissen, dass diese WAL-Datei existiert, da PostgreSQL nicht versucht, sie ein zweites Mal zu archivieren.
Was werden wir hier auf der WAL-G-Seite beheben? Wir werden PostgreSQL nicht darüber informieren, dass diese Datei parallel übertragen wurde, und wenn PostgreSQL uns auffordert, sie zu archivieren, wissen wir bereits, dass eine solche Datei mit dieser Moduszeit und mit diesem MD5 bereits archiviert wurde, und wir sagen einfach PostgreSQL - OK, alles ist fertig, ohne dass Sie wirklich etwas tun müssen.
Es ist jedoch unwahrscheinlich, dass dieses Problem auf der WAL-E-Seite behoben wird. Daher ist es derzeit nicht möglich, einen Archivierungsbefehl zu erstellen, der die Datei sowohl in WAL-G als auch in WAL-E archiviert.
Darüber hinaus gibt es Fälle, in denen WAL-G derzeit nicht für Sie geeignet ist, wir werden das aber auf jeden Fall beheben.
Erstens verfügen wir derzeit nicht über eine integrierte Backup-Verifizierung. Wir führen weder bei der Sicherung noch bei der Wiederherstellung eine Überprüfung durch. Dies geschieht selbstverständlich in der Cloud. Dies wird jedoch einfach durch eine Vorabprüfung, einfach durch die Wiederherstellung des Clusters, umgesetzt. Diese Funktionalität möchte ich den Benutzern zur Verfügung stellen. Durch die Überprüfung gehe ich jedoch davon aus, dass es in WAL-G möglich sein wird, den Cluster wiederherzustellen und zu starten und Smoke-Tests auszuführen: pg_dumpall nach /dev/null und amcheck-Indexüberprüfung.
Derzeit gibt es in WAL-G keine Möglichkeit, ein Backup von WAL zu verschieben. Das heißt, wir unterstützen einige Fenster. Zum Beispiel das Speichern der letzten sieben Tage, das Speichern der letzten zehn Backups und das Speichern der letzten drei vollständigen Backups. Sehr oft kommen Leute und sagen: „Wir brauchen ein Backup von dem, was am Neujahrstag passiert ist, und wir wollen es für immer behalten.“ WAL-G kann dies noch nicht. (Hinweis – Dies wurde bereits behoben. Lesen Sie mehr – Backup-Mark-Option in )
Und wir haben bei der Validierung von PITR keine Seitenprüfsummen und Integritätsprüfungen für alle Wellensegmente.
Aus all dem habe ich ein Projekt für Google Summer of Code zusammengestellt. Wenn Sie kluge Studenten kennen, die gerne etwas in Go schreiben und mehrere tausend Dollar von einem Unternehmen mit dem Buchstaben „G“ bekommen würden, dann empfehlen Sie ihnen unser Projekt. Ich werde als Mentor für dieses Projekt fungieren, sie können es schaffen. Wenn keine Studenten da sind, dann nehme ich es und mache es im Sommer selbst.
Und wir haben noch viele andere kleine Probleme, an denen wir nach und nach arbeiten. Und es passieren einige ziemlich seltsame Dinge.
Wenn Sie WAL-G beispielsweise ein leeres Backup geben, stürzt es einfach ab. Wenn Sie ihm beispielsweise mitteilen, dass er einen leeren Ordner sichern muss. Die pg_control-Datei wird nicht vorhanden sein. Und er wird denken, dass er etwas nicht versteht. Theoretisch müssen Sie in diesem Fall eine normale Nachricht an den Benutzer schreiben, um ihm die Verwendung des Tools zu erklären. Aber das ist nicht einmal ein Merkmal der Programmierung, sondern ein Merkmal einer guten, verständlichen Sprache.
Wir wissen nicht, wie man ein Offline-Backup durchführt. Wenn die Datenbank lügt, können wir sie nicht sichern. Aber hier ist alles ganz einfach. Wir rufen Backups nach LSN auf, wenn es gestartet ist. Die LSN der zugrunde liegenden Basis muss aus der Steuerdatei gelesen werden. Und das ist so eine unerkannte Funktion. Viele Backup-Systeme können eine zugrunde liegende Datenbank sichern. Und es ist praktisch.
Den Mangel an Backup-Speicherplatz können wir derzeit nicht richtig bewältigen. Weil wir zu Hause normalerweise mit großen Backups arbeiten. Und sie haben es nicht geschafft. Aber wenn jemand jetzt in Go programmieren möchte, fügen Sie dem Bucket die Behandlung für Out-of-Space-Fehler hinzu. Ich werde mir den Pull-Request auf jeden Fall ansehen.
Und was uns vor allem Sorgen bereitet, ist, dass wir möglichst viele Docker-Integrationstests wollen, die verschiedene Szenarien prüfen. Im Moment testen wir nur grundlegende Szenarien. Bei jedem Commit möchten wir jedoch Commit für Commit alle von uns unterstützten Funktionen überprüfen. Insbesondere werden wir beispielsweise ausreichend Unterstützung für PostgreSQL 9.4-9.5 haben. Wir unterstützen sie, weil die Community PostgreSQL unterstützt, aber wir überprüfen nicht Commit für Commit, um sicherzustellen, dass nicht alles kaputt geht. Und es scheint mir, dass dies ein ziemlich ernstes Risiko darstellt.
Wir haben WAL-G auf mehr als tausend Clustern in der Yandex-Datenbankverwaltung ausgeführt. Und es sichert jeden Tag mehrere hundert Terabyte an Daten.
Wir haben eine Menge TODO in unserem Code. Wenn Sie programmieren möchten, kommen Sie, wir warten auf Pull-Anfragen, wir warten auf Fragen.
Fragen
Guten Abend! Danke! Ich vermute, dass Sie sich bei Verwendung von WAL-Delta wahrscheinlich stark auf ganzseitige Schreibvorgänge verlassen. Und wenn ja, haben Sie Tests durchgeführt? Du hast eine schöne Grafik gezeigt. Wie viel schöner wird es, wenn FPW ausgeschaltet ist?
Ganzseitiges Schreiben ist für uns aktiviert, wir haben nicht versucht, es zu deaktivieren. Das heißt, ich als Entwickler habe nicht versucht, es auszuschalten. Systemadministratoren, die recherchiert haben, haben dieses Problem wahrscheinlich untersucht. Aber wir brauchen FPW. Fast niemand deaktiviert es, da es sonst unmöglich ist, ein Backup von einer Replik zu erstellen.
Danke für den Bericht! Ich habe zwei Fragen. Die erste Frage ist, was mit Tablespaces passieren wird.
Wir warten auf eine Pull-Anfrage. Unsere Datenbanken befinden sich auf SSD- und NMVE-Festplatten und wir benötigen diese Funktion nicht wirklich. Ich bin im Moment nicht bereit, ernsthaft Zeit darauf zu verwenden, es gut zu machen. Ich plädiere voll und ganz dafür, dass wir das unterstützen. Es gibt Menschen, die es unterstützt haben, aber auf eine Weise, die zu ihnen passt. Sie haben einen Fork gemacht, aber sie stellen keine Pull-Requests. (Hinzugefügt in Version 0.2.13)
Und die zweite Frage. Sie haben gleich zu Beginn gesagt, dass WAL-G davon ausgeht, dass es alleine funktioniert und keine Wrapper benötigt werden. Ich selbst verwende Wrapper. Warum sollten sie nicht verwendet werden?
Wir möchten, dass es so einfach wie eine Balalaika ist. Das bedeutet, dass Sie außer einer Balalaika überhaupt nichts brauchen. Wir wollen, dass das System einfach ist. Wenn Sie Funktionen haben, die Sie in einem Skript ausführen müssen, dann sagen Sie es uns – wir erledigen das in Go.
Guten Abend! Danke für den Bericht! Wir konnten WAL-G nicht dazu bringen, mit der GPG-Entschlüsselung zu arbeiten. Es verschlüsselt normal, möchte aber nicht entschlüsseln. Ist es etwas, das bei uns nicht geklappt hat? Die Situation ist deprimierend.
Erstellen Sie ein Problem auf GitHub und lassen Sie es uns herausfinden.
Das heißt, Sie sind darauf noch nicht gestoßen?
Es gibt eine Funktion im Fehlerbericht, die besagt, dass WAL-G, wenn er nicht versteht, um welche Art von Datei es sich handelt, fragt: „Vielleicht ist sie verschlüsselt?“ Vielleicht liegt das Problem überhaupt nicht in der Verschlüsselung. Ich möchte die Protokollierung zu diesem Thema verbessern. Er muss es entschlüsseln. Wir beschäftigen uns derzeit mit diesem Thema in dem Sinne, dass uns die Organisation des Systems zur Beschaffung öffentlicher und privater Schlüssel nicht wirklich gefällt. Weil wir externes GPG aufrufen, damit es uns seine Schlüssel gibt. Und dann nehmen wir diese Schlüssel und übertragen sie an das interne GPG, das offene PGP, das für uns in WAL-G kompiliert wird, und dort nennen wir Verschlüsselung. In diesem Zusammenhang möchten wir das System verbessern und die Libsodium-Verschlüsselung unterstützen (hinzugefügt in Version 0.2.15). Natürlich sollte die Dekodierung funktionieren, lassen Sie es uns herausfinden – Sie brauchen mehr ein Symptom als ein paar Worte. Sie können sich irgendwann im Raum des Redners treffen und sich das System ansehen. (PGP-Verschlüsselung ohne externes GPG – v0.2.9)
Hallo! Danke für den Bericht! Ich habe zwei Fragen. Ich habe den seltsamen Wunsch, pg_basebackup und WAL-Login bei zwei Anbietern durchzuführen, d. h. ich möchte eine Cloud und eine andere erstellen. Gibt es eine Möglichkeit, dies zu tun?
Das gibt es zwar noch nicht, aber es ist eine interessante Idee.
Ich vertraue einfach keinem Anbieter, sondern möchte das Gleiche auch bei einem anderen haben, nur für den Fall der Fälle.
Die Idee ist interessant. Technisch ist dies gar nicht so schwer umzusetzen. Kann ich Sie bitten, einen Issue auf GitHub zu erstellen, damit die Idee nicht verloren geht?
Ja, natürlich.
Und wenn die Schüler dann zum Google Summer of Code kommen, werden wir sie dem Projekt hinzufügen, damit es mehr Arbeit gibt, um mehr aus ihnen herauszuholen.
Und die zweite Frage. Es gibt ein Problem auf GitHub. Ich glaube, es ist bereits geschlossen. Während der Wiederherstellung kommt es zu einer Panik. Und um es zu besiegen, haben Sie eine separate Versammlung gebildet. Es ist richtig in Sachen. Und es besteht die Möglichkeit, eine variable Umgebung in einem Thread zu erstellen. Und deshalb funktioniert es sehr langsam. Wir sind auf dieses Problem gestoßen und es wurde noch nicht behoben.
Das Problem besteht darin, dass der Speicher (CEPH) aus irgendeinem Grund die Verbindung zurücksetzt, wenn wir mit hoher Parallelität darauf stoßen. Was kann man dagegen tun? Die Wiederholungslogik sieht folgendermaßen aus. Wir versuchen, die Datei erneut herunterzuladen. In einem Durchgang hatten wir eine Reihe von Dateien nicht heruntergeladen, wir werden einen zweiten für alle erstellen, die sich nicht angemeldet haben. Und solange mindestens eine Datei pro Iteration geladen wird, wiederholen wir und wiederholen und wiederholen. Wir haben die Logik des Wiederholungsversuchs verbessert – exponentielles Backoff. Es ist jedoch nicht ganz klar, was man mit der Tatsache anfangen soll, dass die Verbindung auf der Seite des Speichersystems einfach abbricht. Das heißt, wenn wir in einen Stream hochladen, werden diese Verbindungen nicht unterbrochen. Was können wir hier verbessern? Wir verfügen über eine Netzwerkdrosselung, wir können jede Verbindung durch die Anzahl der gesendeten Bytes begrenzen. Ansonsten weiß ich nicht, wie ich mit der Tatsache umgehen soll, dass der Objektspeicher es uns nicht erlaubt, parallel herunterzuladen oder von ihm herunterzuladen.
Kein SLA? Steht ihnen nicht geschrieben, wie sie sich quälen lassen?
Der Punkt ist, dass die Leute, die diese Frage stellen, normalerweise ihren eigenen Tresor haben. Das heißt, niemand kommt von Amazon, Google Cloud oder Yandex Object Storage.
Vielleicht ist die Frage nicht mehr für Sie?
Die Frage hier ist in diesem Fall egal, für wen. Wenn es irgendwelche Ideen gibt, wie man damit umgehen kann, lassen Sie es uns in WAL-G tun. Aber bisher habe ich keine guten Ideen, wie ich damit umgehen soll. Es gibt einige Objektspeicher, die das Auflisten von Backups unterschiedlich unterstützen. Sie bitten sie, Objekte aufzulisten, und sie fügen dort einen Ordner hinzu. WAL-G bekommt darüber Angst – es gibt hier etwas, das keine Datei ist, ich kann es nicht wiederherstellen, was bedeutet, dass die Sicherung nicht wiederhergestellt wurde. Das bedeutet, dass Sie tatsächlich über einen vollständig wiederhergestellten Cluster verfügen, der jedoch einen fehlerhaften Status zurückgibt, da Object Storage einige seltsame Informationen zurückgegeben hat, die es nicht vollständig verstanden hat.
Dies geschieht in der Mail-Cloud.
Wenn Sie eine Reproduktion erstellen können ...
Es wird konsequent reproduziert...
Wenn es eine Reproduktion gibt, werden wir meiner Meinung nach mit Wiederholungsstrategien experimentieren und herausfinden, wie wir es erneut versuchen können, und verstehen, was die Cloud von uns verlangt. Vielleicht ist es für uns bei drei Verbindungen stabil und die Verbindung wird nicht unterbrochen, dann werden wir vorsichtig drei erreichen. Denn jetzt brechen wir die Verbindung sehr schnell ab, d. h. wenn wir eine Wiederherstellung mit 16 Threads gestartet haben, dann sind es nach dem ersten Wiederholungsversuch 8 Threads, 4 Threads, 2 Threads und einer. Und dann wird die Datei in einen Stream gezogen. Wenn es einige magische Werte gibt, wie zum Beispiel, dass 7,5 Threads am besten zum Pumpen geeignet sind, dann werden wir uns mit ihnen befassen und versuchen, weitere 7,5 Threads zu erstellen. Hier ist eine Idee.
Danke für den Bericht! Wie sieht ein vollständiger Workflow für die Arbeit mit WAL-G aus? Zum Beispiel im dummen Fall, wenn es seitenübergreifend kein Delta gibt. Und wir nehmen das erste Backup und entfernen es, dann archivieren wir den Schacht, bis wir blau im Gesicht sind. So wie ich es verstehe, liegt hier eine Panne vor. Irgendwann müssen Sie ein Delta-Backup von Seiten erstellen, d. h. ein externer Prozess steuert dies oder wie passiert das?
Die Delta-Backup-API ist recht einfach. Da gibt es eine Zahl – maximale Delta-Schritte, so heißt es. Der Standardwert ist Null. Das bedeutet, dass jedes Mal, wenn Sie einen Backup-Push durchführen, ein vollständiges Backup heruntergeladen wird. Wenn Sie den Wert in eine positive Zahl ändern, beispielsweise 3, wird beim nächsten Backup-Push der Verlauf früherer Backups angezeigt. Er stellt fest, dass Sie die Kette von 3 Deltas nicht überschreiten und erstellt ein Delta.
Das heißt, jedes Mal, wenn wir WAL-G starten, versucht es, ein vollständiges Backup zu erstellen?
Nein, wir führen WAL-G aus und es versucht, ein Delta zu erstellen, wenn Ihre Richtlinien dies zulassen.
Grob gesagt: Wenn Sie es jedes Mal mit Null ausführen, verhält es sich dann wie pg_basebackup?
Nein, es läuft trotzdem schneller, da es Komprimierung und Parallelität verwendet. Pg_basebackup platziert den Schacht neben Ihnen. WAL-G geht davon aus, dass Sie die Archivierung konfiguriert haben. Und es wird eine Warnung ausgegeben, wenn es nicht konfiguriert ist.
Pg_basebackup kann ohne Wellen ausgeführt werden.
Ja, dann werden sie sich fast gleich verhalten. Pg_basebackup kopiert in das Dateisystem. Übrigens haben wir eine neue Funktion, die ich vergessen habe zu erwähnen. Wir können jetzt von pg_basebackup auf das Dateisystem sichern. Ich weiß nicht, warum das nötig ist, aber es ist da.
Zum Beispiel auf CephFS. Nicht jeder möchte Object Storage konfigurieren.
Ja, das ist wahrscheinlich der Grund, warum sie eine Frage zu dieser Funktion gestellt haben, damit wir sie umsetzen können. Und wir haben es geschafft.
Danke für den Bericht! Es gibt nur eine Frage zum Kopieren in das Dateisystem. Unterstützen Sie jetzt standardmäßig das Kopieren in Remote-Speicher, wenn beispielsweise ein Regal im Rechenzentrum oder etwas anderes vorhanden ist?
In dieser Formulierung ist das eine schwierige Frage. Ja, wir unterstützen, aber diese Funktionalität ist noch in keiner Version enthalten. Das heißt, alle Vorabversionen unterstützen dies, die Release-Versionen jedoch nicht. Diese Funktionalität wurde in Version 0.2 hinzugefügt. Es wird auf jeden Fall bald veröffentlicht, sobald wir alle bekannten Fehler behoben haben. Derzeit ist dies jedoch nur in der Vorabversion möglich. Es gibt zwei Fehler in der Vorabversion. Problem mit der WAL-E-Wiederherstellung, wir haben es nicht behoben. Und in der neuesten Vorabversion wurde ein Fehler bezüglich Delta-Backup hinzugefügt. Daher empfehlen wir jedem, die Release-Versionen zu verwenden. Sobald es in der Vorabversion keine Fehler mehr gibt, können wir sagen, dass wir Google Cloud, S3-kompatible Dinge und Dateispeicherung unterstützen.
Hallo, danke für den Bericht. So wie ich es verstehe, ist WAL-G keine Art zentralisiertes System wie Barmen? Planen Sie, in diese Richtung zu gehen?
Das Problem ist, dass wir uns von dieser Richtung entfernt haben. WAL-G lebt auf dem Basishost, auf dem Clusterhost und auf allen Hosts im Cluster. Als wir auf mehrere Tausend Cluster umzogen, hatten wir viele Barkeeper-Installationen. Und jedes Mal, wenn in ihnen etwas auseinanderfällt, ist das ein großes Problem. Da sie repariert werden müssen, müssen Sie verstehen, welche Cluster jetzt über keine Backups verfügen. Ich habe nicht vor, WAL-G in Richtung physischer Hardware für Backup-Systeme zu entwickeln. Wenn die Community hier eine gewisse Funktionalität wünscht, macht mir das überhaupt nichts aus.
Wir haben Teams, die für die Lagerung verantwortlich sind. Und wir fühlen uns so gut, dass es nicht wir sind, dass es besondere Leute gibt, die unsere Dateien dort ablegen, wo sie sicher sind. Sie führen dort alle möglichen cleveren Codierungen durch, um den Verlust einer bestimmten Anzahl von Dateien zu überstehen. Sie sind für die Netzwerkbandbreite verantwortlich. Wenn Sie einen Barkeeper haben, stellen Sie möglicherweise plötzlich fest, dass sich auf demselben Server kleine Datenbanken mit viel Datenverkehr angesammelt haben. Sie scheinen viel Platz darauf zu haben, aber aus irgendeinem Grund passt nicht alles durch das Netzwerk. Es kann auch andersherum kommen. Es gibt dort viele Netzwerke, es gibt Prozessorkerne, aber hier gibt es keine Festplatten. Und wir hatten die Notwendigkeit, etwas unter einen Hut zu bringen, satt und sind zu der Tatsache übergegangen, dass die Datenspeicherung ein separater Dienst ist, für den separate, spezielle Personen verantwortlich sind.
PS: Eine neue Version wurde veröffentlicht , in dem Sie die Konfigurationsdatei .walg.json verwenden können, die sich standardmäßig im Postgres-Home-Verzeichnis befindet. Sie können auf Bash-Skripte verzichten. Beispiel .walg.json ist in dieser Ausgabe
Video:
Source: habr.com