Ich lade Sie ein, die Zusammenfassung des Vortrags von Anfang 2020 von Georgiy Rylov "WAL-G: neue Möglichkeiten und Community-Erweiterung" zu lesen.
Open-Source-Maintainer stehen vor zahlreichen Herausforderungen, während sie wachsen. Wie kann man immer mehr geforderte Features entwickeln, ständig steigende Issues beheben und noch mehr Pull Requests sichten? Anhand von WAL-G (Backup-Tool für PostgreSQL) erläutere ich, wie wir diese Probleme angegangen sind, indem wir einen Kurs zur Open-Source-Entwicklung an der Universität ins Leben gerufen haben, was wir erreicht haben und wohin wir uns als nächstes bewegen werden.
Hallo zusammen! Ich bin Entwickler bei Yandex aus Jekaterinburg. Heute erzähle ich Ihnen von WAL-G.
Im Titel des Vortrags wurde nicht erwähnt, dass es etwas mit Backups zu tun hat. Weiß jemand nicht, was WAL-G ist? Oder wissen es alle? Bitte heben Sie die Hand, wenn Sie es nicht wissen. Unglaublich, Sie sind zu einem Vortrag gekommen und wissen nicht, worum es geht.
Lassen Sie mich erklären, was heute auf dem Programm steht. Unsere Gruppe beschäftigt sich seit geraumer Zeit mit Backups. Dies ist ein weiterer Vortrag in einer Reihe, in der wir darüber berichten, wie wir Daten sicher, zuverlässig, bequem und effizient speichern.
In den vorherigen Ausgaben gab es viele Präsentationen von Andrej Borodin und Wladimir Leskow. Wir waren viele, und wir haben schon seit Jahren über WAL-G gesprochen.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Dieser Vortrag wird sich ein wenig von den anderen unterscheiden, da wir hier mehr über die technischen Aspekte sprechen werden, während ich über die Herausforderungen berichten möchte, die wir im Zusammenhang mit dem Wachstum der Community erlebt haben. Und wie wir eine kleine Idee entwickelt haben, die uns dabei hilft, damit umzugehen.
Vor einigen Jahren war WAL-G ein relativ kleines Projekt, das wir von Citus Data übernommen haben. Damals hatten wir es nur übernommen, und es wurde von einer Person entwickelt.
Und WAL-G hatte damals einfach nicht:
- Backups von Replikaten.
- Es gab keine inkrementellen Backups.
- Es gab keine WAL-Delta-Backups.
- Und noch vieles mehr fehlte.
In diesen wenigen Jahren ist WAL-G stark gewachsen.
Bis zum Jahr 2020 waren all die oben genannten Funktionen bereits vorhanden. Zudem haben wir jetzt:
- Über 1.000 Sterne auf GitHub.
- 150 Forks.
- Rund 15 offene PRs.
- Und viele Mitwirkende.
- Es gibt konstant viele offene Issues. Und das, obwohl wir dort buchstäblich jeden Tag vorbeischauen und daran arbeiten.
Wir sind zu dem Schluss gekommen, dass dieses Projekt mehr unserer Aufmerksamkeit bedarf, selbst wenn wir nicht aktiv etwas für unseren Managed Databases-Service bei Yandex umsetzen müssen.
Irgendwann im Herbst 2018 kam uns die Idee. Normalerweise hat das Team verschiedene Möglichkeiten, um Features zu entwickeln oder Bugs zu beheben, wenn nicht genügend Kapazitäten vorhanden sind. Man könnte einen weiteren Entwickler einstellen und ihm Gehalt zahlen. Alternativ kann man einen Praktikanten für eine gewisse Zeit anheuern und ebenfalls eine Vergütung anbieten. Es gibt jedoch auch eine beträchtliche Anzahl von Personen, die bereits in der Lage sind, Code zu schreiben. Nur weiß man manchmal nicht, welche Qualität dieser Code hat.
Wir haben darüber nachgedacht und beschlossen, Studenten einzubeziehen. Allerdings werden die Studenten nicht an allem teilnehmen. Sie werden nur einen Teil der Arbeit übernehmen. Beispielsweise werden sie Tests schreiben, Bugs beheben und Funktionen implementieren, die die Hauptfunktionalität nicht betreffen. Die Hauptfunktionalität besteht im Erstellen von Backups und der Wiederherstellung dieser. Wenn ein Fehler beim Erstellen eines Backups auftritt, kann es zu Datenverlust kommen. Das möchte natürlich niemand. Alle wünschen sich, dass alles sehr zuverlässig ist. Daher möchten wir Code, dem wir weniger vertrauen als unserem eigenen, nicht verwenden. Das heißt, jeder nicht-kritische Code ist etwas, das wir von unseren zusätzlichen Arbeitskräften wünschen würden.
Unter welchen Bedingungen wird der PR eines Studenten angenommen?
- Sie sind verpflichtet, ihren Code mit Tests abzudecken. Alles muss im CI-Prozess getestet werden.
- Außerdem gibt es zwei Überprüfungen: eine von Andrej Borodin und eine von mir.
- Zusätzlich lade ich das Build mit diesem Commit separat hoch, um sicherzustellen, dass nichts in unserem Dienst kaputtgeht. Wir überprüfen in den End-to-End-Tests, dass alles funktioniert.
Spezialkurs zu Open Source
Ein bisschen darüber, warum das nötig ist und warum ich das für eine großartige Idee halte.
Der Vorteil für uns ist offensichtlich:
- Wir bekommen zusätzliche Unterstützung.
- Und wir suchen nach Kandidaten aus einer Gruppe fähiger Studenten, die guten Code schreiben.
Was bringt das den Studenten?
Die Vorteile sind vielleicht weniger offensichtlich, denn die Studenten bekommen zumindest kein Geld für den Code, den sie schreiben, sondern nur Noten für ihre Prüfungen.
Ich habe sie danach gefragt. Und laut ihrer Aussage:
- Erfahrung als Open-Source-Beitragsleister.
- Eine Zeile im Lebenslauf.
- Sich beweisen und ein Vorstellungsgespräch bei Yandex bestehen.
- Teilnehmer von GSoC werden.
- +1 Spezialisierungskurs für diejenigen, die Code schreiben möchten.
Ich werde nicht erläutern, wie der Kurs organisiert war. Ich sage nur, dass WAL-G das Hauptprojekt war. Außerdem haben wir weitere Projekte wie Odyssey, PostgreSQL und ClickHouse in den Kurs integriert.
Und wir haben nicht nur während dieses Kurses Aufgaben gestellt, sondern auch Diplome und Projekte vergeben.
Was bringt das den Nutzern?
Jetzt kommen wir zu dem Teil, der vor allem für Sie von Interesse ist. Was haben Sie davon? Der Vorteil ist, dass die Studenten viele Bugs behoben haben und Feature-Requests umgesetzt haben, um die Sie uns gebeten haben.
Lassen Sie mich über Dinge sprechen, die Sie schon lange wollten und die jetzt umgesetzt wurden.
Unterstützung von Tablespaces. Die Tablespaces in WAL-G wurden wahrscheinlich seit der Veröffentlichung von WAL-G erwartet, da WAL-G der Nachfolger eines anderen Backup-Werkzeugs, WAL-E, ist, bei dem Datenbank-Backups mit Tablespaces unterstützt wurden.
Lassen Sie mich kurz erinnern, was das ist und wofür es benötigt wird. In der Regel nehmen alle Ihre Postgres-Daten ein Verzeichnis im Dateisystem ein, das als Basisverzeichnis bezeichnet wird. Dieses Verzeichnis enthält bereits alle erforderlichen Dateien und Unterverzeichnisse für Postgres.
Tablespaces sind Verzeichnisse, in denen Postgres-Daten gespeichert werden, aber sie liegen nicht außerhalb des Basisverzeichnisses. Auf der Folie ist zu sehen, dass sich die Tablespaces außerhalb des Basisverzeichnisses befinden.
Wie sieht das für Postgres selbst aus? Im Basisverzeichnis gibt es ein separates Unterverzeichnis pg_tblspc. In diesem Verzeichnis befinden sich Symlinks auf die Verzeichnisse, in denen die Postgres-Daten tatsächlich außerhalb des Basisverzeichnisses liegen.
Wenn Sie all dies nutzen, könnten diese Befehle für Sie so aussehen. Das heißt, Sie erstellen eine Tabelle in einem bestimmten Tablespace und sehen nach, wo sie jetzt liegt. Diese zwei letzten Zeilen, die zwei letzten ausgeführten Befehle, zeigen einen bestimmten Pfad an. Aber in Wirklichkeit ist das kein echter Pfad. Es handelt sich um einen Pfad mit einem Präfix von dem Basisverzeichnis zu dem Tablespace. Von dort aus wird er über einen Symlink auf Ihre tatsächlichen Daten verwiesen.
In unserem Team nutzen wir das alles nicht, aber viele andere WAL-E-Benutzer hatten damit Erfahrungen gemacht und uns mitgeteilt, dass sie auf WAL-G umsteigen möchten, aber dadurch behindert wurden. Jetzt wird es unterstützt.
Eine andere Funktion, die uns unser Spezialkurs gebracht hat, ist das Catchup. Catchup ist Leuten bekannt, die wahrscheinlich eher mit Oracle als mit Postgres gearbeitet haben.
Kurz gesagt, was es ist. So könnte die Topologie eines Clusters in unserem Service aussehen. Wir haben einen Master. Es gibt eine Replikat, die die Write-Ahead-Logs von ihm streamt. Und die Replikat sagt dem Master, auf welchem LSN sie sich gerade befindet. Gleichzeitig wird das Protokoll archiviert. Neben der Archivierung des Protokolls werden auch Backups in die Cloud gesendet. Außerdem werden Delta-Backups gesendet.
Was könnte das Problem sein? Wenn Sie eine recht große Datenbank haben, kann es vorkommen, dass Ihre Replikat stark hinter dem Master zurückbleibt. Und sie bleibt so weit zurück, dass sie ihn niemals einholen kann. Dieses Problem muss normalerweise irgendwie gelöst werden.
Der einfachste Weg ist, die Replikat zu entfernen und sie neu zu konfigurieren, weil sie ihn ohnehin nie einholen wird, und das Problem gelöst werden muss. Aber das kann ziemlich lange dauern, da die Wiederherstellung eines vollständigen Backups von 10 TB sehr, sehr langwierig ist. Und wir möchten dies so schnell wie möglich tun, wenn solche Probleme auftreten. Genau dafür ist Catchup vorgesehen.
Catchup ermöglicht die Verwendung von Delta-Backups, die auf diese Weise in der Cloud gespeichert werden. Sie geben an, auf welchem LSN sich die zurückgebliebene Replik derzeit befindet und geben diesen in den Catchup-Befehl ein, um ein Delta-Backup zwischen diesem LSN und dem LSN zu erstellen, auf dem sich Ihr Cluster derzeit befindet. Danach stellen Sie dieses Backup auf der zurückgebliebenen Replik wieder her.
Andere Datenbanken
Außerdem haben uns die Studenten gleich viele Funktionen gebracht. Da wir bei Yandex nicht nur Postgres entwickeln, sondern auch MySQL, MongoDB, Redis und ClickHouse haben, benötigten wir einen gewissen Zeitpunkt, an dem wir Point-in-Time-Backup-Wiederherstellungen für MySQL machen und diese in die Cloud hochladen können.
Wir wollten dies auf eine Weise tun, die der von WAL-G ähnlich ist. Deshalb entschieden wir uns, zu experimentieren und zu sehen, wie das alles aussehen würde.
Zunächst haben wir keinen Unterschied in dieser Logik gemacht und den Code in einem Fork geschrieben. Wir haben gesehen, dass wir ein funktionierendes Modell haben und dass es erfolgreich sein könnte. Dann haben wir uns überlegt, dass unsere Hauptgemeinschaft die Postgres-Entwickler sind, die WAL-G verwenden. Daher mussten wir diese Teile irgendwie trennen. Das bedeutet, wenn wir den Code für Postgres ändern, brechen wir nicht MySQL, und wenn wir MySQL ändern, brechen wir nicht Postgres.
Die erste Idee zur Trennung bestand darin, denselben Ansatz zu verwenden, der auch in PostgreSQL-Extensions genutzt wird. Um ein Backup von MySQL zu erstellen, mussten Sie eine bestimmte dynamische Bibliothek installieren.
Hier wird sofort die Asymmetrie dieses Ansatzes deutlich. Wenn Sie Postgres sichern, installieren Sie einfach ein normales Backup-Tool dafür, und alles läuft reibungslos. Bei MySQL hingegen müssen Sie ein Backup-Tool für Postgres installieren und zusätzlich eine dynamische Bibliothek für MySQL. Das klingt irgendwie merkwürdig. Auch wir dachten so und kamen zu dem Schluss, dass dies nicht die benötigte Lösung ist.
Separate Builds für Postgres, MySQL, MongoDB, Redis
Dies ermöglichte uns, wie wir glauben, zur richtigen Lösung zu gelangen – verschiedene Builds für verschiedene Datenbanken bereitzustellen. Dadurch konnten wir die Logik, die mit den Backups der verschiedenen Datenbanken verbunden ist, isolieren, die auf eine gemeinsame API zugreifen, die von WAL-G bereitgestellt wird.
Das ist der Teil, den wir selbst geschrieben haben, bevor wir den Studenten Aufgaben gestellt haben. Das ist genau der Teil, wo sie etwas falsch machen könnten, daher haben wir beschlossen, es selbst zu erledigen, damit alles reibungslos verläuft.
Anschließend haben wir Aufgaben verteilt. Diese wurden sofort übernommen. Die Studierenden sollten drei Datenbanken unterstützen.
Dabei handelt es sich um MySQL, das wir bereits seit über einem Jahr mit WAL-G auf diese Weise sichern.
Jetzt ist auch MongoDB auf dem Weg zur Produktion, wo es noch die letzten Feinarbeiten erhält. Im Grunde genommen haben wir das Grundgerüst dafür geschrieben. Danach haben die Studierenden einige funktionierende Dinge erstellt, die wir in einen Zustand bringen, den wir in unserer Produktion akzeptieren können.
Diese Aufgaben forderten die Studierenden nicht dazu auf, vollständige Backup-Tools für jede dieser Datenbanken zu schreiben. Wir hatten nicht dieses Problem. Unser Anliegen war es, eine Point-in-Time-Wiederherstellung zu ermöglichen und in die Cloud zu sichern. Wir haben die Studierenden gebeten, einen Code zu erstellen, der dies ermöglicht. Die Studierenden haben bestehende Backup-Tools verwendet, die irgendwie Backups erstellen, und haben dann alles mit WAL-G kombiniert, was die Daten in die Cloud transferierte. Zudem haben sie die Point-in-Time-Wiederherstellung hinzugefügt.
Was haben die Studierenden noch beigetragen? Sie haben WAL-G Unterstützung für Libsodium-Verschlüsselung eingebracht.
Wir haben jetzt Richtlinien zur Speicherung von Backups. Backups können nun als dauerhaft markiert werden. So gestaltet sich der Prozess der Speicherung für Ihren Service noch komfortabler und automatisierter.
Was ist das Ergebnis dieses Experiments?
Ursprünglich hatten sich mehr als 100 Personen für den Kurs angemeldet. Ich habe zu Beginn nicht erwähnt, dass die Universität in Jekaterinburg – die Uraler Föderale Universität – ist. Dort haben wir alles angekündigt. 100 Personen haben sich angemeldet. Tatsächlich haben viel weniger als 30 aktiv etwas unternommen.
Noch weniger Teilnehmer haben den Kurs abgeschlossen, da sie Tests zu den vorhandenen Codes schreiben und einige Bugs beheben oder Features entwickeln mussten. Dennoch haben einige Studenten den Kurs erfolgreich abgeschlossen.
Bis jetzt haben die Studenten in diesem Kurs etwa 14 Issues behoben und 10 Features unterschiedlicher Größe erstellt. Meiner Meinung nach ist das eine vollwertige Ersatzlösung für ein oder zwei Entwickler.
Neben all dem haben wir Diplome und Projektarbeiten vergeben. 12 haben Diplome erhalten. 6 von ihnen haben bereits mit "5" bestanden. Die anderen hatten noch keine Verteidigung, aber ich bin zuversichtlich, dass es auch bei ihnen gut laufen wird.
Zukunftspläne
Was sind unsere Zukunftspläne?
Mindestens die Funktionen, die wir bereits von unseren Benutzern gehört haben, und die wir umsetzen möchten, sind folgende:
- Überwachung der Korrektheit der Timeline-Nachverfolgung im Backup-Archiv des HA-Clusters. Das kann mit Hilfe von WAL-G realisiert werden. Ich denke, wir finden Studenten, die daran arbeiten werden.
- Für den Transfer von Backups und WAL zwischen den Clouds haben wir bereits eine verantwortliche Person.
- Wir haben kürzlich die Idee veröffentlicht, dass wir WAL-G noch weiter beschleunigen können, indem wir inkrementelle Backups ohne Überschreibung von Seiten entpacken und die Archive optimieren, die wir dorthin senden.
Sie können diese hier teilen.
Wozu war dieser Bericht da? Darum, dass wir jetzt neben den vier Personen, die dieses Projekt unterstützen, zusätzliche Kräfte zur Verfügung haben, von denen es viele gibt. Besonders, wenn man sie privat anschreibt. Wenn Sie Ihre Daten sichern und dies mit WAL-G tun oder auf WAL-G umsteigen möchten, können wir Ihre Wünsche ziemlich leicht berücksichtigen.
Dies ist der QR-Code und der Link. Sie können diesen folgen und uns Ihre Wünsche mitteilen. Zum Beispiel, wenn wir einen bestimmten Bug nicht beheben. Oder wenn Sie sich eine Funktion wünschen, die bisher in keiner Backup-Lösung vorhanden ist, auch nicht in unserer. Bitte teilen Sie uns das unbedingt mit.
Fragen
Guten Tag! Vielen Dank für den Vortrag! Ich habe eine Frage zu WAL-G, aber nicht zu Postgres. WAL-G sichert MySQL und führt ein Extra-Backup durch. Wenn man aktuelle Installationen auf CentOS betrachtet und Sie führen 'yum install MySQL' aus, wird MariaDB installiert. Ab Version 10.3 wird das Extra-Backup nicht mehr unterstützt, dafür wird das MariaDB-Backup unterstützt. Wie sieht es bei Ihnen damit aus?
Momentan haben wir nicht versucht, MariaDB zu sichern. Wir hatten Anfragen zur Unterstützung von FoundationDB, aber insgesamt, wenn eine solche Anfrage vorliegt, können wir Leute finden, die das machen. Es ist nicht so langwierig und nicht so schwierig, wie ich denke.
Guten Tag! Vielen Dank für den Vortrag! Ich habe eine Frage zu potenziell neuen Funktionen. Sind Sie bereit, WAL-G mit Bandlaufwerken arbeiten zu lassen, um Backups auf Bändern durchzuführen?
Meinen Sie ein Backup auf einem Bandlager?
Ja.
Dort ist Andrei Borodin, der hierzu besser antworten kann als ich.
(Andrej) Ja, danke für die Frage! Wir hatten eine Anfrage für die Übertragung von Backups auf Tape aus einem Cloud-Speicher. Und dafür der Übertragung zwischen Clouds. Denn die Übertragung zwischen Clouds ist eine Art generalisierte Version der Übertragung auf Tape. Darüber hinaus haben wir eine erweiterbare Architektur im Bereich Storages. Übrigens wurden viele Storages von Studenten geschrieben. Und wenn Sie einen Storage für Tape schreiben, wird dieser natürlich unterstützt. Wir sind bereit, Pull Requests zu prüfen. Dabei muss eine Datei geschrieben und gelesen werden. Wenn man diese Dinge in Go umsetzt, benötigt man in der Regel etwa 50 Zeilen Code. Und dann wird Tape in WAL-G unterstützt.
Danke für die Präsentation! Ein interessanter Entwicklungsprozess. Backup ist ein ernsthafter Teil der Funktionalität, der gut getestet sein sollte. Bei der Implementierung neuer Funktionen für neue Datenbanken, wurden die Tests ebenfalls von Studenten geschrieben oder haben Sie die Tests selbst geschrieben und dann die Umsetzung an Studenten übergeben?
Die Tests wurden ebenfalls von Studenten durchgeführt. Doch die Studenten haben hauptsächlich für Funktionen wie neue Datenbanken getestet. Sie haben Integrationstests geschrieben. Und sie haben Unit-Tests erstellt. Wenn die Integrationstests erfolgreich sind, d. h. im Moment – es handelt sich um ein Szenario, das Sie manuell ausführen oder das beispielsweise durch cron ausgeführt wird. Das Szenario ist also gut nachvollziehbar.
Die Studenten haben nicht allzu viel Erfahrung. Wie viel Zeit wird für die Reviews benötigt?
Ja, die Reviews nehmen recht viel Zeit in Anspruch. In der Regel, wenn mehrere Commiter gleichzeitig kommen und sagen, dass sie dies oder jenes gemacht haben, muss man nachdenken und etwa einen halben Tag einplanen, um zu verstehen, was sie dort geschrieben haben. Denn der Code muss sorgfältig gelesen werden. Sie haben schließlich kein Vorstellungsgespräch absolviert. Wir kennen sie nicht besonders gut, daher dauert das erheblich länger.
Vielen Dank für den Vortrag! Früher hat Andrei Borodin gesagt, dass der archive_command in WAL-G direkt aufgerufen werden sollte. Doch im Falle eines Patron-Clusters benötigen wir zusätzliche Logik, um den Knoten zu bestimmen, von dem wir die WALs senden. Wie lösen Sie dieses Problem bei sich?
Wo liegt Ihr Problem? Angenommen, Sie haben eine synchronisierte Replica, von der Sie ein Backup erstellen? Oder was ist los?
(Andrej) Die Sache ist, dass WAL-G tatsächlich die Verwendung ohne Skripting im Shell-Umfeld vorsieht. Wenn etwas fehlt, lassen Sie uns die Logik hinzufügen, die innerhalb von WAL-G nötig ist. Bezogen auf die Quelle der Archivierung gehen wir davon aus, dass die Archivierung vom aktuellen Master im Cluster erfolgen sollte. Eine Archivierung von der Replica ist keine gute Idee. Dort können verschiedene Szenarien mit Problemen auftreten. Insbesondere Probleme bei der Archivierung von Timelines und weiteren Informationen. Vielen Dank für die Frage!
(Hinweis: Wir haben uns von der Einbindung von Shell-Skripten verabschiedet )
Guten Abend! Vielen Dank für den Vortrag! Ich fand die Feature 'Catchup', von der Sie gesprochen haben, sehr interessant. Ich hatte bereits die Situation, dass eine Replica hinterherhinkte und nicht aufholen konnte. In der Dokumentation von WAL-G habe ich diese Funktion nicht gefunden.
'Catchup' wurde buchstäblich Ende Januar 2020 eingeführt. Es wäre möglicherweise sinnvoll, die Dokumentation zu verbessern. Wir selbst schreiben sie und tun dies nicht unbedingt super gut. Vielleicht sollten wir von den Studenten verlangen, dass sie ebenfalls dokumentieren.
Ist es bereits veröffentlicht?
Der Pull-Request wurde bereits zusammengeführt, d. h. ich habe ihn überprüft. Ich habe es auf einem Test-Cluster ausprobiert. Bisher hatten wir nicht die Gelegenheit, es an einem Live-Beispiel zu testen.
Wann ist mit einer Veröffentlichung zu rechnen?
Ich weiß es nicht. Bitte warten Sie einen Monat, dann überprüfen wir es auf jeden Fall.
Quelle: habr.com
