8

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

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

第二に、更新中に何か問題が発生した場合、Web サイトを長期間メンテナンス モードにすることはできないため、古い Web サイトに戻らなければなりません。

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

リリース候補の Web サイトを使用することを考えました。この RC Web サイトを一時的に使用する予定です。まず、RC サイトを更新してから、RC と実稼働 Web サイトの間のバインディングを交換します。しかし、今回はデータベースが問題です。データベース スキーマを変更できるため、古いスキーマは新しいデータベースでは機能しません。そのため、一時データベースで一時サイトを使用すると、データが失われます。また、一時サイトが古い運用データベースを使用している場合、更新された Web サイトは古いデータベースでは機能しません。したがって、この問題に対する確実で実用的な解決策が必要です。

4

3 に答える 3

7

これは想像以上に複雑です。これは具体的にはHA に関するものでも、連続統合に関するものでもありません。どちらも必要なものを提供するものではなく、はるかに複雑なパズルのピースにすぎません。

スキーマの変更が発生したときに透過的/認識しない方法でコードの変更を記述することは、まったく不可能です。せいぜい、v. N および v. N+1 のスキーマをサポートする方法でコードを記述できますが、それ自体が大きな課題です。しかし、v. N から v. N+1に移行するスキーマをサポートする方法でコードを記述することは不可能です。展開によって引き起こされるスキーマの変更は、スキーマで動作するコードに対してアトミックである必要があります。スキーマの変更自体はアトミックにはできないため、アップグレードには次の 2 つの方法があります。

  • スキーマの変更中にコードをオフラインにします。これはあなたが現在行っていることであり、最も安全なアプローチです。もちろん、これはサービスの可用性のダウンタイムを意味し、すでに経験したリスク (失敗したアップグレードのロールバック、長時間のアップグレードなど) を実行します。このアプローチの変形として、サービスをデータの読み取り専用コピーにリダイレクトし、低下したサービス エクスペリエンス (ダウンタイム中は変更できません) を提供します。これは、ビジネスの詳細に応じて、許容される場合と許容されない場合があります。

  • スタンバイのアップグレード。これは、サービス データのスナップショットを作成することを意味します (ログ配布など、さまざまな HA ソリューションがすぐに使用できるスタンバイ スナップショットを提供する場合があります)。スナップショットをアップグレードし、実際のサービス データで発生したすべてのトランザクションをアップグレードされたスナップショットに適用します。変更を検出、キャプチャ、および適用する技術 (変更追跡、レプリケーション、カスタム ソリューションなど) が必要であり、各変更を新しいアップグレードされたスキーマに変換する必要があるため、これは常に注意が必要です。アップグレードされたスキーマがメイン サービスからの変更で最新の状態になると、サービスをアップグレードされたスキーマにリダイレクトできます。このリダイレクトも、見た目よりもはるかに複雑です。古いスキーマを切り離し、新しい変更の受け入れを停止する瞬間を選択する人にとっては、すべてのことを確認しながらアップグレードされた新しいスキーマ DB に変更を適用すること自体が課題です。もう 1 つの課題は、アップグレード前とアップグレード後のスキーマ バージョンを理解するコードの競合を解決することです。前述のように、両方を処理するコードを開発することは問題があり、エラーが発生しやすいため、1 つの解決策は、サービスを短期間オフラインにしてコードを置き換えることです。もう 1 つの解決策は、アップグレード後の DB スキーマを処理し、アップグレード後の DB に接続されているコードを実行するスタンバイサービスを用意し、ライブ リクエストをアップグレードされたスタンバイ サービスにリダイレクトすることです。

また、デプロイされたはるかに大規模なソリューションの特定のサービスをアップグレードする必要がある場合の、サービスのやり取りという厄介な問題には触れませんでした。これは、サービス API プロトコルの後方互換性が主要な役割を果たし、アップグレード後のサービスがそのピア サービスと連携できるようにする場合です。

最終的に特効薬はありません。バージョン N+1 を展開するのに数週間かかった単一マシンの大規模な DB 展開を目撃しました。転写レプリケーションは、アップグレード前の DB からの変更をアップグレード後の DB スキーマに連続的に供給します。また、バージョン N+1 を段階的に展開する数千台のマシンの展開を目の当たりにしました。これは、アップグレード後の完全な機能に到達するために、数日間にわたってコードとデータの変更を可能にするという複雑なダンスでした。この問題は単純に難しいです。

于 2012-08-09T11:15:13.287 に答える
0

これが Azure の優れた点です。Azure クラウド プラットフォームでは、ステージング サーバーと運用サーバーを使用できます。変更を Git または TFS にコミットすると、ステージング サーバーまたは運用サーバーに自動的にプッシュされるように設定できます。変更を手動でプッシュするように設定することもできます。Entity Framework などの ORM ライブラリのほとんどは、移行をサポートしています。

このトピックについては、次のような多くの情報があります: データベース スキーマが変更された場合の Azure のシームレスなアップグレード ステージングまたは運用インスタンス?

于 2012-07-30T01:11:56.640 に答える
-1

高可用性ソリューション (HA) について説明しています。HA ソリューションは高価であり、すぐにやり過ぎになる可能性があります。アプリ サーバーと db サーバーの冗長性が必要になります。つまり、db クラスターをセットアップします。これらすべてにより、変更のデプロイに費やす時間が増加しますが、トレードオフは、アプリが常に利用可能であることです。

展開で重要なことは、繰り返し可能なプロセスを持つことです。したがって、私の最善の推奨事項は、可能な限りスクリプト化または自動化することです。

于 2012-07-30T01:03:18.873 に答える