Ich lade Sie ein, die Zusammenfassung des Vortrags von Georgy Rylov aus Anfang 2020 "WAL-G: neue Möglichkeiten und Erweiterung der Gemeinschaft" zu lesen.
Open-Source-Maintainer stehen mit dem Wachstum vor vielen Herausforderungen. Wie schreibt man immer mehr benötigte Funktionen, behebt immer mehr Issues und schafft es, immer mehr Pull Requests zu überprüfen? Anhand von WAL-G (Backup-Tool für PostgreSQL) werde ich erzählen, wie wir diese Probleme gelöst haben, indem wir einen Kurs zur Open-Source-Entwicklung an der Universität gestartet haben, was wir erreicht haben und wohin wir als nächstes gehen werden.
Hallo zusammen! Ich bin Entwickler bei Yandex aus Jekaterinburg. Heute werde ich über WAL-G sprechen.
Im Titel des Vortrags wurde nicht gesagt, dass es um Backups geht. Weiß jemand nicht, was WAL-G ist? Oder wissen es alle? Hebt die Hand, wenn ihr es nicht wisst. Unglaublich, ihr seid zu einem Vortrag gekommen und wisst nicht, worum es geht.
Lasst mich erzählen, was heute auf dem Programm steht. Es ist so, dass unser Team schon seit einiger Zeit mit Backups beschäftigt ist. Und dies ist ein weiterer Vortrag in einer Reihe, in der wir darüber berichten, wie wir Daten sicher, zuverlässig, bequem und effektiv speichern.
In den vorherigen Serien gab es viele Vorträge von Andrei Borodin und Vladimir Leskov. Wir waren viele. Und wir haben alle seit vielen Jahren über WAL-G gesprochen.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Dieser Vortrag wird sich ein wenig von den anderen unterscheiden, da es in den meisten anderen um die technische Seite ging, während ich hier darüber sprechen werde, wie wir auf die Herausforderungen des Wachstums der Gemeinschaft gestoßen sind. Und wie wir eine kleine Idee hatten, die uns hilft, damit umzugehen.
Vor einigen Jahren war WAL-G ein recht kleines Projekt, das wir von Citus Data übernommen haben. Und wir haben es gerade erst übernommen. Es wurde von einer Person entwickelt.
Und in WAL-G gab es Folgendes nicht:
- Backup von der Replica.
- Es gab keine inkrementellen Backups.
- Es gab keine WAL-Delta-Backups.
- Und es fehlte noch eine Menge anderer Dinge.
In den letzten Jahren ist WAL-G erheblich gewachsen.
Und bis 2020 war all das oben Genannte bereits vorhanden. Dazu kommt, dass wir nun:
- Über 1.000 Sterne auf GitHub.
- 150 Forks.
- Etwa 15 offene PRs.
- Und noch viele Mitwirkende.
- Und ständig offene Issues. Und das, obwohl wir jeden Tag dort reingehen und etwas damit machen.
Und wir kamen zu dem Schluss, dass dieses Projekt mehr unserer Aufmerksamkeit bedarf, selbst dann, wenn wir nichts für unseren Managed Databases-Dienst bei Yandex implementieren müssen.
Und irgendwann im Herbst 2018 kam uns die Idee. Normalerweise hat ein Team mehrere Möglichkeiten, wie es Features entwickeln und Bugs beheben kann, wenn es nicht genug Ressourcen hat. Man kann zum Beispiel einen weiteren Entwickler einstellen und ihm Geld zahlen. Oder man kann für eine gewisse Zeit einen Praktikanten anheuern und auch ihm ein Gehalt zahlen. Aber es gibt auch eine recht große Gruppe von Menschen, von denen viele bereits wirklich programmieren können. Nur weiß man manchmal nicht, welche Qualität der Code hat.
Wir haben darüber nachgedacht und beschlossen, Studenten einzubeziehen. Aber die Studenten werden nicht an allem teilnehmen. Sie werden nur einen Teil der Arbeit erledigen. Zum Beispiel werden sie Tests schreiben, Bugs beheben und Features implementieren, die nicht die Hauptfunktionalität betreffen. Die Hauptfunktionalität ist das Erstellen und Wiederherstellen von Backups. Wenn ein Bug beim Erstellen eines Backups auftritt, verlieren wir Daten. Und das möchte natürlich niemand. Alle möchten, dass alles sehr zuverlässig ist. Daher wollen wir Code, dem wir weniger vertrauen als unserem eigenen, dort nicht einsetzen. Das heißt, jeder nicht kritische Code ist das, was wir gerne von unseren zusätzlichen Arbeitskräften erhalten würden.
Unter welchen Bedingungen wird der PR eines Studenten akzeptiert?
- Sie müssen ihren Code mit Tests abdecken. Alles muss im CI ablaufen.
- Und außerdem wird es 2 Reviews geben. Eines von Andrei Borodin und eines von mir.
- Zusätzlich lade ich eine Build mit diesem Commit hoch, um zu überprüfen, dass nichts in unserem Service kaputtgeht. Und wir prüfen in End-to-End-Tests, dass alles funktioniert.
Spezialkurs über Open Source
Ein wenig darüber, warum das notwendig ist und warum ich es für eine coole Idee halte.
Für uns ist der Profit offensichtlich:
- Wir bekommen zusätzliche Hände.
- Und wir suchen nach Kandidaten für das Team unter fähigen Studenten, die guten Code schreiben.
Welchen Profit haben die Studenten?
Das könnte weniger offensichtlich sein, da die Studenten zumindest kein Geld für den Code erhalten, den sie schreiben, sondern nur Noten für ihr Zeugnis.
Ich habe sie danach gefragt. Und laut ihnen:
- Erfahrung als Contributor im Open Source.
- Eine Zeile im Lebenslauf erhalten.
- Sich beweisen und ein Vorstellungsgespräch bei Yandex bestehen.
- Teilnehmer am GSoC werden.
- +1 Spezialkurs für alle, die coden möchten.
Ich werde nicht erzählen, wie der Kurs organisiert war. Ich sage nur, dass WAL-G das Hauptprojekt war. Außerdem haben wir in diesen Kurs Projekte wie Odyssey, PostgreSQL und ClickHouse einbezogen.
Und es gab nicht nur Aufgaben in diesem Kurs, sondern auch Diplome und Abschlussarbeiten.
Und wo bleibt der Vorteil für die Benutzer?
Kommen wir nun zum Teil, der Sie eher interessiert. Was haben Sie davon? Der Vorteil liegt darin, dass die Studenten viele Bugs behoben haben und Feature-Anfragen umgesetzt haben, die Sie uns mitgeteilt haben.
Lassen Sie mich von den Dingen erzählen, die Sie schon lange wollten und die umgesetzt wurden.
Unterstützung von Tablespaces. Es wurden wahrscheinlich seit der Einführung von WAL-G Tablespaces in WAL-G erwartet, da WAL-G ein Nachfolger des Backup-Tools WAL-E ist, in dem Datenbank-Backups mit Tablespaces unterstützt wurden.
Ich erinnere kurz daran, was das ist und warum das alles notwendig ist. In der Regel befinden sich alle Ihre PostgreSQL-Daten in einem Verzeichnis im Dateisystem, das als Basisverzeichnis bezeichnet wird. Dieses Verzeichnis enthält bereits alle Dateien und Unterverzeichnisse, die für PostgreSQL erforderlich sind.
Tablespaces sind Verzeichnisse, in denen PostgreSQL-Daten liegen, aber sie liegen nicht außerhalb des Basisverzeichnisses. Auf der Folie sehen Sie, dass sich die Tablespaces außerhalb des Basisverzeichnisses befinden.
Wie sieht das für PostgreSQL aus? Im Basisverzeichnis gibt es ein separates Unterverzeichnis pg_tblspc. Darin befinden sich Symlinks zu den Verzeichnissen, in denen die Daten von PostgreSQL außerhalb des Basisverzeichnisses tatsächlich liegen.
Wenn Sie all dies nutzen, können diese Befehle für Sie etwa so aussehen. Das heißt, Sie erstellen eine Tabelle in einem angegebenen Tablespace und sehen dann, wo sie sich gerade befindet. Hier sind die letzten beiden Zeilen, die letzten ausgeführten Befehle. Dort ist ein Pfad sichtbar. Aber das ist in der Tat kein echter Pfad. Es handelt sich um einen Pfad mit einem Präfix aus dem Basisverzeichnis zu dem Tablespace. Und von dort stammt ein Symlink, der zu Ihren tatsächlichen Daten führt.
All das wird in unserem Team nicht verwendet, wurde jedoch von vielen anderen Benutzern von WAL-E genutzt, die uns mitgeteilt haben, dass sie auf WAL-G umsteigen möchten, aber dass dies ihnen im Weg steht. Jetzt wird es unterstützt.
Eine weitere Funktion, die uns unser Spezialkurs gebracht hat, ist das Catchup. Von Catchup wissen wahrscheinlich Menschen, die mehr mit Oracle als mit PostgreSQL gearbeitet haben.
Kurz gesagt, was das ist. So könnte die Topologie eines Clusters in unserem Dienst normalerweise aussehen. Wir haben einen Master. Es gibt eine Replikation, die das Write-Ahead-Log von ihm streamt. Und die Replikation sagt dem Master, an welchem LSN sie sich gerade befindet. Parallel dazu kann das Protokoll archiviert werden. Neben der Archivierung des Protokolls werden auch Backups in die Cloud gesendet. Und es werden Delta-Backups gesendet.
Was könnte das Problem sein? Wenn Sie eine recht große Datenbank haben, könnte es so sein, dass Ihre Replikation stark hinter dem Master zurückbleibt. Und sie bleibt so stark zurück, dass sie ihn niemals einholen kann. Dieses Problem muss normalerweise irgendwie gelöst werden.
Der einfachste Weg ist, die Replikation zu entfernen und sie neu zu installieren, denn sie wird niemals aufholen, und das Problem muss behoben werden. Aber das dauert ziemlich lange, denn die Wiederherstellung eines kompletten Backups einer 10 TB großen Datenbank dauert sehr, sehr lange. Und wir möchten dies so schnell wie möglich tun, wenn solche Probleme auftreten. Genau dafür ist Catchup gedacht.
Catchup ermöglicht die Verwendung von Delta-Backups, die so in der Cloud gespeichert werden. Sie geben an, an welchem LSN sich die hinterherhinkende Replikation gerade befindet, und geben dies im Befehl catchup an, um ein Delta-Backup zwischen diesem LSN und dem LSN, an dem sich Ihr Cluster derzeit befindet, zu erstellen. Danach stellen Sie dieses Backup auf der rückständigen Replikation wieder her.
Andere Datenbanken
Außerdem haben uns die Studenten viele Funktionen gebracht. Da wir bei Yandex nicht nur Postgres entwickeln, sondern auch MySQL, MongoDB, Redis, ClickHouse haben, benötigten wir irgendwann die Möglichkeit, Punkt-in-Zeit-Wiederherstellungen für MySQL durchführen zu können, und die Möglichkeit, diese in die Cloud zu laden.
Und wir wollten dies auf ähnliche Weise tun, wie es WAL-G macht. Und beschlossen, zu experimentieren und zu sehen, wie das alles aussehen würde.
Zunächst haben wir diese Logik nicht getrennt in einem Fork den Code geschrieben. Wir haben gesehen, dass wir ein funktionierendes Modell haben und es laufen könnte. Dann dachten wir, dass unsere Hauptgemeinschaft die Postgres-Anwender sind, die WAL-G verwenden. Daher mussten wir diese Teile irgendwie trennen. D. h. wenn der Code für Postgres geändert wird, dürfen wir MySQL nicht beschädigen, und wenn wir MySQL ändern, dürfen wir Postgres nicht beschädigen.
Die erste Idee, wie man dies aufteilen kann, war die Idee, denselben Ansatz wie bei PostgreSQL-Extensions zu verwenden. Um eine MySQL-Sicherung zu erstellen, mussten Sie im Grunde eine dynamische Bibliothek installieren.
Hier wird sofort die Asymmetrie dieses Ansatzes sichtbar. Wenn Sie Postgres sichern, installieren Sie ein normales Backup-Tool für Postgres und alles funktioniert gut. Für MySQL klingt es jedoch so, als müssten Sie ein Backup-Tool für Postgres installieren und zusätzlich eine dynamische Bibliothek für MySQL. Das klingt irgendwie seltsam. Das dachten wir auch und entschieden, dass das nicht die Lösung ist, die wir brauchen.
Verschiedene Builds für Postgres, MySQL, MongoDB, Redis
Aber das hat uns, wie wir glauben, zu der richtigen Lösung geführt – verschiedene Builds für verschiedene Datenbanken zu schaffen. Das ermöglicht es, die Logik, die an Backups verschiedener Datenbanken gebunden ist, zu isolieren, die auf eine gemeinsame API zugreifen, die WAL-G implementiert.
Das ist der Teil, den wir selbst geschrieben haben – bevor wir den Studenten Aufgaben geben. Das heißt, das ist genau der Teil, wo sie etwas falsch machen konnten, deshalb haben wir beschlossen, dass es besser ist, wir machen etwas richtig und alles wird gut.
Danach haben wir die Aufgaben verteilt. Sie wurden sofort angenommen. Von den Studenten wurde gefordert, drei Datenbanken zu unterstützen.
Das ist MySQL, das wir seit mehr als einem Jahr mit WAL-G auf diese Weise sichern.
Jetzt nähert sich auch MongoDB der Produktionsreife, da es gerade noch weiter optimiert wird. Im Grunde genommen haben wir das Gerüst dafür geschrieben. Danach haben die Studenten einige funktionierende Lösungen entwickelt. Und dann bringen wir sie in einen Zustand, den wir in unserer Produktion akzeptieren können.
Die Aufgaben schienen nicht so, dass die Studenten vollständige Backup-Tools für jede dieser Datenbanken schreiben mussten. Das war nicht unser Problem. Unser Problem war, dass wir eine Point-in-Time-Wiederherstellung wollten und dass wir in die Cloud sichern wollten. Wir baten die Studenten, einen Code zu schreiben, der dies ermöglicht. Die Studenten nutzten bereits bestehende Backup-Tools, die irgendwie Backups erstellen, und führten alles dann mit WAL-G zusammen, das alles in die Cloud umleitete. Zudem fügten sie die Point-in-Time-Wiederherstellung hinzu.
Was haben die Studenten noch gebracht? Sie brachten in WAL-G die Unterstützung für die Verschlüsselung mit Libsodium.
Außerdem haben wir Richtlinien für die Speicherung von Backups eingeführt. Jetzt können Backups als permanent markiert werden. Es ist auch bequemer, den Prozess ihrer Speicherung für Ihren Service zu automatisieren.
Was sind die Ergebnisse dieses Experiments?
Zu dem Kurs hatten sich anfangs mehr als 100 Personen angemeldet. Ich hatte zu Beginn nicht erwähnt, dass die Universität in Jekaterinburg die Ural Föderale Universität ist. Dort haben wir alles angekündigt. 100 Personen haben sich registriert. Tatsächlich haben viel weniger begonnen, aktiv etwas zu tun, ungefähr 30 Personen.
Von diesen haben noch weniger den Kurs abgeschlossen, da man Tests zu den vorhandenen Codes erstellen musste. Außerdem musste man einige Bugs beheben oder neue Funktionen implementieren. Ein Teil der Studierenden hat den Kurs jedoch tatsächlich abgeschlossen.
Momentan haben die Studierenden für diesen Kurs etwa 14 Issues behoben und 10 Funktionen unterschiedlicher Größe implementiert. Und wie ich denke, ist das ein vollwertiger Ersatz für ein oder zwei Entwickler.
Neben alldem haben wir Diplome und Kursarbeiten ausgestellt. 12 haben Diplome erhalten. 6 von ihnen haben bereits mit der Note „5“ bestanden. Bei den übrigen gab es noch keine Verteidigung, aber ich denke, dass es bei ihnen auch gut laufen wird.
Zukunftspläne
Was sind unsere Pläne für die Zukunft?
Zumindest die Funktionsanfragen, die wir bereits von den Nutzern gehört haben und die wir umsetzen möchten. Dazu gehören:
- Überwachung der Korrektheit der Zeitplanung im Archiv der HA-Cluster-Backups. Das kann man mit WAL-G machen. Und ich denke, wir werden Studierende finden, die sich damit beschäftigen möchten.
- Für den Transfer von Backups und WALs zwischen Clouddiensten haben wir bereits einen verantwortlichen Ansprechpartner.
- Kürzlich haben wir die Idee veröffentlicht, dass wir WAL-G noch weiter beschleunigen können, indem wir inkrementelle Backups ohne Überschreibung der Seiten entpacken und die Archive optimieren, die wir dorthin senden.
Sie können sie hier teilen.
Wozu war dieser Vortrag? Dazu, dass wir jetzt, außer den 4 Personen, die dieses Projekt unterstützen, zusätzliche Helfer haben, und zwar ziemlich viele. Besonders, wenn man ihnen eine persönliche Nachricht schreibt. Und wenn Sie Ihre Daten sichern und dies mit WAL-G tun oder umsteigen möchten, können wir Ihre Wünsche recht leicht berücksichtigen.
Das ist der QR-Code und der Link. Sie können durch diese auf alle Ihre Wünsche eingehen. Zum Beispiel beheben wir einen bestimmten Bug nicht. Oder es gibt eine Funktion, die Sie sich sehr wünschen, die aber aus irgendeinem Grund noch in keinem Backup-Tool vorhanden ist, einschließlich unserem. Lassen Sie uns unbedingt darüber wissen.
Fragen
Hallo! Danke für den Vortrag! Eine Frage zu WAL-G, aber nicht zu Postgres. WAL-G sichert MySQL und führt ein Extrabackup aus. Wenn man moderne Installationen auf CentOS betrachtet und wenn Sie yum install MySQL machen, wird MariaDB installiert. Ab Version 10.3 wird das Extrabackup nicht unterstützt, sondern nur das MariaDB-Backup. Wie sieht es damit bei Ihnen aus?
Bis jetzt haben wir versucht, MariaDB zu sichern. Wir hatten Anfragen zur Unterstützung von FoundationDB, aber im Allgemeinen, wenn eine solche Anfrage besteht, können wir Leute finden, die das machen. Es ist nicht so lange und nicht so kompliziert, wie ich denke.
Guten Tag! Danke für den Vortrag! Frage zu potenziell neuen Funktionen. Sind Sie bereit, WAL-G mit Bändern arbeiten zu lassen, damit man Backups auf Bänder machen kann?
Meinen Sie Backups auf Band-Speichern?
Ja.
Da ist Andrey Borodin, der auf diese Frage besser antworten kann als ich.
(Andrey) Ja, danke für die Frage! Wir hatten eine Anfrage zum Übertragen von Backups auf Bänder aus Cloud-Speichern. Und dafür der Transfer zwischen Clouds. Denn der Transfer zwischen Clouds ist eine allgemeine Version des Transfers auf Bänder. Außerdem haben wir eine skalierbare Architektur im Bereich der Speichersysteme. Übrigens wurden viele Speicher von Studenten geschrieben. Wenn Sie einen Speicher für Bänder schreiben, wird er natürlich unterstützt. Wir sind bereit, Pull-Requests zu prüfen. Man muss eine Datei schreiben, eine Datei lesen. Wenn man diese Dinge in Go umsetzt, sind das normalerweise 50 Zeilen Code. Und dann wird das Band in WAL-G unterstützt.
Danke für den Vortrag! Interessanter Entwicklungsprozess. Backup ist ein wichtiger Teil der Funktionalität, der gut getestet sein sollte. Als Sie die Funktionalität für neue Datenbanken implementiert haben, wurden die Tests auch von Studenten geschrieben oder haben Sie die Tests selbst geschrieben und dann die Implementierung den Studenten übergeben?
Die Tests wurden auch von Studenten geschrieben. Aber die Studenten haben mehr für solche Funktionen wie neue Datenbanken geschrieben. Sie haben Integrationstests geschrieben. Und sie haben Unit-Tests geschrieben. Wenn die Integrationen bestehen, also derzeit – das ist ein Szenario, das Sie manuell ausführen oder das beispielsweise von cron erledigt wird. Das Szenario ist sehr klar.
Die Studenten haben nicht viel Erfahrung. Wie viel Zeit geht für das Review drauf?
Ja, es dauert ziemlich viel Zeit, um das Review zu machen. Das heißt, wenn mehrere Committer gleichzeitig kommen und sagen, dass ich das gemacht habe, ich das gemacht habe, dann muss man darüber nachdenken und irgendwo einen halben Tag einplanen, um herauszufinden, was sie da geschrieben haben. Denn den Code muss man gründlich lesen. Sie haben schließlich kein Vorstellungsgespräch durchlaufen. Wir kennen sie nicht sehr gut, deshalb benötigt das erhebliche Zeit.
Danke für den Vortrag! Früher hat Andrei Borodin gesagt, dass der archive_command in WAL-G direkt aufgerufen werden sollte. Aber im Fall eines Patron-Clusters benötigen wir eine zusätzliche Logik zur Bestimmung des Knotens, von dem wir die WALs senden. Wie lösen Sie dieses Problem bei sich?
Wo besteht hier Ihr Problem? Haben Sie einen synchronen Replica, von dem Sie ein Backup machen? Oder was?
(Andrei) Die Sache ist, dass WAL-G tatsächlich ohne Shell-Skript-Wrapper vorgesehen ist. Wenn etwas fehlt, dann lasst uns die Logik ergänzen, die innerhalb von WAL-G vorhanden sein sollte. Bezüglich der Archivierung sollten wir annehmen, 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 entstehen. Insbesondere Probleme mit der Archivierung von Timelines und anderen Zusatzinformationen. Danke für die Frage!
(Hinweis: Wir haben die Wrapper mit Shell-Skripten entfernt. )
Guten Abend! Danke für den Vortrag! Die Funktion Catchup, über die Sie gesprochen haben, hat mein Interesse geweckt. Ich hatte schon einmal die Situation, dass die Replica hinterherhinkte und einfach nicht aufholen konnte. Und ich habe in WAL-G keine Beschreibung für diese Funktion in den Dokumentationen gefunden.
Das Catchup-Feature erschien buchstäblich in den 20er Tagen im Januar 2020. Vielleicht sollte man die Dokumentation besser bearbeiten. Wir schreiben sie selbst, und das auch nicht unbedingt super gut. Und von den Studierenden sollte man vielleicht auch verlangen, dass sie sie schreiben.
Ist es bereits in der Release?
Der Pull Request wurde bereits zusammengeführt, d. h. ich habe ihn überprüft. Ich habe das auf einem Test-Cluster ausprobiert. Bisher hatten wir keine Gelegenheit, dies an einem realen Beispiel zu testen.
Wann ist damit zu rechnen?
Ich weiß es nicht. Wartet einen Monat, dann werden wir es sicher testen.
Quelle: habr.com
