„Es ist paradox, aber wahr, zu sagen, je mehr wir wissen, desto unwissender werden wir im absoluten Sinne, denn nur durch Erleuchtung werden wir uns unserer Grenzen bewusst. Gerade eines der erfreulichsten Ergebnisse der intellektuellen Evolution ist die ständige Erschließung neuer und größerer Perspektiven.“ Nikola Tesla
PostgreSQL ist ein großartiges Projekt und entwickelt sich mit erstaunlicher Geschwindigkeit. Wir werden uns mit einer Reihe von Blogbeiträgen auf die Entwicklung der Fehlertoleranzfunktionen in PostgreSQL in allen Versionen konzentrieren.
PostgreSQL auf den Punkt gebracht
PostgreSQL ist von Natur aus fehlertolerant. Erstens ist es ein fortschrittliches Open-Source-Datenbankverwaltungssystem und feiert dieses Jahr seinen 20. Geburtstag. Daher ist es eine bewährte Technologie und hat eine aktive Community, dank derer es einen schnellen Entwicklungsfortschritt hat.
PostgreSQL ist SQL-kompatibel (SQL:2011) und vollständig ACID-konform (Atomizität, Konsistenz, Isolation, Haltbarkeit).
PostgreSQL ermöglicht die physische und logische Replikation und verfügt über integrierte Lösungen für die physische und logische Replikation. Wir werden über Replikationsmethoden (in den nächsten Blogbeiträgen) in PostgreSQL in Bezug auf Fehlertoleranz sprechen.
PostgreSQL ermöglicht synchrone und asynchrone Transaktionen, PITR (Point-in-Time Recovery) und MVCC (Multiversion Concurrency Control). Alle diese Konzepte sind auf einer gewissen Ebene mit Fehlertoleranz verbunden, und ich werde versuchen, ihre Auswirkungen zu erklären, während ich notwendige Begriffe und ihre Anwendungen in PostgreSQL erkläre.
PostgreSQL ist robust!
Alle Aktionen auf der Datenbank werden innerhalb von Transaktionen ausgeführt , geschützt durch ein Transaktionsprotokoll die im Falle eines Softwarefehlers eine automatische Wiederherstellung nach einem Absturz durchführt.
Datenbanken können optional mit Datenblockprüfsummen erstellt werden zur Diagnose von Hardwarefehlern. Es gibt mehrere Sicherungsmechanismen mit vollständigem und detailliertem PITR, falls eine detaillierte Wiederherstellung erforderlich ist. Es steht eine Vielzahl von Diagnosetools zur Verfügung.
Die Datenbankreplikation wird nativ unterstützt. Synchrone Replikation kann mehr als „5 Neunen“ (99,999 Prozent) liefern Verfügbarkeit und Datenschutz, sofern ordnungsgemäß konfiguriert und verwaltet.
In Anbetracht der obigen Fakten können wir leicht behaupten, dass PostgreSQL robust ist!
PostgreSQL-Fehlertoleranz:WAL
Write-Ahead-Protokollierung ist das wichtigste Fehlertoleranzsystem für PostgreSQL.
Die WAL besteht aus einer Reihe von Binärdateien, die in das Unterverzeichnis pg_xlog des PostgreSQL-Datenverzeichnisses geschrieben werden. Jede an der Datenbank vorgenommene Änderung wird zuerst in WAL aufgezeichnet, daher der Name „Write-Ahead“-Protokoll als Synonym für „Transaktionsprotokoll“. Wenn eine Transaktion festgeschrieben wird, besteht das standardmäßige – und sichere – Verhalten darin, die WAL-Datensätze auf die Festplatte zu zwingen.
Sollte PostgreSQL abstürzen, wird die WAL erneut wiedergegeben, wodurch die Datenbank auf den Punkt der letzten festgeschriebenen Transaktion zurückgesetzt wird und somit die Dauerhaftigkeit aller Datenbankänderungen sichergestellt wird.
Transaktion? Bestätigen?
Datenbankänderungen selbst werden beim Commit der Transaktion nicht auf die Festplatte geschrieben. Diese Änderungen werden einige Zeit später vom Hintergrundschreiber oder Checkpointer auf einem gut abgestimmten Server auf die Festplatte geschrieben. (Überprüfen Sie die WAL-Beschreibung oben. )
Transaktionen sind ein grundlegendes Konzept aller Datenbanksysteme. Der wesentliche Punkt einer Transaktion ist, dass sie mehrere Schritte in einer einzigen Alles-oder-Nichts-Operation bündelt.
Die Zwischenzustände zwischen den Schritten sind für andere gleichzeitige Transaktionen nicht sichtbar, und wenn ein Fehler auftritt, der den Abschluss der Transaktion verhindert, wirkt sich keiner der Schritte überhaupt auf die Datenbank aus. PostgreSQL unterstützt keine Dirty-Reads (Transaktion liest Daten, die von einer gleichzeitigen, nicht festgeschriebenen Transaktion geschrieben wurden ).
Kontrollpunkt
Die Wiederherstellung nach einem Absturz wiederholt die WAL, aber ab welchem Punkt beginnt sie mit der Wiederherstellung?
Die Wiederherstellung beginnt an Punkten im WAL, die als Checkpoints bezeichnet werden . Die Dauer der Wiederherstellung nach einem Absturz hängt von der Anzahl der Änderungen im Transaktionsprotokoll seit dem letzten Prüfpunkt ab. Ein Prüfpunkt ist ein bekanntermaßen sicherer Ausgangspunkt für die Wiederherstellung, da er garantiert, dass alle vorherigen Änderungen an der Datenbank bereits auf die Festplatte geschrieben wurden.
Ein Kontrollpunkt kann entweder unmittelbar sein oder geplant . Sofortige Checkpoints werden durch eine Aktion eines Superusers ausgelöst, wie z. B. CHECKPOINT Befehl oder andere; Geplante Checkpoints werden automatisch von PostgreSQL entschieden.
Schlussfolgerung
In diesem Blogbeitrag haben wir wichtige Funktionen von PostgreSQL aufgelistet, die mit der Fehlertoleranz in PostgreSQL zusammenhängen. Wir haben Write-Ahead-Protokollierung, Transaktion, Commit, Isolationsstufen, Prüfpunkte und Wiederherstellung nach einem Absturz erwähnt. Wir werden im nächsten Blogbeitrag mit der PostgreSQL-Replikation fortfahren.
Referenzen:
PostgreSQL-Dokumentation
PostgreSQL 9 Administration Cookbook – Zweite Ausgabe
