7

独自の (SQL Azure) データベースを使用して、運用環境とステージング環境の両方をデプロイしているとします。ステージングのスキーマが変更され、本番環境にデプロイする必要がある場合、本番データベースで (ダウンタイムなしで) データベースのアップグレードを実現する定義済みの方法はありますか?

たとえば、VIP ステージング <-> プロダクションを交換する場合 (同時に接続文字列の変更を何らかの方法で自動化する場合)、SQL Azure データベースのアップグレードを自動化するための最良のプロセスは何ですか。

私の考えでは、RoleEnvironmentChanging で環境の変更を見つけ (ただし、VIP スワップが RoleEnvironmentChanging を起動するかどうかはわかりません)、その時点で予定のデータベース (つまり、prod) に対して SQL スクリプトを実行しますが、スクリプトが確実に実行されるようにする必要があります。一度だけ実行すると、複数のインスタンスが遷移します。

4

2 に答える 2

5

したがって、独自の SQL Azure データベースを持つ運用展開と、独自の SQL Azure データベースを持つステージング展開があります。この状況では、両方のアプリケーションの接続文字列が 2 つの異なるデータベースを指しています。

あなたの最初の要件は、展開を交換するか、何かを行うときにデータベース スキーマをその場で変更することです。その設計には次の懸念があります。

  1. ロール内に「1 回だけ」アクションを実行するコードを記述した場合、これが 1 回だけ発生するという保証はありません。次のようないくつかのシナリオに応じて、複数回発生します

    1.1どのような状況でも、VMはシステムによって再イメージ化される必要があり、このコードは最後の再イメージ化中に行ったのとまったく同じことを行います

    1.2 何らかの外部キーの何らかのレジストリ メソッドによって、ロールの開始時または VM の開始時に発生しないように保護することができますが、発生しないことを完全に証明するメカニズムがあります。

  2. そのため、展開をスワップする準備ができたら、次のことができることをお勧めします。

    2.1 スクリプトを実行して、本番関連の SQL Azure スキーマに更新します (変更されていないため、アプリケーションのダウンロードには影響しませんが、データベース スキーマが更新されている間は、アプリケーションへの影響をよりよく知ることができます)。

    2.2 ステージング展開の構成を変更して、運用 SQL Azure を指すようにします (これにより、運用アプリケーションのダウンタイムはまったく発生しません)

    2.3 SWAP デプロイメント (これにもアプリケーションのダウンタイムはありません)

したがって、DB スキーマを手動で更新してからデプロイを SWAP した場合でも、DB がスキーマを更新するのにかかる時間以外に大きなダウンタイムはありません。

于 2012-05-15T14:23:50.523 に答える