Mehrere bevorstehende Vorträge basieren auf dem ersten Y. Subbotnik über Datenbanken, die
im Frühjahr stattfinden . Zunächst sprach Entwickler Andrei Borodin bei Y. Subbotnik. Er sprach über WAL-G, ein einfaches und effektives Tool zum Sichern von PostgreSQL in der Cloud, sowie über Algorithmen und Technologien, mit denen WAL-G Backups schneller erstellen kann. Das Hauptmerkmal von WAL-G sind Delta-Backups. In der Vorlesung erfahren Sie mehr über deren Implementierung und wie sich die Unterstützung für diese Technologie in PostgreSQL entwickelt.
- Hallo! Ich bin ein Yandex-Entwickler aus Jekaterinburg. Zur Technologie der schnellen Sicherung. Wir führen seit geraumer Zeit Backups durch. Es gab Berichte von
Vladimir Borodin und
Evgeny Dyukov darüber, wie wir recherchieren und was wir entwickeln, um Daten sicher, zuverlässig, bequem und effizient zu speichern. Diese Reihe widmet sich den neuesten Entwicklungen in diesem Bereich.
Lassen Sie uns im Prinzip über Backups in PostgreSQL sprechen. Das Standarddienstprogramm zum Übertragen von Daten -
pg_dump - ist als Konsolendienstprogramm definiert, das eine Datei mit einer logischen Darstellung Ihrer Daten erstellt.
Dass es sich um eine logische Kopie handelt, ist sehr praktisch. Sie können jederzeit Daten zwischen verschiedenen Versionen übertragen, Ihre Datenbank in Stücke schneiden und dies ist ein Standardwerkzeug, das beispielsweise in einer Box mit dem PgAdmin-Verwaltungsdienstprogramm geliefert wird.
Zu pg_dump müssen Sie zunächst wissen, dass dies ein Entwicklertool ist.
Dies ist kein Datenbankwartungstool. pg_dump ist nicht für die Arbeit mit einer hoch geladenen Datenbank ausgelegt.
Angenommen, alles ist ernst und Sie möchten die "Point-in-Time-Recovery" -Technologie verwenden, die die PostgreSQL-API für die Arbeit mit Online-Backups verwendet. Sie rufen die Funktion pg_start_backup auf und erstellen eine Dateikopie der Datenbank. Tatsächlich zwingt pg_start_backup die Datenbank, CHECKPOINT auszuführen. und aktivieren Sie ganzseitige Schreibvorgänge im Vorausschreibprotokoll. Die Kopie der Datenbank, die Sie beim Aufrufen der API erstellen, ist keine konsistente Kopie der Daten. Sie benötigen außerdem ein Vorausschreibprotokoll, um Ihre Datenbank für die Dauer des Aufrufs pg_stop_backup, dh am Ende der Sicherung, wiederherstellen zu können.
Nach der Endzeit des Entfernens der Sicherung und bei Vorhandensein eines führenden Datensatzes können Sie den gewünschten Zeitpunkt in der Lebensdauer Ihrer Datenbank wiederherstellen.
Das Dienstprogramm pg_basebackup ist im Lieferumfang enthalten. Es implementiert all diese Technologien in kanonischer Form und ermöglicht Ihnen das Sichern mit der minimal erforderlichen Funktionalität.
Wenn Sie immer noch ernsthafter sind als zuvor, verwenden Sie eine Art Backup-Management-Software, und normalerweise ist es Barman.
Er hat mehrere Vorteile. Das Hauptplus ist ein sehr verbreitetes Dienstprogramm, es hat eine riesige Community, eine große Anzahl von Fragen zum Stapelüberlauf.
Sie müssen nur einen Sicherungsserver auswählen und dort alle Ihre PostgreSQL-Daten sichern. Dies ist sehr praktisch - solange ein Sicherungsserver für Sie ausreicht.
Sobald Sie viele Sicherungsserver haben, müssen Sie überwachen, ob einer von ihnen voll ist. Im Falle eines Ausfalls eines Sicherungsservers müssen Sie wissen, welche Ihrer Datenbanken jetzt in Gefahr sind. Sie müssen im Prinzip verstehen, wo ein neuer Datenbankcluster beim Erstellen kopiert werden muss.
Es gibt ein viel einfacheres Dienstprogramm zum Entfernen von Backups namens WAL-E.
WAL-E führt vier Hauptbefehle aus. Der WAL-PUSH-Befehl sendet eine WAL-Datei an die Cloud, und der WAL-FETCH nimmt eine WAL-Datei, wenn der Befehl restore_command wiederhergestellt werden muss.
Es gibt auch BACKUP-PUSH (implementiert das Entfernen der Backup-API) und BACKUP-FETCH (nimmt alle Daten aus der Cloud). Daten werden in der Cloud gespeichert, sodass Sie nichts überwachen müssen. Dies ist bereits ein Cloud-Service-Problem. So stellen Sie sicher, dass Ihre Daten bei Bedarf verfügbar sind. Dies ist wahrscheinlich der Hauptvorteil des WAL-E.
Es gibt ziemlich viele Funktionen. Es gibt eine Liste von Sicherungen, es gibt eine Aufbewahrungsrichtlinie, dh wir möchten beispielsweise Sicherungen für die letzten sieben Tage oder die letzten fünf Sicherungen, so etwas, speichern. Und WAL-E kann auf einer Vielzahl von Cloud-Diensten sichern: S3, Azure, Google und das lokale Dateisystem können als Cloud bezeichnet werden.
Es hat mehrere Eigenschaften. Erstens ist es in Python geschrieben und verwendet aktiv die Unix-Pipeline, teilweise aus diesem Grund hat es Abhängigkeiten und ist nicht sehr produktiv. Dies ist normal, da sich WAL-E auf Benutzerfreundlichkeit und einfache Einrichtung konzentriert, damit Sie bei der Erstellung eines Sicherungsplans keinen Fehler machen können. Und das ist eine sehr gute Idee.
In WAL-E sind viele Funktionen geschrieben, und wo die Autoren sie weiterentwickelt haben, war den Autoren nicht sehr klar. Die Idee kam, dass ich ein neues Werkzeug brauche.
Das Hauptmerkmal ist, dass es in Go neu geschrieben wurde, fast keine externen Abhängigkeiten aufweist, wenn Sie keine externe Verschlüsselung verwenden, und dass es viel produktiver ist.
WAL-G wurde ursprünglich von zwei Autoren von Citus Data erstellt. Der Hauptvorteil wird in diesem Histogramm gezeigt - die Geschwindigkeit beim Senden von „Wellen“. Wir sehen, dass WAL-E schnell ist, es kann alles sein, es kann eine große Spalte nahe Null sein.
WAL-G hat eine ziemlich stabile Bandbreite. Bei Tests bei Citus Data zeigte er, dass er stabil etwa 800 Mb / s „Wellen“ sendet.
Außerdem habe ich in WAL-G beispielsweise eine Funktion geschrieben, die die Sicherung von einem Replikat implementiert. Sie müssen Ihren DB-Master nicht mit einer Leselast laden, sondern können die Sicherung aus dem Replikat entfernen.
Aber es gibt ein kleines Problem. In dem Moment, in dem Sie mit der Sicherung beginnen, sollten Sie die Sicherung irgendwie benennen. Der Name enthält eine Zeitleiste, die geändert wird, wenn ein Replikat heraufgestuft wird. Wenn in der Replikatkette vor dem Replikat, mit dem Sie sichern, ein Failover auftritt, werden Sie einige der Replikate bemerken und die Zeitachse wird geändert. WAL-G ist sich bewusst, dass diese Situation nicht konsistent ist, da der Name einen Namen auf der alten Zeitachse enthält und Ihnen verspricht, dass Sie die Entwicklung des Datenbankverlaufs in jede vorhandene Richtung fortsetzen können. Das ist aber nicht so. Sie sind bereits in eine der Richtungen gegangen und können mit dem hinteren Auto nicht zu einer anderen Zeitachse springen. Daher versteht WAL-G diese Situation und lädt keine steuerliche JSON-Datei in die Cloud hoch. Sie erstellen eine physische Kopie. Es ist jedoch ein Eingreifen des Administrators erforderlich, damit diese Kopie verwendet werden kann.
Wir haben Delta-Kopien in WAL-G implementiert, ich habe auch an dieser Entwicklung gearbeitet. Auf diese Weise können Sie bei der nächsten Basissicherung weniger Daten aufnehmen. Sie erstellen keine Kopie der Datenseiten, die sich gegenüber der vorherigen Sicherung nicht geändert haben.
Beim Einrichten von WAL-G geben Sie die Anzahl der Schritte an, die am weitesten von der Basissicherung, der Delta-Sicherung, entfernt sind, und geben die Delta-Kopierrichtlinie an. Entweder erstellen Sie eine Kopie des letzten vorhandenen Deltas oder Sie erstellen ein Delta aus der ursprünglichen vollständigen Sicherung. Dies ist erforderlich, wenn sich in Ihrer Datenbank immer dieselbe Datenbankkomponente ändert und sich dieselben Daten ständig ändern.
Warum brauchen wir grundsätzlich Delta-Kopien der Datenbank? Theoretisch haben Sie eine WAL und können also überall rollen.
Auf einem ausgelasteten Server kann das Spielen der WAL von fünf physischen Sekunden der Vergangenheit vier physische Sekunden der Gegenwart dauern. Wenn Sie aufgefordert werden, die WAL in vier Tagen zu würfeln, bedeutet dies, dass die Person, die dies wünscht, möglicherweise weitere drei Tage warten sollte. Nicht immer eine akzeptable Situation.
Sie benötigen für jeden Tag Basissicherungen, können jedoch nicht 7 oder 14 vollständige Kopien Ihrer Datenbank dort speichern, obwohl WAL-G sie archiviert, sie ist jedoch immer noch recht groß. In diesem Fall helfen Delta-Kopien.
Bei der Entwicklung von Delta-Kopien wurden mehrere mögliche Datendateiformate diskutiert. Zunächst wurde das Format vorgeschlagen. Wenn wir die Seite nicht verunsichern, machen wir sie einfach ungültig. Wir sind jedoch zu dem Schluss gekommen, dass dies kein sehr effektiver Weg ist. Die Nullen werden dann effektiv komprimiert. Wir haben diese Speichermethode jedoch abgelehnt, da es schwierig ist, sie in Notfallsituationen zu debuggen.
Die nächste Technologie, die in Betracht gezogen wurde, besteht darin, zuerst die Blocknummer und dann den geänderten Block zu speichern. Hier sehen wir uns jedoch mit der Besonderheit der Speicherung in TAR-Dateien konfrontiert, dass wir zuerst die Größe der TAR-Dateien angeben müssen, in denen wir unsere Delta-Kopie speichern, und dann mit der Aufzeichnung beginnen müssen. Ich wollte die Implementierung der Technologie mit einem Minimum an verbrauchtem RAM durchführen, also mussten wir das dritte Format verwenden, in dem wir zuerst jede Datendatei vollständig lesen, nach den geänderten Datenseiten suchen, zuerst die Nummern der geänderten Blöcke in der TAR-Datei speichern und erst dann die geänderten Blöcke selbst.
Diese Funktion wurde noch nicht implementiert. Ich schaue sie an oder suche jemanden, der eine Pull-Anfrage in WAL-G stellen möchte. Bei der Wiederherstellung von einer Delta-Kopie überlebt die Datenbank jede Reinkarnation der Datenbank bei jedem Schritt der Delta-Sicherung. Manchmal werden mitten im Leben einige Dateien gelöscht. Gleichzeitig müssten wir uns keine Sorgen um ihren Zustand machen, wenn sie trotzdem gelöscht und dann aus der Delta-Kopie neu erstellt würden. Dies scheint keine sehr komplizierte Funktion zu sein. Wenn Sie also etwas über Go schreiben möchten, schauen Sie sich diese Funktion an.
Zeitplan für die Verwendung von Netzwerk, CPU und Festplatte. Wie wir sehen können, ist das Backup bei WAL-E hier noch nicht beendet. Es begann um ein Uhr morgens in Moskau und endete nicht beim letzten Bericht, den wir sehen. Der WAL-G-Zeitplan ist abgelaufen, er arbeitet schneller und ist sogar noch ressourcenschonender.
Das Interessanteste ist das Diagramm des Ressourcenverbrauchs während einer Delta-Kopie. Wir sehen, dass alle Ressourcen fast Null geworden sind. Die Belastung der CPU entspricht fast der Standardlast der Datenbank. Nachts werden einige Abfragen ausgeführt. Wir sehen einen großen Stift beim Lesen. Ich beschäftige mich auch damit, ich würde auch gerne eine Anfrage ziehen oder ich werde es im Sommer selbst machen. Das Fazit ist, dass wir unsere Daten noch lesen müssen, um herauszufinden, was sich an ihnen geändert hat. Dieses Lesen hätte vermieden werden können.
In WAL-G wird gelöscht, wenn die Anzahl der Sicherungen oder das Datum angegeben wird, ab dem alle WALs und alle Basissicherungen gespeichert werden müssen. Und WAL-G beschäftigt sich bereits mit der Frage, welche WALs und Basissicherungen benötigt werden. Bisher haben wir keine Funktionen, die alles löschen würden. In WAL-E ist dies auch ein Anlass für eine Pull-Anfrage. Ein interessanter Befehl ALLES LÖSCHEN wurde noch nicht implementiert.
Es gibt eine Liste von Backups.
Wir legen die Umgebungsvariable fest, die für die Funktion von WAL-G erforderlich ist, und rufen das Konsolendienstprogramm WAL-G auf. Die Backups, die wir anzeigen müssen, werden angezeigt.
WAL-G implementiert eine Vielzahl von Technologien zur Parallelisierung von Backups und allgemein verschiedenen Vorgängen. Diese Technologie wird beispielsweise verwendet, um „Wellen“ an das Archiv zu senden. Sobald PostgreSQL archive_command aufruft, um eine Datei zu senden, prüft WAL-G, ob weitere Dateien in der Nähe bereitstehen.
Im Allgemeinen ist dies keine sehr dokumentierte Funktion, sie ist in den neuesten Versionen von PostgreSQL sehr stabil, viele Technologien verwenden sie. Wir prüfen, ob sich fertige WAL-Dateien im Archivstatus befinden, und senden sie zusammen mit der Datei, die die Datenbank an das Archiv senden soll. Und wenn PostgreSQL sie zum Senden auffordert, haben wir sie bereits gesendet, wir sind bereit. Dies beschleunigt das Senden von WALs auf geladenen Basen erheblich und ermöglicht es Ihnen, diese nicht als Single-Threaded zu erstellen. Normalerweise bereitet PostgreSQL eine Datei vor, wartet dann darauf, dass sie abläuft, und bereitet die nächste vor. Wir schaffen es, diese konsequente Arbeit zu vermeiden.
Während WAL-FETCH, wenn der Cluster wiederhergestellt ist, versuchen wir auch, die folgenden N Dateien herunterzuladen, die benötigt werden, und versuchen, die Pausen zwischen den Starts der Voreinstellung neuer WAL-Dateien auszugleichen, damit wir alle Ressourcen, die wir haben, so weit wie möglich nutzen können: entweder in das Netzwerk laufen oder in seltenen Fällen auf eine Festplatte stoßen.
Dies wird alles durch Umgebungsvariablen festgelegt.
Es besteht auch die Möglichkeit, eine Kopie zu erstellen. Obwohl diese Funktion in verschiedenen Versionen nicht vorhanden ist - A. B. wurde im Juni 2018 in Version 0.1.10 veröffentlicht -, können Sie aufgrund der Parallelität des Lesens von der Festplatte garantiert entweder auf ein Netzwerk oder eine Festplatte zugreifen. Dies ist bei einer geladenen Datenbank nicht sehr gut. WAL-E hatte eine Funktion, die das Drosseln ermöglichte. Bisher haben wir das nicht. Es ist notwendig, die Geschwindigkeit des Entfernens von Backups zu begrenzen, damit die Basis ihr eigenes Leben führen und die Last bedienen kann.
Unser Hauptmerkmal ist nicht wirklich Technologie.
Vor zwei Jahren hat Zhenya Dyukov die
Delta-Backup-Technologie für Barman implementiert. Sie wurde noch nicht durchgeführt, die Community diskutiert immer noch darüber.
Vor fast einem Jahr hat Zhenya den WAL-E-Fehler behoben und wir haben ihn sechs Monate lang gesendet (
Link zu GitHub - ca. Ed.). Sehr oft gibt es bei Open Source-Lösungen ein Problem mit der Tatsache, dass sie nicht sehr gut gewartet werden.
Mit WAL-G ist alles ganz einfach: Wir verwenden es und ich pflege es. Wenn wir oder Sie etwas brauchen, melden Sie einfach, dass Sie ein Problem haben. Wir werden versuchen, es zu lösen.
Die Standardanfrage der Community ist einfach: "Lass es uns am meisten tun."
Mehr Kryptographie, mehr Plattformen. Vielleicht nicht nur PostgreSQL, sondern auch MySQL noch Backup oder etwas anderes? Ich sehe noch ein paar andere Dinge.
Zunächst konnten wir beim Senden der „Welle“ verstehen, welche Datenbankblöcke sich geändert haben, diese WAL-Dateien scannen und Informationen darüber speichern, was sich geändert hat.
Und wenn cron mit einem anderen Delta-Backup ankommt, konnten wir nicht die gesamte Datenbank scannen, den Zahn des Festplattenlesens ablegen und nur wissen, welche Seiten wir in die Cloud ziehen müssen.
Wir haben versucht, die Page-Track-Technologie zu verwenden. Es implementiert die Verfolgung von Seitenänderungen auf der Ebene des Datenbankkerns. Backup wird sehr schnell entfernt. Das Hauptproblem bei PTRACK ist, dass es sehr invasiv ist. Es enthält viele Änderungen im PostgreSQL-Kern an sehr sensiblen Stellen, so dass es unwahrscheinlich ist, dass es bald übernommen wird.
Außerdem unterscheiden sich seine Deltas geringfügig von den Deltas, die wir jetzt haben. Beim Entfernen des LSN-basierten Deltas werden alle Änderungen in der Delta-Datei entfernt, die vom vorherigen Start bis zur aktuellen Zeit aufgetreten sind.
Im Fall von PTRACK erhalten wir Änderungen in der Delta-Datei, beginnend mit dem zuvor empfangenen Delta. Wir haben nicht die genaue Deltazeit vor dem Start der Sicherung, vor dem Beginn der Änderungen. Dies ist nicht das Hauptproblem von PTRACK, im Allgemeinen funktioniert es gut, aber bisher ist es schwer zu akzeptieren.
PTRACK erlaubt keine Delta-Entfernung im LATEST_FULL-Modus, da eine Karte mit geänderten Blöcken aus der vorherigen Entfernung dieser Karte gespeichert wird. Oracle hat eine interessante Technologie, es gibt 8 vorherige Karten, die sie für alle Fälle speichern. Vielleicht könnten wir etwas Ähnliches tun, aber bisher arbeiten wir nicht in diese Richtung.
Im September letzten Jahres habe ich versucht, der Community eine Technologie anzubieten, die auf der Tatsache basiert, dass wir nur die erforderlichen Hooks zum Kernel hinzufügen und das Tracking für geänderte Seiten in Erweiterung implementieren, damit der Seitenverfolgungs-Patch nicht zu invasiv ist. Nachdem wir diese Technologie besprochen hatten, kamen wir zu dem Schluss, dass wir mehrere Prototypen benötigen, und wir werden Haken hinzufügen, wenn es Prototypen gibt. Vielleicht werden wir sehen, wie sie funktionieren. Ich arbeite derzeit an Prototypen dieser Erweiterungen, die Kernel-Hooks verwenden könnten, um Datenbankänderungen zu verfolgen.
In der Community gibt es den Ausdruck, dass jeder Postgresista sein eigenes Backup-Tool haben muss. Das ist schlecht. Jeder macht sein eigenes Ding, das geschäftskritische Aufgaben erledigt. Es muss eine Sache geben, in der alles in der Box sein wird, alles wird in einer idealen Welt perfekt sein.
Was möchte ich in einer Box in Basebackup sehen? Wir möchten wahrscheinlich sehen, dass in der Cloud archiviert wird. Und Delta-Kopien.
Ich möchte auch Komprimierung, Parallelität, Verschlüsselung, Drosselung, Auflistung von Sicherungen, Überprüfung, Validierung von Sicherungen ... Viele Dinge. Wir verstehen, dass wenn all dies jetzt der Community angeboten wird, dies zu mehreren Dutzend Patches führen wird, die durch Commitfest nur schwer zu diskutieren und zu implementieren sind. Daher verwenden wir jetzt immer noch ein separates Tool, aber es besteht der Wunsch, der Community Zeit und Technologie zu widmen, um PostgreSQL besser zu machen.