Automatisierung von Sicherungen einer großen Anzahl von Datenbanken

In einer Webanwendung mit mehreren Mandanten, in der für jeden Mandanten eine Datenbank eingerichtet wird, kann die Datenbank auf herkömmliche Weise manuell gesichert und wiederhergestellt werden.

Ich erwäge diese Art von Architektur für eine Anwendung, die 5.000 bis 10.000 Mandanten haben könnte, und das Ausführen dieser Art von Prozess für diese vielen Mandantendatenbanken wird umständlich sein.

Wenn ich einen solchen Prozess für eine große Anzahl von Mandantendatenbanken implementieren würde:

• Gibt es wahrscheinlich einen übermäßigen Leistungsaufwand für eine so große Anzahl unterschiedlicher Backups?

• Wie würde eine so große Anzahl von Sicherungsprozessen automatisiert?

• Wie kann man eine so große Anzahl von Sicherungen verfolgen und sicherstellen, dass die Wiederherstellungsvorgänge die richtige Sicherung und Datenbank für die Wiederherstellung erhalten?

• Wie könnte man Kontrollen implementieren, um den Sicherungsstatus und die Integrität einer so großen Anzahl von Datenbanken zu überwachen?

Wenn die Sicherungen in diesen 5-10K-Datenbanken seriell ausgeführt werden, sollte es keinen wesentlichen Leistungsunterschied geben, als wenn Sie eine Sicherung in einer riesigen Datenbank ausführen würden. Sie könnten mit der gleichzeitigen Ausführung einiger Sicherungen auskommen , wenn Ihre Datenbanken nicht groß sind und Sie über eine gute E / A-Kapazität verfügen, aber darauf würde ich nicht zählen.

Sie sollten sich von Jobs vom Typ "Wartungsplan" fernhalten, da Sie mehr Kontrolle darüber benötigen, was passiert, und diese Jobs nicht die Art von Protokollen erstellen, die Sie möchten. Außerdem gibt es bei Plänen seltsame Fehlermöglichkeiten, die insbesondere bei älteren SQL Server-Versionen nicht immer bemerkt werden. Das Schreiben einer Prozedur zum Sichern aller Datenbanken auf einem Server ist ziemlich einfach. Bei diesem Verfahren sollte eine Protokolltabelle geführt werden, in der beschrieben wird, welche Datenbank gesichert wurde, wann sie gesichert wurde und in welche Datei sie verschoben wurde. Dateinamen sollten wahrscheinlich einen Zeitstempel enthalten, damit die richtigen Dateien leicht gefunden werden können. Ich würde sicherstellen, dass es eine Möglichkeit gibt, all diese Sicherungsdateien in verschiedene Ordner und Dateisysteme zu "zerlegen". Legen Sie sie nicht einfach in einem Ordner ab. Sie benötigen eine automatisierte Methode, um "alte" Sicherungen zu archivieren oder zu löschen. Es wäre gut, wenn dies auch in diese Protokolltabelle eingehen und eine bestimmte Sicherungsdatei als "verfügbar", "archiviert", "gelöscht" usw. kennzeichnen würde. Und natürlich benötigen Sie genügend Speicher, um so viele Sicherungen jeder Datenbank zu speichern wie Sie bereit sind zu halten.

Automatisierte Wiederherstellung ist Tricker. Zum einen, weil Sie die falsche Datenbank schnell löschen können, zum anderen, weil Sie eine Möglichkeit benötigen, Datenbankbenutzer auszuschalten, um die Wiederherstellung zu starten.

Backups können über RESTORE HEADERONLY und RESTORE FILELISTONLY gelesen werden, um zu überprüfen, ob das wiederhergestellt werden soll, was Sie zu sein glauben. Ich würde versuchen, diese Informationen in den Namen der Datei zu integrieren, da es viel einfacher ist, einen Dateinamen anzuzeigen, als mit RESTORE-Befehlen herumzuspielen. Sie können ein paar Quickie-CLR-Befehle schreiben, um Verzeichnislisten zu erstellen. Ich bin kein C # -Genie, daher habe ich im Web einige Beispiele gefunden, als ich das tun musste. Wählen Sie einfach ein gutes Format für einen Dateinamen und bleiben Sie dabei. So etwas wie SERVERNAME-INSTANCENAME-DATABASENAME-FULL-2012.04.18-09.24.00.bak. Auf diese Weise ist leicht zu erkennen, woher das Backup stammt und wann es erstellt wurde. Stellen Sie sicher, dass Ihr Wiederherstellungsschema die Wiederherstellung einer Datenbank auf einem anderen Server und / oder unter einem anderen Datenbanknamen durchführen kann. Ein häufiges Problem bei der Wiederherstellung auf demselben Server unter einem anderen Datenbanknamen ist eine Kollision mit den Dateinamen. Sie müssen neue Dateien verwenden.

All dies setzt voraus, dass die Datenbanken im EINFACHEN Wiederherstellungsmodus ausgeführt werden. Wenn die Datenbanken nicht im EINFACHEN Modus ausgeführt werden, vervielfachen sich Ihre Probleme. Sie benötigen mehr Speicherplatz für Backups, da Sie sowohl die tlog-Backups als auch die vollständigen Backups benötigen. Das Ausführen von Transaktionsprotokollsicherungen kann ein echtes Problem sein, da ein einzelner Job zum Sichern aller Sicherungen möglicherweise nicht in einem akzeptablen Fenster ausgeführt wird. (Wenn Sie eine Wiederherstellung zu einem bestimmten Zeitpunkt auf 15 Minuten garantieren, hilft dies nicht, wenn die Ausführung des Jobs 30 Minuten dauert.) Wenn die tlog-Sequenz unterbrochen wird oder Sie die vollständige Sicherung irgendwie verlieren, müssen Sie in der Lage sein Sicherungen einer oder mehrerer Datenbanken zu erstellen, je nachdem, was schief gelaufen ist. Es wäre nützlich, Datenbanken auszuwählen und auf einer anderen Instanz wiederherzustellen, um sicherzustellen, dass alles funktioniert. DBAs sind nicht so gut wie ihre letzten Backups.

Der Wiederherstellungscode wird komplizierter, insbesondere wenn Sie die Idee haben, dass Mandanten ihre eigenen Wiederherstellungen durchführen können.

Zusätzlich zum Sichern dieser Datenbanken möchten Sie ähnliche Prozesse erstellen, um DBCC CHECKDB auszuführen und eine erneute Indizierung durchzuführen. Ich würde mir einen Teil des vorhandenen Codes ansehen, der in DBA-Blogs verfügbar ist. Möglicherweise finden Sie sogar etwas, das Sie in eine Sicherungsprozedur überarbeiten können.

Testen Sie zum Schluss alles, was von Ihrem Unternehmen abhängt. Weil es könnte. Stellen Sie sicher, dass Sie Situationen testen, in denen die Sicherung fehlschlägt (möglicherweise nicht genügend Speicherplatz für die Sicherungsdatei?) Oder dass Datenbanken offline oder auf eingeschränkten Zugriff eingestellt oder irgendwie beschädigt sind. Überwachen Sie beim Ausführen Ihrer Tests die Leistung des Systems, vorzugsweise wenn es bereits ausgelastet ist.

Bei meinem vorherigen Job habe ich genau das getan. Wir waren im Bereich von 500 Mietern, aber sobald Sie über 10 oder 20 sind, macht der Automatisierungsteil die tatsächliche Anzahl viel weniger wichtig.

Angenommen, Ihre Hardware kann 10.000 Datenbanken in ausreichender Zeit sichern, und alle 10.000 haben nicht genügend Aktivität, um Ihren Server mit oder ohne Sicherungen zu überfordern. Der nächste Schritt besteht darin, den Prozess im Allgemeinen zu automatisieren. Das Schöne an diesem Modell ist, dass es viel einfacher ist, die Hälfte davon auf einen zweiten Server zu verschieben und Ihre Anwendungen je nach Mandant auf die richtige Instanz zu richten, wenn 10.000 Datenbanken Ihren Server überfordern, als zu versuchen, sie zu rippen die Hälfte der Daten aus einer einzigen Datenbank. Haben Sie einige in FULL und einige in SIMPLE oder befinden sich alle im selben Wiederherstellungsmodell?

Wir hatten Prioritäten. Eine Tabelle für die Mandanteninformationen (in meiner Implementierung gab es viel mehr Spalten, aber dies sollten die Grundlagen sein):

CREATE TABLE dbo.TenantBackups
(
  TenantID      INT PRIMARY KEY,
  RecoveryModel VARCHAR(6),
  Priority      TINYINT
);

Und dann eine Verlaufstabelle (wieder mehr dazu im eigentlichen System, aber für die Zwecke der Frage):

CREATE TABLE dbo.TenantBackupHistory
(
  TenantID   INT,          -- FOREIGN KEY,
  BackupType TINYINT,      -- lookup for FULL, LOG, RESTORE_TEST
  StartTime  DATETIME,
  EndTime    DATETIME,
  Status     NVARCHAR(1000) -- almost always NULL but held true "exceptions"
);

Jetzt können die Jobs die Mandanten nach Priorität sortiert durchlaufen und Sicherungen durchführen. Wir hatten tatsächlich getrennte Jobs für Priorität 1 gegenüber Priorität 2-5.

Wir haben Mandanten der Priorität 1 jede Nacht getestet, indem wir ihre vollständigen Sicherungen auf einem Sicherungsserver wiederhergestellt haben. Wir haben außerdem jede Nacht 20 zufällige Datenbanken aus den anderen Prioritäten ausgewählt, um auch deren Wiederherstellungen zu testen. Natürlich wurden Warnungen usw. so konfiguriert, dass Fehler sofort bekannt wurden. Wenn die Ausnahme außerhalb unserer normalen Wiederholungs- / Fehlerbehandlung lag, enthielt die Spalte Status Informationen.

Wir haben SQL Sentry auch verwendet, um Jobs zu verketten , sodass wir uns nicht darum kümmern mussten, einen Puffer zu planen und vorherzusagen, wann die Sicherungsjobs abgeschlossen sein würden. Bei Datenbanken mit Priorität 1 haben wir nicht darauf gewartet, dass die Sicherungen insgesamt abgeschlossen sind. Wir hatten einen Hintergrund-Thread, der darauf wartete, dass jede einzelne vollständige Sicherung abgeschlossen war, und ihn dann sofort aus der Warteschlange holte und die Testprozesse zum Kopieren / Wiederherstellen startete. Für Mandanten der Priorität 1 haben wir die wiederhergestellte Kopie auch als Berichts-Offload verwendet. Für alle Berichte, die vor heute an Daten interessiert waren (was die meisten Berichte waren), konnten sie die Kopie ausführen, da sie heute nur noch fehlte.

Für Mandanten mit vollständiger Wiederherstellung (nicht alle Kunden benötigten einen bestimmten Zeitpunkt) könnten die Protokollsicherungsjobs leicht die Verlaufstabelle überprüfen, um festzustellen, ob bereits eine Sicherung jeglicher Art durchgeführt wurde. Aber natürlich wurde überall eine Fehlerbehandlungs- und Wiederholungslogik implementiert.

Ich weiß, dass dies sehr allgemeine Beschreibungen sind, aber ich hoffe, sie weisen Sie in die richtige Richtung. Lassen Sie mich wissen, ob ich weitere Details erläutern soll.