Ich habe viel über AWS EBS gelesen und viele Leute scheinen die Leute zu ermutigen, das Dateisystem einzufrierenwährendder Schnappschuss. Dieser Teil der Amazon-Dokumentation ist jedoch anderer Meinung:
Während der Fertigstellung wird ein in Bearbeitung befindlicher Snapshot nicht durch laufende Lese- und Schreibvorgänge auf dem Datenträger beeinflusst.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
Warum frieren viele Leute das Dateisystem während des Snapshots ein, obwohl in der AWS-Dokumentation steht, dass der Snapshot nicht durch E/A beeinflusst wird?
Was passiert, wenn mein Dateisystem für ein FTP verwendet wird?
Was passiert, wenn mein Dateisystem für eine Datenbank verwendet wird?
Antwort1
Kurze Antwort:es hängt wirklich von der Art der Anwendung ab, die Sie auf Ihrer Instanz ausführen.
Lange Antwort:Im Grunde genommen ist das Aufnehmen eines unberuhigten Schnappschusses einer laufenden Maschine vergleichbar mit dem „Ziehen des Netzsteckers“ – also einem plötzlichen, sofortigen, unerwarteten Absturz.
Bei aktivierter I/O-Barriere sollte das moderne Journaled-Dateisystem trotz Abstürzen konsistent sein. Diesnichtbedeutet, dass die im Speicher gespeicherten Daten nicht verloren gehen, sondern dass die festgeschriebenen Datengarantiertzur Speicherung auf einem dauerhaften Speicher (z. B. Festplatte).
Dies gilt für alle ordnungsgemäß journalisierten Anwendungen, insbesondere für ACID-kompatible Datenbanken (eine nicht abschließende Liste: MSSQL, InnoDB, PostgreSQL, Oracle, IBM DB2 usw.). Auch dies giltnichtbedeutet, dass ein plötzlicher Stromausfall (oder ein wiederhergestellter, nicht in den Ruhezustand versetzter Snapshot) nicht zu Datenverlust führt; es bedeutet vielmehr, dass bei der Rückkehr eines (möglicherweise impliziten) COMMIT alle relevanten Daten im stabilen Speicher vorhanden sind.
Bei einer solchen Journalanwendung müssen Sie das Dateisystem nicht unbedingt stilllegen. Beim ersten Booten nach einem wiederhergestellten Snapshot antwortet das System auf seine Journale (Dateisystem und Datenbanken) und es wird ein konsistenter Zustand erreicht.
Es gibt jedoch viele Anwendungen, dienichtihre Aktualisierungen ordnungsgemäß protokollieren und welcheerforderndas Äquivalent einesfsck um zu einem konsistenten Zustand zurückzukehren. Das wichtigste Beispiel ist MySQL+MyISAM: Diese (sehr verbreitete) Datenbank-Engine istnichtACID-kompatibel, da die hohe Schreibgeschwindigkeit durch die Stapelverarbeitung unabhängiger E/A-Vorgänge unter geringer Berücksichtigung regulärer E/A-Barrieren erreicht wird. Bei einem unsachgemäßen Herunterfahren (z. B. Stromausfall, System- oder MySQL-Absturz, nicht beendeter Snapshot) kann die MyISAM-Datenbank funktionsunfähig sein, bis ein Herunterfahren mysqlcheck/mysqlrepairdurchgeführt wird.
In den verschiedenen Anleitungen wird empfohlen, das Dateisystem vor einem Snapshot ruhigzustellen. Der Grund dafür ist genau: Einige „unvorbereitete“ Anwendungen (z. B. MyISAM) können durch das plötzliche Herunterfahren und die anschließende Wiederherstellung etwas beschädigt werden, sodass eine Konsistenzprüfung erforderlich ist.
Endeffekt:wenn Sie ein Journal-Dateisystem mit aktivierten I/O-Barrieren verwenden (Standard bei ext4 und XFS)Undeine ACID-kompatible Datenbank, sollten Sie beim Erstellen von Snapshots ohne Beruhigung sicher sein. Im schlimmsten Fall wird beim Einbinden des Snapshots ein nicht schwerwiegender Fehler/eine Warnung angezeigt, aber die Journalantwort bringt das System in einen konsistenten Zustand. Wenn Sie jedoch MyISAM verwenden, ist es besser, Ihr Dateisystem vor dem Erstellen eines Snapshots einzufrieren/zu beruhigen.
Antwort2
Amazon-Snapshots selbst sind nicht sicher, wenn sie bei laufendem System erstellt werden. Sie sind sicher, wenn Sie das System vor dem Erstellen des Snapshots herunterfahren. Alle Dateisystemdaten, die in den Puffern des Betriebssystems oder in den Puffern einer Anwendung (z. B. Datenbanken) zwischengespeichert sind, sind nicht Teil des Snapshots. Dies kann zu irreparablen Beschädigungen führen.
Sowohl Linux als auch Windows verfügen über vom Betriebssystem bereitgestellte Mechanismen zum Einfrieren des Systems (die Anwendungen werden angewiesen, ihre Daten auf die Festplatte zu übertragen). Sobald dies abgeschlossen ist, wird ein Auftauen durchgeführt, sodass die Anwendungen fortfahren können. Zwischen dem Einfrieren und Auftauen wird der Snapshot erstellt. Hinweis: Die meisten Anwendungen unterstützen das Einfrieren/Auftauen nicht und einige implementieren es falsch. Lesen Sie die Dokumentation Ihres Anbieters sorgfältig durch.
Ein weiterer wichtiger Punkt ist die Überprüfung, wo Ihre Anwendungen ihre Daten speichern. Datenbanken speichern ihre Daten, Protokolle usw. gemäß Best Practice-Design auf unterschiedlichen Dateisystemen. Dies bedeutet, dass Sie möglicherweise einen Snapshot eines Volumes zu einem anderen Zeitpunkt starten als den Snapshot eines anderen Volumes (dieser kann als Set erforderlich sein, um die Anwendung und ihre Daten erfolgreich wiederherzustellen).
Der Schlüssel liegt darin, den Unterschied zwischen absturzkonsistenten und anwendungskonsistenten Snapshots zu verstehen.
Hier ist ein Artikel zu EBS-Snapshots, der die Unterschiede erklärt.
EBS-Snapshots: absturzkonsistent vs. anwendungskonsistent
[Update nach Michaels Kommentaren]
Snapshots implementieren Copy-on-Write (COW). Sobald ein Snapshot gestartet wurde, kann das Dateisystem geändert werden. Wenn das Dateisystem in einen Festplattenblock schreibt, kopiert das COW-Subsystem den Originalblock in seinen internen Cache, sodass das Dateisystem während des Snapshots geändert werden kann.
Es ist nicht notwendig, das Dateisystem während des Snapshots eingefroren zu lassen. Während der Snapshot-Erstellung werden die erforderlichen Datenstrukturen des Volumes erstellt/kopiert, sodass das Einfrieren nicht erforderlich ist. Je nach System und der im Speicher zwischengespeicherten Datenmenge, der Größe der Betriebssystem- und Anwendungsjournale usw. kann der Einfrier-/Snapshot-/Auftauzyklus nur wenige Sekunden dauern.
Hier ist ein Artikel zu verschiedenen Snapshot-Technologien, der eine Erklärung zu Copy-on-Write enthält:
Verwendung unterschiedlicher Speicher-Snapshot-Technologien zum Schutz von Daten