新しいデータセンターへのデータベースの移動
私の会社はインフラストラクチャを新しいデータセンターに移動しています。新しい環境が稼働する準備ができるまで、新しいサーバーのデータベースを現在の運用データベースと同期させる最善の方法を見つけようとしています。私はフルタイムのDBAではなく、いくつかの調査を行いました。私が読んだことから、国境を越えたレプリケーションのセットアップは私たちのニーズに最も適しているようです。
詳細：本番DBのサイズは約90 GBで、Robocopyを使用すると、そのコピーを新しいサーバーの1つに移動するのに約9時間かかりました。現在の本番データベースは、移行プロセス全体を通じてオンラインでアクセス可能な状態を維持する必要があります。これは単純なリカバリであるため、データベースミラーリングは使用できません。
トランザクションレプリケーションは、データベースの同期を維持するための最良の方法ですか？
私の計画：
- （完了）現在のデータベースとログを新しいサーバーに転送し、SQL Serverの新しいインスタンスにアタッチします
- 開発データベースマシンでディストリビューターをセットアップし、本番データベースからそれに発行します。
- 毎晩1回、ディストリビューターからプッシュされる更新を受け入れる新しいデータベースマシンでサブスクライバーを作成します。
私の心には2つあります。トランザクションレプリケーションでは、パブリッシュされた各テーブルに主キーがあり、本番データベースのテーブルの多くに主キーが定義されていないことが必要です。私の主な関心事はデータベースを同期させることだけなので、これはそれほど大きな問題になるとは思いません。データベースを使用するさまざまなアプリケーションを後でデータでテストしますが、それが深刻な問題ではないことを確認したいと思います。次に、関連するシステムDBも、マスターなどの元のインスタンスから移動する必要がありますか？新しい環境でActive Directoryセットアップに移行するので、ユーザーなどは気にしませんが、システムDBの必要性についてはわかりません。
そして一般的に、私はこれらの概念を正しく把握していますか？
あなたの現在の状況：
- 新しいデータセンターに移動する90 GBのデータベース。
- データベースは単純復旧中です。
- T-Repを使用してデータの同期を保つことを考えています。
- データベースには、主キーを持たない多くのテーブルがあります。これは、テーブルをパブリッシュするための要件です。
- 宛先のデータセンターにバックアップがすでにコピーされています。
あなたのアプローチには多くの欠点があります：
- T-Repは、他のテクノロジーに比べてセットアップが簡単ではありません。スキーマの変更がある場合は、新しいスナップショットが必要です。
- T-REPを使用する場合は、スキーマを変更する必要があります-ないテーブルに主キーを追加します。
- 既存のデータベースに変更を加える場合は、アプリケーションを完全にテストして、予期しない動作を回避する必要があります。
- データベースに多数のトランザクションがあり、2つのデータセンター間のネットワーク帯域幅に依存している場合、レプリケーションの待ち時間も発生します。
私の経験に基づいて、以下が私の推奨事項です：
- データベースを完全復旧に変更します。これは、PKの作成と比較して大きな影響はありません。
- ソースデータベースの完全バックアップを出荷します-圧縮してバックアップを取り、ファイルの初期化を即座に有効にします。これは、宛先データセンターでの復元時間を短縮するのに役立ちます。
- 宛先サーバー
WITH NORECOVERYにデータベースを復元します。 - Logshipping を実装し、バックアップから初期化します。
- ログ配布では、ログを1分ごとに発送してください。
- フェイルオーバーの日中に、ソースで最後のログ末尾のバックアップを取り、
WITH RECOVERYを使用して宛先でそれを復元します。これにより、宛先データベースがオンラインになります。 - 宛先データベースがオンラインになったら、 ユーザーの同期 を実行する必要があります。
- 新しいサーバーを指すようにweb.configを変更する必要があります。
システムデータベースを移動する必要はありません。ログイン、ジョブ、ssisパッケージなどをスクリプトで書き出し、宛先サーバーでそれらを作成する前に、すべての準備作業を必ず行ってください。
復元後の手順とその他のベストプラクティスについては、 この回答 を参照してください。
注：データベースミラーリング（使用しているsqlサーバーのエディションに応じてSYNCまたはASYNC）を実装することもできますが、ログ配布は実装するのが簡単であり、テストしても失望しません。上記の手法を使用して、テラバイトデータベースをあるデータセンターから別のデータセンターに正常に移動しましたが、完全に正常に機能します。
現在の本番データベースは、移行プロセス全体を通じてオンラインでアクセス可能な状態を維持する必要があります。
常にダウンタイムがあり、それをスケジュールする必要があります。クラスタリングなどのソリューションに多額の費用を投じても、フェイルオーバーするとダウンタイムが発生します。ダウンタイムがゼロに近い場合の投資額と、許容可能なダウンタイムで利用可能な場合のバランスをとる必要があります。
私自身はこれを使用する機会がなく、まだプレビュー段階にあると思いますが、AzureプラットフォームのSQL Data Syncは潜在的なオプションになる可能性があります。
https://Azure.Microsoft.com/en-gb/documentation/articles/sql-database-get-started-sql-data-sync/
オンプレミスおよびAzure SQLデータベースで機能し、データベースの同期を維持するための便利なツールのようです。