Es gibt einen Testserver, der die Testdatenbank verwendet. Wir testen die Website auf dem Testserver. Wenn es in Ordnung ist, aktualisieren wir die Website und das Datenbankschema vom Testserver auf den Produktionsserver. Aber diese Methode ist sehr schmerzhaft und riskant.
Zuerst müssen wir die Benutzer auf eine Wartungsseite umleiten, sodass die Website für eine Weile angehalten wird.
Zweitens: Wenn bei der Aktualisierung etwas schief geht, müssen wir auf die alte Website zurückkehren, da wir die Website nicht lange in einen Wartungsmodus versetzen können.
Ich suche also nach einer soliden Lösung, um eine IIS-Website und eine SQL Server-Datenbank ohne Datenverlust zu aktualisieren und den Wartungsmodus zu verwenden. Gibt es eine Möglichkeit, dies zu tun? Wie die großen Websites das ohne Datenverlust und -pause machen.
Wir haben uns gedacht, eine Veröffentlichungskandidaten-Website zu verwenden. Wir haben vor, diese RC-Website vorübergehend zu nutzen. Zuerst aktualisieren wir die RC-Site und tauschen dann die Bindungen zwischen RC und der Produktionswebsite aus. Aber diesmal ist die Datenbank ein Problem. Weil wir das Datenbankschema ändern können und das alte nicht mit der neuen Datenbank arbeiten kann. Also, wenn wir eine temporäre Site mit temp db verwenden, kommt es zu Datenverlust. Außerdem funktioniert die aktualisierte Website nicht mit der alten Datenbank, wenn die temporäre Website eine alte Produktionsdatenbank verwendet. Also brauche ich eine solide und praktische Lösung für dieses Problem.
Das ist um Größenordnungen komplizierter als Sie sich vorstellen. Dies ist insbesondere nicht über HA oder über zusammenhängende Integration. Keiner von denen wird dir bieten, was du brauchst, sie sind nur Teile des viel komplexeren Puzzles.
Es ist einfach nicht möglich, Codeänderungen in einer Weise zu schreiben, die für Schemaänderungen transparent / unwichtig ist, wenn sie auftreten . Im besten Fall können Sie den Code in einer Weise schreiben, die das Schema bei v. N und bei v. N + 1 unterstützt, was an sich schon eine große Herausforderung darstellt. Es ist jedoch unmöglich, den Code in einer Weise zu schreiben, die das Schema unterstützt, wenn es von v.N zu v.N + 1 übergeht. Die Schemaänderung, die durch eine Bereitstellung ausgelöst wird, muss für den Code, der auf dem Schema ausgeführt wird, atomar sein. Da die Schemaänderung selbst nicht atomar sein kann, folgt daraus, dass das Upgrade zwei mögliche Wege hat:
Nimm den Code während der Schemaänderung offline. Das machen Sie jetzt und ist der sicherste Ansatz. Natürlich impliziert es Ausfallzeiten für die Verfügbarkeit von Diensten und führt die Risiken aus, die Sie bereits erlebt haben (Rollback eines fehlgeschlagenen Upgrades, langwieriges Upgrade usw.). Eine Variante dieses Ansatzes besteht darin, den Dienst auf eine schreibgeschützte Kopie der Daten umzuleiten und eine verschlechterte Serviceerfahrung anzubieten (während der Ausfallzeit sind keine Änderungen möglich), die abhängig von den Geschäftsspezifikationen akzeptabel oder nicht akzeptabel ist. p>
Standby-Upgrade. Dies bedeutet, dass Sie einen Snapshot der Servicedaten erstellen (verschiedene HA-Lösungen können standardmäßig einen Standby-Snapshot bereitstellen, z. B. Protokollversand). Aktualisieren Sie den Snapshot und wenden Sie dann alle Transaktionen, die in den echten Servicedaten aufgetreten sind, auf den aktualisierten Snapshot an. Dies ist immer schwierig, da es eine Technologie erfordert, um die Änderungen zu erkennen, zu erfassen und anzuwenden (z. B. Änderungsverfolgung, Replikation, benutzerdefinierte Lösung usw.) und erfordert, jede Änderung in das neue, aktualisierte Schema zu transformieren . Sobald das aktualisierte Schema mit Änderungen vom Hauptdienst aktualisiert wurde, kann der Dienst zum aktualisierten Schema umgeleitet werden. Diese Umleitung ist auch viel komplexer als es klingt. Wenn man den Zeitpunkt wählt, an dem das alte Schema abgeschnitten wird und keine neuen Änderungen mehr akzeptiert, während sichergestellt wird, dass alle Änderungen auf die neue aktualisierte Schema-DB angewendet werden, ist dies eine Herausforderung für sich. Eine weitere Herausforderung besteht darin, den Konflikt der Code-Verständnis-Vor-Upgrade- und Nach-Upgrade-Schema-Versionen zu lösen. Das Entwickeln von Code, der beides verarbeitet, ist, wie gesagt, problematisch und fehleranfällig. Eine Lösung besteht darin, den Dienst für kurze Zeit wieder offline zu schalten und den Code zu ersetzen. Eine andere Lösung besteht darin, einen Bereitschaftsdienst zu verwenden , der das Datenbankschema nach dem Upgrade ausführt und mit der Post-Upgrade-Datenbank verbunden ist und die Live-Anforderungen an Ihren Standby-, Upgrade- und Service-Dienst umleitet / p>
Und ich habe nicht einmal das heikle Thema der Service-Interaktion berührt, wenn ein bestimmter Service einer viel größeren implementierten Lösung aufgerüstet werden muss. Dies ist, wenn Service-API-Protokoll-Kompatibilität spielt die Hauptrolle zu ermöglichen der Post-Upgrade-Dienst, um mit seinen Peer-Diensten zu spielen.
Letztendlich gibt es einfach keine Silberkugel. Ich habe große DB-Bereitstellungen für einzelne Computer gesehen, die Wochen zum Ausrollen der Version N + 1 benötigten, wobei die Transkriptionsreplikation das DB-Schema nach dem Upgrade mit Änderungen aus der DB vor dem Upgrade zusammenhängend fütterte. Und ich war Zeuge von Bereitstellungen von Tausenden von Maschinen, die die Version N + 1 in Etappen implementierten, als ein komplizierter Prozess, der Code- und Datenänderungen über mehrere Tage ermöglichte, um die volle Funktionalität des Post-Upgrades zu erreichen. Dieses Problem ist einfach schwer .
Dafür ist Azure fantastisch. Die Azure Cloud-Plattform ermöglicht das Bereitstellen von Servern und Produktionsservern. Sie können es einrichten, sobald Sie Ihre Änderungen an Git oder TFS festgeschrieben haben, wird es automatisch an einen Staging- oder Produktionsserver gesendet. Sie können auch festlegen, dass Änderungen manuell vorgenommen werden. Die meisten ORM-Bibliotheken wie Entity Framework haben Migrationsunterstützung.
Es gibt viele weitere Informationen zu diesem Thema wie: Azure nahtlose Aktualisierung, wenn sich das Datenbankschema ändert Staging- oder Produktionsinstanz?
Sie beschreiben eine Hochverfügbarkeitslösung (HA). HA-Lösungen sind teuer und können schnell übertrieben werden. Sie würden Redundanz für Ihre App und Db-Server benötigen, was bedeutet, dass Sie einen db-Cluster einrichten müssen. All dies erhöht die Zeit, die Sie für die Bereitstellung von Änderungen aufwenden würden. Der Nachteil ist jedoch, dass Ihre App immer verfügbar ist.
Das Wichtigste bei der Bereitstellung ist ein wiederholbarer Prozess. Also meine beste Empfehlung ist es, so viel wie möglich zu schreiben oder zu automatisieren.
Tags und Links sql-server iis web-deployment continuous-deployment updating