Datenbankaktualisierung und Bereitstellung ohne Ausfallzeiten

    Es wurden viele Artikel über die sofortige Aktualisierung von Systemen geschrieben, ohne diese anzuhalten (Bereitstellung ohne Ausfallzeiten), und viele Aspekte dieses Ansatzes liegen auf der Hand. Meiner Meinung nach ist der schwierigste Teil der Bereitstellung in diesem Fall die Aktualisierung von Data Warehouses, wenn sich ihr Vertrag (Schema) geändert hat. Dies ist der Aspekt, den ich in diesem Artikel berücksichtigen möchte.

    Unabhängig von der Datenbank - mit einem expliziten Datenschema als relational oder willkürlich wie NoSQL - ist das Datenschema auch auf Anwendungsebene noch vorhanden. Die aus der Datenbank gelesenen Daten sollten für den Client eindeutig sein, auch wenn der Speicher selbst keine Einschränkungen für ihre Struktur enthält.

    Angenommen, ein System mit einer bestimmten Datenstruktur und Terabyte Daten in der Datenbank wird bereits in der Produktion ausgeführt. In der neuen Version des Systems müssen wir die Struktur geringfügig ändern, um neue Funktionen zu implementieren oder die Leistung zu verbessern. Überlegen Sie, welche Änderungen im Schema auftreten können:

    • Ein neues Feld hinzufügen
    • Ein Feld löschen
    • Feld umbenennen
    • Änderungen des Feldtyps
    • Feldübertragung in eine andere Datenstruktur (zB bei Denormalisierung)

    Das Hinzufügen eines neuen Felds sowie eines anderen Datenbankobjekts ist eine abwärtskompatible Änderung und erfordert keine zusätzlichen Schritte zur Implementierung einer Bereitstellung ohne Ausfallzeit (mit einer Maßgabe - wenn dieses neue Feld oder Objekt nicht funktional von den anderen in der Datenbank gespeicherten Feldern abhängt Daten). Es reicht aus, die Änderungen in der Datenbank „on the fly“ anzuwenden. Anschließend wird die neue Version des Codes angewendet, der die neuen Datenbankobjekte verwendet.

    Das Löschen eines Felds oder eines anderen Datenbankobjekts ist keine abwärtskompatible Änderung. Die Implementierung ist jedoch sehr einfach. Unnötige Datenbankobjekte sollten erst entfernt werden, nachdem die neue Version des Systems vollständig installiert wurde.

    Die verbleibenden drei Arten von Änderungen sind komplexer, da keine Ausfallzeiten erforderlich sind. Im Allgemeinen können Sie alle Aufgaben ausführen, indem Sie Daten in andere Felder / Entitäten kopieren und die "alten" Daten nach erfolgreichem Abschluss der Datenmigration löschen. Zum Umbenennen können Sie Daten aus dem alten Feld in das Feld mit dem neuen Namen kopieren und dann das alte Feld löschen und den Datentyp ändern kann zusammen mit dem Umbenennen usw. gemacht werden Auf jeden Fall sollte die Datenbank für einige Zeit sowohl den alten als auch den neuen Vertrag unterstützen. Es gibt mindestens zwei Möglichkeiten, diese Änderungen im laufenden Betrieb vorzunehmen:

    Wenn die Datenbank Trigger unterstützt


    1. Erstellen Sie Trigger, die bei jeder Änderung / Hinzufügung Daten vom alten zum neuen Speicherort kopieren und in der Produktion aktivieren.
    2. Wenden Sie ein Datenkonvertierungsdienstprogramm an, das dasselbe für alle Datensätze in der Datenbank ausführt. Da die Trigger bereits installiert sind, kann das Dienstprogramm nichts Komplizierteres tun als nur eine „fiktive“ Aktualisierung jedes Datensatzes (UPDATE-Tabelle SET field = field ...). Ein sehr wichtiger Punkt hierbei ist, dass die Aktion des Lesens von Daten vom alten Ort und des Schreibens auf den neuen atomar sein und vor verlorenen Änderungen geschützt werden sollte. Abhängig von der Struktur der Datenbank können Sie entweder die pessimistische Sperre über SELECT FOR UPDATE oder seine Analoga verwenden oder optimistisch, wenn die Tabellen ein Feld mit der Datensatzversion enthalten.
    3. Nachdem das Dienstprogramm seine Arbeit beendet hat (abhängig von der Datenmenge und der Komplexität des Updates kann die Ausführungszeit in Tagen berechnet werden), können Sie eine neue Version des Systems installieren, die das neue Datenschema unterstützt. Zu diesem Zeitpunkt werden alle Datensätze in der Datenbank, die zum Zeitpunkt des Starts des Dienstprogramms vorhanden waren, erfolgreich konvertiert, und alle neuen Datensätze, die während des Betriebs aufgetreten sind, werden ebenfalls durch Trigger konvertiert.
    4. Löschen Sie Trigger und alle Felder (oder andere Datenbankobjekte), die nicht mehr benötigt werden.

    Wenn es nicht möglich ist, Trigger zu verwenden (wie es bei vielen NoSQL-Lösungen der Fall ist)




    1. Erstellen und schließen Sie eine neue Version der Anwendung (temporäre Version 1 in der Abbildung), die immer aus dem alten Feld liest. Beim Schreiben in dieses Feld werden jedoch sowohl die alte als auch die entsprechende neue Stelle aktualisiert (in der Abbildung "C" die alte, "H" - neu). Wenden Sie diese Version auf alle Knoten an, auf denen Anwendungsinstanzen ausgeführt werden.
    2. Wenden Sie ein Dienstprogramm an, mit dem Daten vom alten zum neuen Speicherort kopiert werden. Wie bei Triggern müssen Maßnahmen ergriffen werden, um Änderungen zu vermeiden.
    3. Erstellen Sie eine andere Version der Anwendung (temporäre Version 2), die Daten aus dem neuen Feld liest, aber weiterhin an zwei Stellen schreibt. Dieser Schritt ist erforderlich, da es während der sequentiellen Aktualisierung jedes Knotens immer noch eine Lücke gibt, wenn Instanzen einer früheren Version der Anwendung, die das alte Feld liest, gleichzeitig mit der neuen funktionieren.
    4. Erstellen Sie die endgültige Version, die bereits nicht mit dem alten Feld interagiert, und schließen Sie den vollständigen Scan des vorherigen ab.
    5. Alte Felder löschen.

    Der zweite Ansatz erfordert die Erstellung und Installation von drei verschiedenen Versionen der Anwendung, was sehr umständlich und umständlich sein kann. Stattdessen können Sie das Feature-Umschalten verwenden - die Logik aller drei Versionen in eine umwandeln, den Modus jedoch in Abhängigkeit von den Konfigurationsparametern ändern, die im Idealfall sofort umgeschaltet werden können. Anstatt also jede nachfolgende Version zu installieren, reicht es aus, den Wert des Parameters zu ändern (und den Dienst neu zu starten, wenn das Konfigurationsupdate nicht sofort bereitgestellt wird). Nach dem erfolgreichen Abschluss der Installation der endgültigen Version sollte der gesamte Code zur Gewährleistung der Datenmigration vollständig aus dem Arbeitszweig entfernt werden, auch wenn er bis zur nächsten Systemaktualisierung in Betrieb ist.

    Es ist leicht einzusehen, dass das Sicherstellen von Ausfallzeiten bei der Aktualisierung eines Systems ein umständliches und anfälliges Verfahren ist. Es ist daher sinnvoll, sich nur dann damit zu befassen, wenn eine entsprechende Anforderung des Unternehmens vorliegt. Aber selbst wenn die Anforderungen an die Systemverfügbarkeit recht niedrig sind (z. B. 99% pro Jahr und das Fenster für die geplante Systemaktualisierung 24 Stunden), kann die Konvertierung der für die Installation der neuen Version erforderlichen Daten noch länger dauern. Daher müssen Sie im Voraus auf die Verwendung solcher Lösungen vorbereitet sein, wenn Sie große Datenmengen speichern möchten.

    Ein alternativer Ansatz besteht darin, die rückwärtskompatiblen Änderungen im Datenbankschema absichtlich aufzugeben. In der Praxis ist dies jedoch leider nicht immer möglich, da die Umstrukturierung des Schemas häufig die effektivste Methode zur Verbesserung der Datenzugriffsleistung darstellt.

    Jetzt auch beliebt: