本番IIS WebSiteとSQL Serverデータベースを停止せずに更新する

Question

テストデータベースを使用するテストサーバーがあります。私たちはテストサーバー上のWebサイトをテストします。問題がなければ、Webサイトとデータベーススキーマをテストサーバーから運用サーバーに更新します。しかし、この方法は非常に苦痛で危険です。

まず、ユーザーをメンテナンスページにリダイレクトする必要があるため、しばらくウェブサイトが一時停止されています。

第2に、更新時に何か問題が発生した場合、私たちは古いバージョンのWebサイトに戻る必要があります。これは、Webサイトを長期間メンテナンスモードにすることができないためです。

私は、IIS WebサイトとSQL Serverデータベースをデータの損失やメンテナンスモードの更新なしで更新するための堅実なソリューションを探しています。これを行う方法はありますか？大規模なウェブサイトがデータを失うことなく一時停止する方法。

私たちはリリース候補のウェブサイトを使用していると考えています。このRCウェブサイトは一時的に使用する予定です。まず、RCサイトを更新し、RCと本番サイトの間のバインディングを入れ替えます。しかし今回はデータベースが問題になります。データベーススキーマを変更できるため、古いデータベースは新しいデータベースでは機能しません。したがって、temp dbを持つtempサイトを使用すると、データが失われます。また、一時サイトが古い本番データベースを使用している場合、更新されたWebサイトは古いデータベースと連動しません。だから、私はこの問題のための実用的で実用的なソリューションが必要です。

Answer 1

。これは具体的には、ではなく、HAについてのではなく、連続的な統合についてです。それらのどちらもあなたが必要とするものを提供することはありません、彼らははるかに複雑なパズルの一部です。

が発生したときに、スキーマの変更を透過的に/忘れるようにコード変更を書き込むことはできません。最高でも、v。Nとv。N + 1でスキーマをサポートする方法でコードを書くことができます。それ自体は大きな課題です。しかし、がv。Nからv。N + 1にを移行するときに、スキーマをサポートする方法でコードを書くことは不可能です。デプロイメントによって引き起こされるスキーマの変更は、スキーマ上で動作するコードにとっては不可分でなければなりません。スキーマの変更自体はアトミックすることはできませんので、アップグレードが2つの可能な手段を持っていることは、次のとおりです。

• は、スキーマの変更時にコードをオフラインにします。これはあなたが今やっていることであり、最も安全なアプローチです。もちろん、サービスの可用性の低下を意味し、既に経験したリスク（失敗したアップグレードのロールバック、長時間のアップグレードなど）を実行します。このアプローチの変種は、サービスをデータの読み取り専用コピーにリダイレクトし、ビジネスの詳細に応じて、サービス品質の低下をもたらします（ダウンタイム中に変更は不可能です）。

• スタンバイアップグレード。これは、サービスデータのスナップショットを取ることを意味します（さまざまなHAソリューションが、ログ配送などのスタンバイスナップショットをすぐに提供する可能性があります）。スナップショットをアップグレードしてから、実際のサービスデータで発生したすべてのトランザクションをアップグレードされたスナップショットに適用します。 とは、変更を新しくアップグレードされたスキーマに変換する必要があります。変更トラッキング、レプリケーション、カスタムソリューションなどの変更を検出、取得、適用する技術が必要なため、常に難しいです。アップグレードしたスキーマをメインサービスからの変更で最新にすると、サービスはアップグレードされたスキーマにリダイレクトされます。このリダイレクションは、それが聞こえるよりはるかに複雑です。 すべての変更が新しいアップグレードされたスキーマDBに適用されていることを確認しながら、古いスキーマをカットして新しい変更を受け入れないようにする瞬間を選択するには、それ自体が課題です。もう一つの課題は、アップグレード前およびアップグレード後のスキーマバージョンを理解するコードの競合を解決することです。私が言ったように、問題とエラーが起こりやすいので、両方を処理するコードを開発することは短期間でサービスをオフラインにしてコードを置き換えることです。もう1つの解決策は、アップグレード後のDBスキーマを処理し、アップグレード後のDBに接続されている実行コードを実行して、スタンバイ、アップグレード済みのサービスにライブ要求をリダイレクトするスタンバイサービスです。

さらに、より大規模な展開ソリューションの特定のサービスをアップグレードする必要があるときに、サービスのやりとりの厄介な問題には触れませんでした。これは、アップグレード後のサービスがピアサービスと一緒にプレイできるようにするために、service API protocol back compatibilityが大きな役割を果たしている場合です。

最終的に銀色の弾丸はありません。私は週をバージョンN + 1に展開し、アップグレード前DBからの変更を伴うアップグレード後のDBスキーマを連続して転写レプリケーションする単一マシンの大規模なDB展開を目撃しました。また、バージョンN + 1を段階的に導入している数千台のマシンの導入が、アップグレード後の機能に完全に到達するまで数日間のコードとデータの変更を可能にする複雑なダンスとして目撃されました。この問題は単なる普通ハードです。

Answer 2

高可用性ソリューション（HA）について説明します。 HAソリューションは高価であり、迅速に過度に使用することができます。あなたはあなたのアプリとDBサーバのための冗長性が必要です。つまり、dbクラスタを設定することです。これにより、変更を配備するのにかかる時間が長くなりますが、アプリケーションが常に利用可能であるというトレードオフがあります。

展開の主なものは、繰り返し可能なプロセスです。ですから、できるだけ多くのスクリプトや自動化をお勧めします。

Answer 3

これはアズールが幻想的なものです。 Azure Cloudプラットフォームは、ステージングサーバーとプロダクションサーバーを可能にします。 GitやTFSに変更をコミットしたら、それをステージングサーバやプロダクションサーバに自動的にプッシュするように設定することができます。手動で変更をプッシュするように設定することもできます。 Entity FrameworkのようなほとんどのORMライブラリには移行がサポートされています。

のように、このトピックにそこに多くの情報があります：これは、あなたが想像よりも複雑桁違いである Azure seamless upgrade when database schema changes Staging or Production Instance?