現在、ローカル Web サイト、ステージング Web サイト、および運用 Web サイトをセットアップしています。ステージング データベースを使用してローカルで開発し、変更が行われると、ステージングに移動されます。これは、構成に関しては、運用に一致するはずです。ステージングで機能する場合、ライブで機能することはほぼわかっているので、本番環境に移行します。
現在、ステージング データベースは、ユーザーが本番環境で行った変更により最新ではありません。
できれば達成したいことは、ステージング データベースを毎晩自動的に更新できるようにすることです。これにより、ステージングを最新の状態にすることができますが、本番環境の更新によってすぐに上書きされることなく、新しい変更をテストするために必要な変更をステージングに加えることができます。
それが役立つ場合は、Microsoft SQL Server。2008年だと信じてください。
要約すると、本番データベースをステージング データベースに毎晩自動的にミラーリングするにはどうすればよいでしょうか?
24 時間以内にスキーマの変更をステージングから本番環境に確実に移行できる場合。次に、実際にタスクを簡単に実行できます。本番データベースをバックアップし、ステージングで復元するだけです。
ログ配布とデータベース ミラーリングでは、読み取り専用のデータベースしか残せません。レプリケーションには読み取り専用の制限はありませんが、ステージング データベースのスキーマとデータを更新しているときに競合が発生すると失敗します。
あなたの製品データベースは約 25G 圧縮されています。毎日転送するには大きすぎると思います。増分変更がそれほど多くない場合、たとえば 1 日 500M 未満の zip 圧縮がある場合は、毎週の完全バックアップと毎日の差分バックアップ戦略を使用することをお勧めします。この方法では、本番環境で 2 つのバックアップ ジョブを設定し、ステージングで 1 つの復元ジョブを設定するだけで済みます。常に、今週の完全バックアップと新しい差分バックアップを復元するだけです。
ステージングデータベースを復元する前に、ステージングデータベースのすべての接続を強制終了する必要があることに注意してください。データベースを変更して、ユーザーモデルを単一化してください。
完全バックアップとログ バックアップの戦略も機能し、転送するデータは少なくて済みますが、復元ジョブの設定が少し複雑になります。
(免責事項 - 私は本質的に @SolidSnake4444 のセットアップと目標に精通しています)
@jmoreno は矛盾を正しく観察しています。
データベースのサイズが大きいことは、スケジュールされた完全な復元に依存するソリューションに不利に働くもう 1 つの要因です。
@JohnyWeil と @SteveStedman の提案を組み合わせたものが最善の解決策だと思います。次のようにします。 1. 2 つ目の「実際の」ステージング ローカル データベースを作成します。2. 現在の「ステージング」を「テスト」または「開発」と呼び始めます。3. 本番環境から新しいステージングへのログ配布をセットアップしますが、ログの適用を遅らせます。
注 3. は、「ステージング」または「展開前のテスト」ローカル アクティビティを許可するために、この「ステージング」データベースが操作可能でなければならないという暗黙の要件のために必要です。「運用上の」要件は、あらゆる種類の「ライブ」同期 (ミラーリングまたはレプリケーション) を除外します。これは、毎日の「ローカル」アクティビティが、本番環境で生成されているものと競合して、大量のデータを生成することが最も確実であるためです。スキーマの変更も可能です。（私が間違っている場合は、誰かが私を訂正してください）。
また、週単位または隔週単位で (基本的に、必要なトランザクション ログ バックアップの復元数が実際的でないほど多くなった場合)、運用環境から完全バックアップを取得し、古い蓄積されたトランザクション ログ バックアップを削除して、サイクルをリセットします。
これらはすべて完全に自動化できます。
良い質問です。私は自分の開発環境でこれと非常によく似たことをしています。
私がしているのは、複数のステージング データベースです。Once はアクティブなものであり、もう 1 つは本番システムからバックアップを復元するために使用できます。物事が進むにつれて、ステージング サーバーを使用して、あるステージング データベースから別のステージング データベースに切り替えることになります。
スキーマを移動するには、RedGate の 2 つのツールを使用します。最初の SQL ソース管理では、すべてのデータベース スキーマをチェックインして、ソース管理に保持できるようにします。2 つ目は SQL Compare です。これにより、2 つのデータベース間でスキーマを比較し、一方を他方に移行できます。
このプロセスでは、本番環境のバックアップを開発環境に持ち込んでから、SQL Compare を使用してスキーマの変更を古いステージング DB から新しいステージング DB に移行します。次に、すべての開発サーバーとステージング サーバーが、新しいステージング DB を指すように切り替えられます。
時間の経過とともに 2 つのステージング サーバーの間を行ったり来たりすると、常に 1 つのアクティブな開発サーバーと復元可能な 1 つのサーバーが存在します。
スキーマの変更を本番環境に移行する場合は、RedGate の SQL Compare を使用して変更スクリプトを作成するだけです。
私はこのプロセスをほぼ 4 年間 (SQL ソース管理は 2 年間) 使用しており、複数の開発者や、変更を本番環境にプッシュする場合に最適です。
RedGate の SQL Compare と SQL Source Control をチェックしてください。ご不明な点がございましたら、お知らせください。
あなたは相反する 2 つの目標を述べました。
データとスキーマに互換性がなくなる可能性があるため、これらの目標は矛盾しています。単純な例は列の追加または削除です。もう少し複雑な例は、ステージング データベースにテーブル制約を追加することです...不良データの修正に取り組んでいて、それが再び発生しないようにしている場合でも、運用データベースは引き続き不良データが含まれています。
ステージング (別名テスト) に復元された運用データの毎日のバックアップを作成し、テストに時間がかかったときに運用 Q を変更するために使用するスクリプトを実行することをお勧めします。非常に負荷の高いデータや変更がない限り、これはかなり迅速に行われるはずです。おそらく、自動化したくないほど十分に高速です（失敗した場合に何が起こるかを簡単に確認できます）。
必要に応じて、SQL エージェントを使用して、これらの両方の手順を自動化できます。