it-swarm-eu.dev

Wie aktualisieren Sie Ihr Produktionscodebasis- / Datenbankschema, ohne Ausfallzeiten zu verursachen?

Welche Techniken gibt es, um eine Codebasis/ein Datenbankschema eines Produktionsservers zu aktualisieren, ohne Ausfallzeiten zu verursachen?

43
Olivier Lalonde

Im Allgemeinen befanden sich die Websites, an denen ich mit diesen Anforderungen gearbeitet habe, alle hinter Load-Balancern oder hatten separate Failover-Speicherorte. In diesem Beispiel gehe ich davon aus, dass Sie einen einzelnen Load Balancer, 2 Webserver (A & B) und 2 Datenbankserver (M & N - normalerweise sind DB-Server über Logshipping verbunden - zumindest in der SQL Server-Welt ).

  1. Webserver A muss vom Load Balancer getrennt werden (damit der gesamte eingehende Datenverkehr an B geht).
  2. Der Protokollversand wird gestoppt (DB Server M wird zuerst aktualisiert).
  3. Aktualisieren Sie den Webserver A. Zeigen Sie mit der Konfiguration auf DB Server M.
  4. Testen und überprüfen Sie, ob das Update funktioniert hat (normalerweise treffen die Leute die IP-Adresse direkt).
  5. Stellen Sie den Load Balancer so ein, dass vorhandene Sitzungen weiterhin zu B wechseln. Neue Sitzungen gehen zu A.
  6. Warten Sie, bis alle Sitzungen auf B abgelaufen sind (möglicherweise eine halbe Stunde oder länger, normalerweise beobachten wir den Verkehr und haben eine Pause von 1 Stunde geplant).
  7. Update B und N.
  8. Testen und überprüfen Sie, ob das Update funktioniert hat.
  9. Richten Sie den Protokollversand erneut ein und testen Sie, ob er funktioniert.
  10. Stellen Sie den Load Balancer auf den regulären Betrieb ein.

In sehr komplizierten Webanwendungen kann das, was als Schritte 1 bis 5 beschrieben wird, die ganze Nacht dauern und eine 50-seitige Excel-Tabelle mit Zeiten und Notfall-Kontaktnummern sein. In solchen Situationen ist die Aktualisierung der Hälfte des Systems für 18 bis 6 Uhr geplant, während das System den Benutzern zur Verfügung steht. Die Bearbeitung des Updates für die DR-Site ist normalerweise für die folgende Nacht geplant - hoffen Sie nur, dass am ersten Tag nichts kaputt geht.

Wenn Verfügbarkeit erforderlich ist, werden Patches zuerst in der QS-Umgebung getestet, die im Idealfall dieselbe Hardware wie die Produktion aufweist. Wenn sie keine Störung aufweisen, können sie nach dem regulären Zeitplan angewendet werden, der normalerweise am Wochenende stattfindet.

20
Tangurena

Bei typischen Datenbanken (z. B. Oracle) ist es möglich, das Datenbankschema zu ändern, während weiterhin Abfragen parallel ausgeführt werden. Es erfordert jedoch eine gewisse Vorausplanung.

Es gibt einige Einschränkungen für die anzuwendende Änderung:

  • es sollte mit dem vorhandenen Code funktionieren, was bedeutet, dass der Code sowohl die alte als auch die neue Version des Schemas behandeln sollte
  • die Datenbank sollte nicht so stark belastet werden, dass Transaktionen zum Stillstand kommen (ich sehe Sie an CREATE INDEX)
  • es sollte keinen Datenverlust verursachen (Sie können keine Tabelle löschen und neu erstellen).

Damit das Schema abwärtskompatibel ist, können Sie normalerweise eine Spalte HINZUFÜGEN oder ÄNDERN. Sie können nur dann DROPEN, wenn der vorhandene Code es nicht mehr verwendet.

Wenn Ihr Code die Änderung nicht transparent verarbeiten kann, ändern Sie den Code, bevor Sie die Datenbank ändern.

Einfache Hinweise zur Vorausplanung: Geben Sie in Ihren DB-Anforderungen immer die Spaltennamen an (verwenden Sie nicht SELECT * FROM). Auf diese Weise werden in alten Anforderungen keine neuen Spalten angezeigt.

9
Matthieu M.

Nicht alle Systeme können, es muss so eingerichtet werden, dass es dies unterstützt.

Zum Beispiel sollte eines unserer wichtigsten Systeme, an deren Aktualisierung ich vor einigen Jahren mitgewirkt habe, rund um die Uhr verfügbar sein. Es bestand aus mehreren Ebenen, einschließlich einer reinen Kommunikationsebene zwischen der externen Benutzeroberflächenschicht und der Geschäftsschicht. Aufgrund der Art und Weise, wie die Kommunikationsschicht codiert wurde, konnten zukünftige Änderungen an der Geschäftsschicht oder dem DB-Schema ohne einen echten Ausfall implementiert werden. Im schlimmsten Fall würde ein Benutzer eine Pause von 10 bis 30 Sekunden einlegen, wenn die Änderungen wirksam werden.

Wenn es sich bei den Änderungen lediglich um Codeänderungen an der Geschäftsschicht handelt, können sie mit einer Verzögerung von nur Millisekunden in die Warteschlange gestellt und "eingeschaltet" werden.

Es könnte dies tun, weil:

  • Die Kommunikationsschicht könnte Nachrichten enthalten. Dies ermöglichte uns einen tatsächlichen Ausfall auf einer anderen Ebene als der UI-Ebene, ohne dass die UI heruntergefahren werden musste.
  • Die von der MVDB verwaltete Business-Schicht mit dem Namen niData . Dies hält den gesamten Code im Speicher. Nach dem Kompilieren des Codes können Sie mit einem Befehl den neuen Objektcode in den Speicher zwingen und den alten ersetzen.

Andere Techniken umfassen die Replikation von Transaktionen auf einen anderen Spiegel des vorhandenen Systems. Durch Anwenden des Updates auf eins können alle zwischen Update und Switch durchgeführten Transaktionen umgeschaltet und wiedergegeben werden. YMMV hängt jedoch von Ihren Systemen ab.

5
Dan McGrath

Hier ist eine andere Perspektive als in der Welt der eingebetteten Datenbanksysteme und eingebetteten Systeme. Eingebettete Systeme umfassen verschiedene Netzwerk-/Telekommunikationsinfrastrukturgeräte, und in diesem Bereich sprechen sie häufig von einer Verfügbarkeit von 99,999% (fünf Neuner).

Wir (McObject) sind der Anbieter der eXtremeDB-Familie eingebetteter Datenbanksystemprodukte, einschließlich eXtremeDB High Availability.

Verstehen Sie zunächst, dass "eingebettete Datenbank" bedeutet, dass das Datenbanksystem eine Bibliothek ist, die kompiliert und mit Ihrem Anwendungscode verknüpft ist. In diesem Sinne ist es in Ihre Anwendung "eingebettet".

Bei eXtremeDB High Availability gibt es eine MASTER-Instanz Ihrer Anwendung (bei der es sich möglicherweise um einen oder mehrere Prozesse handelt) und eine oder mehrere REPLICA-Instanzen Ihrer Anwendung. Wenn ein Replikat eine Verbindung zum Master herstellt, empfängt es eine Kopie der Datenbank des Masters über einen Prozess, der als "Erstsynchronisation" bezeichnet wird. Dies kann erfolgen, während die Master-Anwendung ihre Arbeit fortsetzt. Nach der Synchronisierung werden die Transaktionen des Masters durch Replikation empfangen. Daher verfügt ein Replikat immer über aktuelle Daten und kann (durch einen als Failover bezeichneten Prozess) die Funktion übernehmen, falls der Master ausfällt.

Ein Merkmal der anfänglichen Synchronisation heißt "binäre Schemaentwicklung". Im Klartext bedeutet dies, dass beim Auffüllen der Datenbank des Replikats Unterschiede zwischen dem Datenbankschema des Replikats und dem Datenbankschema des Masters berücksichtigt werden.

In der Praxis bedeutet dies, dass Sie eine neuere Version Ihrer Anwendung erstellen können (mit neuen/gelöschten Tabellen, neuen/gelöschten/geänderten Feldern, neuen/gelöschten Indizes), diese neue Version Ihrer Anwendung an einen Master anhängen und diese dann verursachen können neueres Replikat, um der neue Master zu werden (dh ein Failover auf das neue Replikat erzwingen, damit es zum Master wird und der alte Master sich selbst herunterfährt). Voila, Sie haben Ihre Anwendung von Version N auf N + 1 migriert, ohne die Verfügbarkeit Ihres Systems zu unterbrechen. Jetzt können Sie den alten Master und alle anderen Replikate auf Version N + 1 aktualisieren.

1
user22538