Ich habe ein ZFS auf einer Festplatte mit ZIL SLOG auf einer SSD.
Falls das relevant ist, ich habe auch einen LARC-Cache auf einer SSD.
Wie kann ich es neu konfigurieren, um sicherzustellen, dass ein Ausfall der SSDs keine Dateninkonsistenz verursacht (Nichteinhaltung der Ergebnisregeln für POSIX-Dateisystemaufrufe, wie z. B. das Vermischen von Inhalten zweier write()Operationen, die in einem einzelnen Thread nacheinander erfolgen)?
Ich möchte sicherstellen, dass meine PosgreSQL-Datenbank auf ZFS nicht inkonsistent wird, wenn ich einen Sicherungs-Snapshot der Festplatte wiederherstelle, ohne die SSDs wiederherzustellen. (Ich treffe Maßnahmen zur Synchronisierung von PostgreSQL, sodass (sofern Postgre keine Fehler aufweist) ein POSIX-korrektes Dateisystem gewährleistet, dass die Datenbank nicht inkonsistent wird.)
Antwort1
Das ZIL soll nur für einen kurzen Zeitraum nicht festgeschriebene Schreibvorgänge auf stabilen Festplatten enthalten. Wenn Sie gleichzeitig einen Stromausfall und einen SSD-Fehler hatten, könnte dies ein Problem darstellen. Wenn die SSD jedoch ausfällt, während alles ansonsten normal ist, sollte ZFS einfach vom Äquivalent des RAID-Schreibens zurück zum RAID-Schreibdurchgangsmodus wechseln. Die Leistung könnte sinken, aber nichts sollte sofort beschädigt werden.
Der Sinn von ZIL besteht darin, Änderungen schnell in den nichtflüchtigen Speicher zu schreiben, damit die Anwendung schnell zum Fortfahren aufgefordert werden kann. Wenn der Strom ausfällt, bevor diese Änderungen auch in den stabilen Speicher (Festplatte) geschrieben werden, werden sie beim nächsten Mounten des ZFS-Volumes nach dem Einschalten von ZIL in den stabilen Speicher kopiert.
Der Sinn eines Dateisystem-Snapshots besteht darin, dass Sie eine stabile Version des Dateisystems zum Kopieren erhalten, in die nicht aktiv geschrieben wird. Dies hat nichts mit ZIL zu tun, da der Snapshot nicht beschreibbar sein sollte, sodass ZIL keine ausstehenden Schreibvorgänge dafür hat.
Allerdings ist PostgreSQL möglicherweise nicht glücklich, wenn ein Dateisystem-Snapshot wiederhergestellt wird. Sofern PostgreSQL nicht auch angewiesen wird, direkt vor dem ZFS-Snapshot einen Snapshot zu erstellen oder anzuhalten, könnte der ZFS-Snapshot einige teilweise PostgreSQL-Schreibvorgänge enthalten, was ein Problem darstellen könnte. Sie sollten vielleicht eine separate Frage dazu stellen, wie man eine PostgreSQL-Datenbank richtig sichert. (... es sei denn, jemand anderes möchte das hier behandeln.)
Antwort2
Man kann sich das SLOG als unabhängig vom Datensatz vorstellen. Das bedeutet, dass, sobald Ihre pg-Daten auf die Festplatte geschrieben wurden, ein Snapshot des Datensatzes erstellt und gesichert werden kann und der Snapshot wiederhergestellt werden kann (im selben Pool und/oder in einem anderen Pool), unabhängig davon, ob er über ein Protokollgerät verfügt oder nicht.
Wenn Sie beabsichtigen, ein log(SLOG)- oder cache(L2ARC)-Gerät physisch aus Ihrem Pool zu entfernen, sollten Sie es natürlich zuerst logisch entfernen:
zpool remove [poolname] [logdevice|cachedevice]
(Sehen man zpool-remove)
Wenn Sie ein SLOG nicht richtig entfernen, kann der Pool beim nächsten Neustart möglicherweise nicht importiert werden. Die Wiederherstellung kann recht einfach sein (wenn sich keine ungelöschten Daten mehr im SLOG befinden) oder schwierig/unmöglich, ohne eine gewisse Beschädigung Ihrer Daten in Kauf zu nehmen. Es gibt einen Grund, warum oft empfohlen wird, zwei SLOG-Geräte als gespiegeltes Paar hinzuzufügen, und zwar um genau dieses Problem zu vermeiden – d. h. um zu vermeiden, dass es einen einzelnen Ausfallpunkt gibt, der Ihren Pool beschädigen kann.
Ich würde immer noch regelmäßige pg_dumpBackups erstellen (auf einen anderen Datensatz mit eigenem Snapshot und Backup-Zeitplan), weil ich denke, dass Text-Dumps zuverlässiger sind als Binärdateien - insbesondere, wenn der Binär-Snapshot erstellt wurde, während der PostgreSQL-Server noch lief (der ServerMainicht alles aus dem Speicher auf die Festplatte geschrieben haben, als der Snapshot erstellt wurde... aber durch das Herunterfahren des Servers wird alles geschrieben, was für einen Neustart im gleichen Zustand erforderlich ist). Auch, weil mehr Backups bei wichtigen Daten besser sind.
Übrigens habe ich vor Jahren ein einfaches PostgreSQL-Backup-Skript geschrieben, das alles ausgibt, dann die pg-Globals (Rollen usw.), dann das Schema für jede Datenbank und Tabelle und dann die Daten (als COPY ... FROM) und dann die Daten erneut als Spalteneinfügungen. Ich verwende Varianten davon seit etwa 20 Jahren. Ich habe eine Version davon auf ServerFault unter gepostet.Was ist die beste Möglichkeit, die Sicherung von PostgreSQL-Datenbanken zu automatisieren?im Jahr 2009.
Diese Version muss wahrscheinlich ein paar Mal geringfügig optimiert werden (insbesondere an der DBS=( $($PSQL --list --tuples-only ...) )Zeile, die die Liste der Datenbanken abruft). Und wenn das Sicherungsverzeichnis ein ZFS-Dataset mit einem eigenen Snapshot-Zeitplan ist, benötigen Sie weder die YMD-Unterverzeichnisse noch das find ... -mtime +30 ...zum Löschen alter Sicherungen. Außerdem müssen Sie weder eine Pipe pg_dumpnoch pg_dumpalleine Inleitung durchführen gzip, sondern nur die Komprimierung des Sicherungsdatasets verwenden.