Get best of the week

Buch „Datenbanken. Zuverlässigkeitstechnik

BildHallo habrozhiteli! Im Bereich der IT fand eine echte Revolution statt - sie begannen, mit der Infrastruktur wie mit Code zu arbeiten. Dieser Prozess schafft nicht nur neue Probleme, sondern auch Möglichkeiten, die Verfügbarkeit von Datenbanken sicherzustellen. Die Autoren haben diesen praktischen Leitfaden für alle vorbereitet, die der Community der modernen Datenbankzuverlässigkeitsingenieure (DBRE) beitreten möchten.

In diesem Buch: • Speicheranforderungen und Anforderungen an das Risikomanagement. • Erstellung und Entwicklung einer Architektur, die transparente Datenbankunterstützung bietet. • Optimierung des Release-Management-Prozesses. • Speicherung, Indizierung und Replikation von Daten. • Ermittlung der Merkmale des Data Warehouse und Auswahl der besten Optionen für dessen Verwendung. • Erforschung von Architekturkomponenten und Erstellung von Architekturen, die auf die Verarbeitung großer Datenmengen ausgerichtet sind.

Für wen ist dieses Buch?
, , . , . , . , , . .

, Linux/Unix, - / . , — — — . , , .

, , , . , , .

, , . , - , . , Excel, .

Publikationsstruktur
. . , , , . : , , , . , . !

, : (DBRE), (RE). , . DBR- , , .

, . . , . — , . , , , , , , , . .
, .

1 . , — , DBRE, — , , DBRE .

2 . , . , , — , . , .
3 . . .

4 . . , , . , .

5 6 . . , , , , , .

7 . , , DBE. — , . , , , .

8 . , ? SQL? — , .

9 . . .

10 , . , , . , .

11 . , , . , , , .

12 (), , , . , « » () , , . — .

, 13 . , .

Backup wiederherstellen


In den Kapiteln 5 und 6 haben wir uns auf das Entwerfen und Verwalten der Infrastruktur konzentriert. Dies bedeutet, dass Sie eine gute Vorstellung davon haben, wie verteilte Infrastrukturen, in denen Datenbanken funktionieren, erstellt und bereitgestellt sowie verwaltet werden. Wir haben Methoden zum schnellen Hinzufügen neuer Knoten untersucht, um die Kapazität zu erhöhen oder einen ausgefallenen Knoten zu ersetzen. Jetzt ist es an der Zeit, das Wichtigste zu besprechen - das Sichern und Wiederherstellen von Daten.

Seien wir ehrlich: Jeder erwägt, langweilige und langwierige Aktivitäten zu sichern und wiederherzustellen. Für die meisten sind diese Verfahren der Inbegriff von Routine. Das Team interagiert nicht gerne mit Nachwuchsingenieuren und externen Auftragnehmern und arbeitet mit Tools von Drittanbietern. Vorher mussten wir uns nur mit schrecklicher Backup-Software auseinandersetzen. Wir sympathisieren ehrlich mit Ihnen.

Dies ist jedoch einer der wichtigsten Prozesse in Ihrer Arbeit. Das Verschieben wichtiger Daten zwischen Knoten, Rechenzentren und das Übertragen in Langzeitarchive ist eine ständige Verschiebung des wertvollsten Vermögens Ihres Unternehmens - Informationen. Wir empfehlen dringend, dass Sie Wiederherstellungs- und Sicherungsvorgänge nicht als Vorgänge zweiter Klasse betrachten, sondern als VIP-Vorgänge behandeln. Jeder sollte nicht nur die Ziele der Datenwiederherstellung verstehen, sondern auch mit den Prinzipien dieser Arbeits- und Prozessüberwachung vertraut sein. Die DevOps-Philosophie geht davon aus, dass jeder in der Lage sein sollte, Code zu schreiben und in einem wirklich funktionierenden System zu implementieren. Wir laden jeden Techniker ein, mindestens einmal an kritischen Datenwiederherstellungsprozessen teilzunehmen.

Wir erstellen und speichern Kopien von Daten - Backups und Archive -, um einen bestimmten Bedarf zu decken. Sie werden für die Wiederherstellung benötigt. Manchmal ist die Wiederherstellung eine angenehme und gemächliche Angelegenheit, beispielsweise wenn eine Umgebung für Prüfer geschaffen oder eine alternative Umgebung eingerichtet wird. In den meisten Fällen ist es jedoch erforderlich, ausgefallene Knoten schnell zu ersetzen oder die Kapazität vorhandener Cluster zu erhöhen.

In verteilten Umgebungen stehen wir heute vor neuen Herausforderungen bei der Datensicherung und -wiederherstellung. Nach wie vor werden die meisten lokalen Datensätze innerhalb angemessener Grenzen bis zu maximal einigen Terabyte verteilt. Der Unterschied besteht darin, dass diese lokalen Datensätze nur Teil eines großen verteilten Satzes sind. Die Standortwiederherstellung ist ein relativ kontrollierter Prozess, aber das Aufrechterhalten des Status in einem Cluster ist eine schwierigere Aufgabe.

Grundprinzipien


Wir beginnen mit der Erörterung der Grundprinzipien der Datensicherung und -wiederherstellung. Für einen erfahrenen Datenbankspezialisten oder Systemingenieur scheinen einige von ihnen elementar zu sein. In diesem Fall können Sie problemlos durch mehrere Seiten scrollen.

Physisch oder logisch?


Eine physische Sicherung der Datenbank sichert die realen Dateien, in denen die Daten gespeichert sind. Dies bedeutet, dass die für die Datenbank typischen Dateiformate unterstützt werden. In der Regel enthält die Datenbank eine Reihe von Metadaten, die bestimmen, welche Dateien und welche Datenbankstrukturen sich in ihnen befinden. Wenn Sie beim Erstellen von Sicherungskopien von Dateien erwarten, dass eine andere Datenbankinstanz diese verwenden kann, müssen Sie eine Sicherung erstellen und die damit verbundenen Metadaten speichern, auf die sich diese Datenbank stützt, damit die Sicherung portabel ist.

Beim Erstellen einer logischen Sicherung werden die Daten aus der Datenbank in ein Format exportiert, das theoretisch auf jedes System übertragen werden kann. Normalerweise werden auch Metadaten gespeichert, aber höchstwahrscheinlich sind sie für den Moment relevant, in dem die Sicherung durchgeführt wurde. Ein Beispiel ist der Export aller Einfügeanweisungen, die zum Auffüllen einer leeren Datenbank beim Aktualisieren erforderlich sind. Ein weiteres Beispiel ist eine JSON-Zeichenfolge. Infolgedessen nehmen logische Sicherungen in der Regel viel Zeit in Anspruch, da es sich nicht um eine physische Kopier- und Schreiboperation handelt, sondern um eine zeilenweise Datenextraktion. In ähnlicher Weise geht die Wiederherstellung mit dem üblichen Datenbank-Overhead einher, z. B. dem Sperren und Erstellen von Wiederherstellungs- und Rückgängig-Protokollen.

Ein gutes Beispiel für diese Trennung ist die Unterscheidung zwischen zeilenbasierter Replikation und anweisungsbasierter Replikation. In vielen relationalen Datenbanken bedeutet agentenbasierte Replikation, dass nach dem Schreiben in das Versionskontrollsystem ein Journal mit Operatoren der Datenmanipulationssprache (DML oder Einfügen, Aktualisieren, Ersetzen, Löschen) hinzugefügt wird. Diese Anweisungen werden an die Replikate übergeben, in denen sie abgespielt werden. Ein anderer Ansatz für die Replikation basiert auf Zeichenfolgen oder CDC (Change Data Capture).

Autonom oder betriebsbereit?


Eine Offline- (oder Cold-) Sicherung ist eine Sicherung, bei der die Datenbankinstanz, die die Dateien verwendet, deaktiviert ist. Dank dieser Funktion können Sie Dateien schnell kopieren, ohne sich um die Beibehaltung des Status kümmern zu müssen, während andere Prozesse Daten lesen und schreiben. Dies ist eine ideale, aber sehr seltene Erkrankung.

Bei einer Online- (oder Hot-) Sicherung kopieren Sie weiterhin alle Dateien. Die Notwendigkeit, einen konsistenten Snapshot der Daten zu erstellen, die zu dem Zeitpunkt vorhanden sein müssen, zu dem die Sicherung durchgeführt wird, ist jedoch mit einer zusätzlichen Komplexität verbunden. Wenn der aktuelle Datenverkehr während der Sicherung auf die Datenbank zugreift, müssen Sie außerdem darauf achten, den Durchsatz des E / A-Subsystems auf Speicherebene nicht zu überschreiten. Selbst wenn Sie die Last begrenzen, können Sie feststellen, dass die zur Aufrechterhaltung der Konsistenz verwendeten Mechanismen zu unangemessenen Verzögerungen in der Anwendung führen.

Voll, inkrementell und differenziell


Eine vollständige Sicherung, unabhängig davon, welche Methode erstellt wird, bedeutet, dass der lokale Datensatz vollständig reserviert ist. Bei kleinen Datensätzen ist dies ziemlich häufig. Für 10 TB kann dies unglaublich viel Zeit in Anspruch nehmen.

Mit differenziellen Sicherungen können Sie nur Daten sichern, die sich seit der letzten vollständigen Sicherung geändert haben. In der Praxis werden jedoch in der Regel mehr Daten gesichert als nur die geänderten, da die Daten in Form von Strukturen einer bestimmten Seitengröße organisiert sind. Die Seitengröße beträgt beispielsweise 16 oder 64 KB, und die Seite enthält viele Datenzeilen. Differenzielle Sicherungen sichern alle Seiten, auf denen Daten geändert wurden. Somit werden bei großen Seitengrößen Sicherungen mit einer viel größeren Größe erhalten, als wenn nur modifizierte Daten dort gespeichert würden.

Inkrementelle Sicherungen ähneln differenziellen Sicherungen, mit der Ausnahme, dass das Datum der letzten Sicherung, auf die sich die geänderten Daten beziehen, inkrementell oder vollständig ist. Wenn Sie von einer inkrementellen Sicherung wiederherstellen, müssen Sie möglicherweise die letzte vollständige Sicherung sowie eine oder mehrere inkrementelle Sicherungen wiederherstellen, um zum aktuellen Punkt zu gelangen.

In diesem Wissen werden wir einige Punkte diskutieren, die bei der Auswahl einer effektiven Sicherungs- und Datenwiederherstellungsstrategie berücksichtigt werden sollten.

Überlegungen zur Datenwiederherstellung


Wenn Sie zum ersten Mal eine effektive Strategie auswählen, sollten Sie erneut Ihre Servicequalitätsziele (SLOs) berücksichtigen, die in Kapitel 2 erläutert wurden. Insbesondere müssen Sie die Verfügbarkeits- und Zuverlässigkeitsindikatoren berücksichtigen. Unabhängig davon, für welche Strategie Sie sich letztendlich entscheiden, sollte sie dennoch die Möglichkeit beinhalten, Daten innerhalb der vordefinierten Grenzen der Verfügbarkeit wiederherzustellen. Und Sie müssen schnell sichern, um sicherzustellen, dass Ihre Zuverlässigkeitsspezifikationen eingehalten werden.

Wenn Sie jeden Tag eine Sicherungskopie erstellen und die Transaktionsprotokolle zwischen den Sicherungen auf Standortebene speichern, können Sie diese Transaktionen leicht bis zur nächsten Sicherung verlieren.

Darüber hinaus müssen Sie berücksichtigen, wie der Datensatz in einem ganzheitlichen Ökosystem funktioniert. Beispielsweise können Ihre Bestellungen in einer relationalen Datenbank gespeichert werden, in der alles in Form von Transaktionen festgelegt ist und daher in Bezug auf andere in dieser Datenbank gespeicherte Daten leicht wiederhergestellt werden kann. Nach der Auftragserstellung kann der Workflow jedoch durch ein im Warteschlangensystem gespeichertes Ereignis oder durch die Speicherung des Typs "Schlüsselwert" ausgelöst werden. Diese Systeme können die Datenintegrität nur gelegentlich oder sogar kurz (kurzlebig) sicherstellen und bei Bedarf auf die relationale Datenbank verweisen oder sie für die Wiederherstellung verwenden. Wie werden diese Workflows während der Wiederherstellung berücksichtigt?

Wenn Sie sich in einer Umgebung befinden, in der eine schnelle Entwicklung im Gange ist, kann es sich herausstellen, dass die in der Sicherung gespeicherten Daten von einer Version der Anwendung geschrieben und verwendet wurden und nach dem Wiederherstellen einer anderen Version ausgeführt wird. Wie interagiert die Anwendung mit veralteten Daten? Wenn die Daten versioniert sind, kann dies berücksichtigt werden, aber Sie sollten sich dieser Möglichkeit bewusst sein und auf solche Fälle vorbereitet sein. Andernfalls kann die Anwendung diese Daten logisch beschädigen, was in Zukunft zu noch größeren Problemen führen wird.

All diese und viele andere Nuancen, die nicht vorhergesagt werden können, müssen bei der Planung der Datenwiederherstellung berücksichtigt werden. Wie in Kapitel 3 erwähnt, ist es unmöglich, sich auf eine Situation vorzubereiten. Es ist jedoch sehr wichtig, dies zu versuchen. Die Datenwiederherstellung ist eine der wichtigsten Aufgaben eines Ingenieurs, um die Zuverlässigkeit der Datenbank sicherzustellen. Daher sollte Ihr Datenwiederherstellungsplan so umfassend wie möglich sein und so viele potenzielle Probleme wie möglich berücksichtigen.

Wiederherstellungsszenarien


Nachdem wir alle oben genannten Punkte berücksichtigt haben, werden wir die Arten von Vorfällen und Vorgängen erörtern, die möglicherweise eine Datenwiederherstellung erfordern, damit alle Anforderungen geplant werden können. Zunächst können Sie alle Szenarien in geplante und ungeplante Szenarien unterteilen. Wenn Sie die Datenwiederherstellung nur als Instrument zur Lösung von Notfällen betrachten, beschränken Sie die Tools Ihres Teams nur auf die Notfallversorgung und simulieren Unfälle. Umgekehrt kann ein höheres Maß an Bewusstsein und eine erfolgreiche Lösung von Notfällen erwartet werden, wenn die Datenwiederherstellung in die täglichen Aktivitäten einbezogen wird. Darüber hinaus verfügen wir über weitere Daten, um festzustellen, ob die Wiederherstellungsstrategie unsere SLOs unterstützt. Mit ein paar täglichen Durchläufen des Skripts ist es einfacher, eine Reihe von Beispielen zu erhalten.Dies beinhaltet Grenzwerte und kann sehr sicher für die Planung verwendet werden.

Geplante Wiederherstellungsszenarien


In welche täglichen Aufgaben können Wiederherstellungsprozesse integriert werden? Hier ist die Liste, die wir am häufigsten auf verschiedenen Websites getroffen haben:

  • die Schaffung neuer Knoten und Cluster in einer industriellen Betriebsumgebung;
  • Schaffung verschiedener Umgebungen;
  • Durchführen von Extraktion, Transformation und Laden (Extrahieren, Transformieren und Laden, ETL) und Stufen des technologischen Datenverarbeitungsprozesses für sequentiell platzierte Speicher;
  • Leistungstest.

Stellen Sie bei der Ausführung dieser Vorgänge sicher, dass der Wiederherstellungsprozess im Betriebssteuerungsstapel enthalten ist. Betrachten Sie die folgenden Indikatoren.

  • Zeit. Wie lange dauert es, bis jede Komponente und der gesamte Prozess abgeschlossen sind? Auspacken? Kopieren? Protokollausführung? Testen?
  • Die Größe. Wie viel Speicherplatz benötigt ein Backup, komprimiert und unkomprimiert?
  • . ?

Mithilfe dieser Informationen können Sie Bandbreitenprobleme vermeiden und die Stabilität des Wiederherstellungsprozesses sicherstellen.

Neue Knoten und Cluster in einer industriellen Betriebsumgebung Unabhängig davon,

ob Ihre Datenbanken Teil einer unveränderlichen Infrastruktur sind oder nicht, gibt es Möglichkeiten für regelmäßige Neuerstellungen, bei denen bei Bedarf Wiederherstellungsverfahren verwendet werden.

Datenbanken werden aufgrund der Zeit, die für das erstmalige Laden eines neuen Knotens und dessen Platzierung in einem Cluster erforderlich sein kann, selten in die automatische Skalierung von Systemen einbezogen. Es gibt jedoch keine Gründe, die das Team daran hindern, einen Zeitplan für das regelmäßige Hinzufügen neuer Knoten zum Cluster zum Testen dieser Prozesse zu erstellen. Chaos Monkey ( http://bit.ly/2zy1qsE) - Ein von Netflix entwickeltes Tool, mit dem Systeme nach dem Zufallsprinzip heruntergefahren werden. Auf diese Weise können Sie den gesamten Prozess der Überwachung, Ausgabe von Benachrichtigungen, Sortierung und Wiederherstellung testen. Wenn Sie dies noch nicht getan haben, können Sie dies in den Plan der Checkliste der Prozesse aufnehmen, die Ihre Betriebsabteilung in regelmäßigen Abständen ausführen muss, damit sich alle Mitarbeiter mit dem Verfahren vertraut machen. Mit diesen Aktionen können Sie nicht nur die vollständige und inkrementelle Wiederherstellung testen, sondern auch die Replikation und den Prozess der Inbetriebnahme des Knotens.

Erstellen Sie verschiedene Umgebungen

Sie erstellen unweigerlich Entwicklungs-, Integrations- und Betriebstestumgebungen für Demonstrations- und andere Zwecke. Einige dieser Umgebungen erfordern eine vollständige Datenwiederherstellung und müssen eine Knotenwiederherstellung und eine vollständige Clusterwiederherstellung implementieren. In einigen Umgebungen gelten andere Anforderungen, z. B. Unterstützung für die teilweise Wiederherstellung zum Testen von Funktionen und zur Datenbereinigung, um die Privatsphäre der Benutzer zu gewährleisten. Auf diese Weise können Sie die Datenwiederherstellung zu einem bestimmten Zeitpunkt sowie die Wiederherstellung bestimmter Objekte testen. All dies unterscheidet sich stark von der standardmäßigen vollständigen Wiederherstellung und ist nützlich, um Schäden zu reparieren, die durch Bedieneraktionen und Anwendungsfehler verursacht wurden. Durch Erstellen einer APIDurch die Datenwiederherstellung auf Einrichtungsebene und zu einem bestimmten Zeitpunkt können Sie die Automatisierung und Einarbeitung der Mitarbeiter in diese Prozesse erleichtern.

ETL- und Pipeline-Prozesse für weiter unten in der Pipeline befindliche Data Warehouses

Bei der Erstellung einer Umgebung können Prozesse und Wiederherstellungs-APIs aus Snapshots oder auf der Ebene einzelner Objekte erfolgreich angewendet werden, wenn Daten aus Arbeitsdatenbanken zur weiteren Analyse und zum Stream-Speicher in Pipelines übertragen werden .

Feldtests

Während der Ausführung verschiedener Testszenarien benötigen Sie Kopien der Daten. Einige Tests, z. B. für Kapazität und Last, erfordern einen vollständigen Datensatz, was sich hervorragend für eine vollständige Wiederherstellung eignet. Für Funktionstests sind möglicherweise kleinere Datensätze erforderlich, die eine Wiederherstellung zu einem bestimmten Zeitpunkt und auf Einrichtungsebene ermöglichen.

Das Testen der Datenwiederherstellung selbst kann ein kontinuierlicher Vorgang sein. Zusätzlich zur Verwendung von Datenwiederherstellungsprozessen in alltäglichen Szenarien können Sie kontinuierliche Wiederherstellungsvorgänge konfigurieren. Dadurch werden Tests und Validierungen automatisiert, um Probleme, die bei einer Unterbrechung des Sicherungsprozesses auftreten können, schnell zu identifizieren. Bei der Implementierung dieses Prozesses fragen sich viele, wie der Erfolg einer Wiederherstellung überprüft werden kann.

Wenn Sie ein Backup erstellen, können Sie viele Daten abrufen, die Sie dann zum Testen verwenden können, zum Beispiel:

  • Die neueste Kennung in der Auto-Inkrement-Sequenz
  • Zeilenzähler für Objekte;
  • Prüfsummen für Teilmengen von Daten, die nur eingefügt werden und daher als unveränderlich angesehen werden können;
  • Prüfsummen in Schemadefinitionsdateien.

Wie bei jedem Test sollte der Ansatz mehrstufig sein. Es gibt eine Reihe von Tests, die entweder erfolgreich sind oder schnell fehlschlagen. Dies sollte die erste Teststufe sein. Beispiele sind das Vergleichen von Prüfsummen für Metadaten / Objektdefinitionen, das erfolgreiche Starten einer Datenbankinstanz und das erfolgreiche Herstellen einer Verbindung zu einem Replikationsdatenstrom. Vorgänge, die möglicherweise länger dauern, wie das Berechnen von Prüfsummen und das Zählen von Tabellen, sollten später während der Prüfung ausgeführt werden.

Ungeplante Skripte


Unter Berücksichtigung aller täglich geplanten Szenarien, die verwendet werden können, sollte der Datenwiederherstellungsprozess gut getestet, dokumentiert, ausgearbeitet und ausreichend fehler- und problemfrei sein. Dank dessen erweisen sich ungeplante Szenarien selten als so beängstigend wie sie sein könnten. Das Team sollte den Unterschied zwischen geplanter und ungeplanter Wiederherstellung nicht erkennen. Wir listen und betrachten detailliert Situationen, in denen wir möglicherweise Wiederherstellungsprozesse durchführen müssen:

  • Benutzerfehler
  • Anwendungsfehler;
  • Verfügbarkeit von Infrastrukturdiensten;
  • Betriebssystemfehler und Hardwarefehler;
  • Hardwarefehler;
  • Rechenzentrumsfehler.

Benutzerfehler Im

Idealfall sollten Benutzerfehler selten auftreten. Durch den Bau eines „Geländers“ und einer „Barriere“ für Ingenieure können Sie viele dieser Situationen verhindern. Es besteht jedoch immer die Möglichkeit, dass der Bediener versehentlich Schäden verursacht. Ein typisches Beispiel ist die überall und für alle vergessene WHERE-Klausel, wenn UPDATE oder DELETE in einer Datenbankclientanwendung ausgeführt wird. Oder die Ausführung des Datenbereinigungsskripts erfolgt beispielsweise nicht in einer Testumgebung, sondern in einem funktionierenden "Produktions" -System. Oft wird die Operation korrekt ausgeführt, aber zur falschen Zeit oder nicht für diese Hosts. All dies bezieht sich auf Benutzerfehler. Oft werden sie sofort identifiziert und korrigiert. Manchmal bleiben die Folgen solcher Änderungen jedoch mehrere Tage oder Wochen lang unbemerkt.

Anwendungsfehler

Anwendungsfehler sind die schlimmsten der diskutierten Szenarien, da sie sehr heimtückisch sein können. Anwendungen ändern ständig die Art und Weise, wie sie mit Data Warehouses interagieren. Viele Anwendungen verwalten auch die referenzielle Integrität und externe Zeiger auf Ressourcen wie Dateien oder Kennungen von Drittanbietern. Es ist beängstigend, sich vorzustellen, was passieren wird, wenn Sie nur eine Änderung vornehmen, die die Daten verdirbt, löscht oder falsche Daten auf eine Weise hinzufügt, die für einige Zeit unbemerkt bleiben kann.

Infrastrukturdienste

In Kapitel 6 haben wir die Magie der Infrastrukturverwaltungsdienste vorgestellt. Leider können sich diese Systeme als ebenso zerstörerisch wie nützlich herausstellen, was zu weitreichenden Konsequenzen im Zusammenhang mit der Bearbeitung einer Datei, dem Hinweis auf eine andere Umgebung oder falschen Konfigurationseinstellungen führen kann.

Betriebssystemfehler und Hardwarefehler

Die Betriebssysteme und Geräte, mit denen sie interagieren, sind ebenfalls von Personen erstellte Systeme. Daher können in ihnen Fehler auftreten, die aufgrund nicht dokumentierter oder wenig bekannter Konfigurationen unerwartete Folgen haben können. Im Zusammenhang mit der Datenwiederherstellung gilt dies insbesondere für die Art und Weise, wie Daten aus der Datenbank über Betriebssystem-Caches an Dateisysteme, Controller und schließlich an Festplatten übertragen werden. Datenschäden oder Datenverlust treten viel häufiger auf als wir denken. Leider führt unser Vertrauen in diese Mechanismen und unser Vertrauen in diese Mechanismen zu der Erwartung von Datenintegrität anstelle von Skepsis.



Netflix 2008 . (ECC). ECC . , ECC- , , . , 46 512- 92 . , , , « » S.M.A.R.T. 92 . . , ?

. , , . , . — .

, ZFS, , . RAID-, , .

Hardwarefehler

Hardware-Komponenten fallen im Prinzip aus, und in verteilten Systemen geschieht dies regelmäßig. Sie stoßen ständig auf Festplatten-, Speicher-, Prozessor-, Controller- und Netzwerkgerätefehler. Die Folgen dieser Hardwarefehler können der Ausfall von Knoten oder Verzögerungen auf Knoten sein, wodurch das System unbrauchbar wird. Freigegebene Systeme, wie z. B. Netzwerkgeräte, können ganze Cluster beeinflussen, sie unzugänglich machen oder sie in kleinere Cluster aufteilen, die nicht wissen, dass das Netzwerk aufgeteilt wurde. Dies kann zu schnellen und erheblichen Abweichungen in den Daten führen, die kombiniert und korrigiert werden müssen.

Rechenzentrumsfehler

Manchmal führen Hardwareprobleme auf Netzwerkebene zu Abstürzen im Rechenzentrum. Es kommt vor, dass das Überladen der Speicher-Backplanes zu Kaskadenfehlern führt, wie dies 2012 bei Amazon-Webdiensten der Fall war ( http://bit.ly/2zxSpzR ). Manchmal führen Hurrikane, Erdbeben und andere Katastrophen zum Ausfall ganzer Rechenzentren. Die anschließende Wiederherstellung testet selbst die zuverlässigsten Wiederherstellungsstrategien auf Stärke.

Skriptumfang


Nachdem wir die geplanten und ungeplanten Szenarien aufgelistet haben, die möglicherweise wiederhergestellt werden müssen, fügen wir diesen Ereignissen eine weitere Dimension hinzu, damit unsere Präsentation umfangreich wird. Dies ist nützlich, um die am besten geeignete Antwortmethode auszuwählen. Betrachten Sie die folgenden Optionen:

  • Fehler innerhalb eines einzelnen Knotens lokalisiert;
  • Ausfall des gesamten Clusters;
  • Ein Fehler, der das gesamte Rechenzentrum oder mehrere Cluster betrifft.

Im Falle eines lokalen oder Single-Site-Fehlers ist die Wiederherstellung auf einen Host beschränkt. Sie können dem Cluster einen neuen Knoten hinzufügen, um die Kapazität zu erhöhen oder einen ausgefallenen Knoten zu ersetzen. Oder das System implementiert eine kontinuierliche Aktualisierung, und dann wird die Wiederherstellung Knoten für Knoten durchgeführt. In jedem Fall handelt es sich um eine lokale Wiederherstellung.

Auf Clusterebene ist der Wiederherstellungsbedarf für alle Mitglieder dieses Clusters global. Möglicherweise gab es eine destruktive Änderung oder Löschung von Daten, die auf alle Knoten übertragen wurden. Oder Sie müssen einen neuen Cluster einführen, um die Kapazität zu testen.

Wenn auf der Skala des Rechenzentrums oder mehrerer Cluster ein Fehler aufgetreten ist, müssen alle Daten an ihrem physischen Standort oder im gesamten Fehlerbereich wiederhergestellt werden. Dies kann auf einen Ausfall des gemeinsam genutzten Data Warehouse oder auf einen Ausfall zurückzuführen sein, der einen katastrophalen Ausfall des Rechenzentrums verursacht hat. Eine solche Wiederherstellung kann auch während der geplanten Bereitstellung eines neuen sekundären Standorts erforderlich sein.

Zusätzlich zum Bereich gibt es einen Datensatzbereich. Hier können Sie drei mögliche Optionen auflisten:

  • ein Objekt;
  • mehrere Objekte;
  • Datenbank-Metadaten.

Auf der Skala eines Objekts erfordert nur dieses bestimmte Objekt eine Datenwiederherstellung - einige oder alle. Der zuvor diskutierte Fall, aufgrund dessen bei der Ausführung der DELETE-Operation mehr Daten gelöscht wurden als geplant, bezieht sich auf einen Fehler innerhalb desselben Objekts. Wenn mehrere Objekte ausfallen, sind mehrere oder möglicherweise alle Objekte in einer bestimmten Datenbank betroffen. Dies kann passieren, wenn die Anwendung beschädigt ist, das Update oder die Segmentmigration fehlschlägt. Schließlich kommt es zu Abstürzen auf der Skala der Datenbankmetadaten, wenn alles in Ordnung mit den in der Datenbank gespeicherten Daten ist, aber Metadaten verloren gehen, die sie verwendbar machen, z. B. Benutzerdaten, Sicherheitsberechtigungen oder Einhaltung von Betriebssystemdateien.

Skript Konsequenzen


Es ist wichtig, nicht nur das Szenario zu identifizieren, das wiederhergestellt werden muss, und den Fehlerbereich zu identifizieren, sondern auch die möglichen Konsequenzen zu ermitteln, da diese bei der Auswahl eines Wiederherstellungsansatzes von Bedeutung sind. Wenn sich der Datenverlust nicht auf SLO auswirkt, können Sie einen methodischen und langsamen Ansatz wählen, der die Ausweitung der Folgen minimiert. Die globaleren Änderungen, die zur Störung von SLO führen, sollten mit Vorsicht angegangen werden. Wählen Sie eine schnelle Wiederherstellung des Dienstes und fahren Sie erst dann mit einer langfristigen Bereinigung fort. Alle Ansätze können in die folgenden drei Kategorien unterteilt werden.

  • Auswirkungen auf SLO, Anwendungsfehler, betrafen die meisten Benutzer.
  • Bedrohungs-SLO haben einige Benutzer gelitten.
  • Funktionen, die SLO nicht bedrohen, sind betroffen.

Über die Autoren


Campbell Lane (Laine Campbell) ist Senior Manager (Senior Director) der Designfirma Fastly. Sie war außerdem Gründerin und CEO von PalominoDB / Blackbird, einem Beratungsdienst, der Datenbanken einer Reihe von Unternehmen bedient, darunter Obama für Amerika, Activision Call of Duty, Adobe Echosign, Technorati, Livejournal und Zendesk. Sie verfügt über 18 Jahre Erfahrung im Betrieb von Datenbanken und skalierbaren verteilten Systemen.

Cherity Majors(Charity Majors) ist der CEO und Mitbegründer von Honeycomb.io. Honeycomb kombiniert die Genauigkeit von Protokollaggregatoren, Zeitreihen-Geschwindigkeitsmetriken und die Flexibilität von Application Performance Metrics (APMs) und ist der weltweit erste Analysedienst der neuen Generation. Cheriti war zuvor ein Parse / Facebook-Betriebsspezialist, der eine riesige Flotte von MongoDB-Replikatsätzen sowie Redis, Cassandra und MySQL verwaltete. Sie arbeitete auch eng mit dem RocksDB-Team auf Facebook zusammen und beteiligte sich an der Entwicklung und Bereitstellung der weltweit ersten Mongo + Rocks-Installation mithilfe der Speicher-Plug-In-API.

»Weitere Informationen zum Buch finden Sie auf der Website des Herausgebers.
» Inhalt
» Auszug

Für Khabrozhiteley 25% Rabatt auf Gutschein - Datenbanken

Nach Zahlung der Papierversion des Buches wird ein elektronisches Buch per E-Mail verschickt.

More articles:


All Articles