ネットワーク経由のダウンタイムが少ない巨大なSQL Serverデータベースを移行する最良の方法
問題の定義
データベースサーバーを他のデータセンターに転送する必要があります。 Microsoft SQL Server 2012 Enterprise（64ビット）で実行され、約2TBと1TBの2つのデータベースが含まれています。
このためのダウンタイムがほとんどまたはまったくないことが理想的です。
ワークロード
これらのデータベースは.NET Webサイトで使用され、常に更新されています。
週末に利用できなくても構いません。現在使用中のDBは、新しいDBに切り替えるまで、使用中の唯一のDBのままです。
この切り替えは、DBが更新されていないことを確認しながら、新しいDBサーバーを指すようにDNSエントリを変更するだけで行うのが理想的です。
また、あるサーバーから別のサーバーへの切り替え（ダウンタイム）が低く抑えられている限り、この操作にかかる時間はそれほど重要ではありません。
検討されるアプローチ
バックアップと復元
これは過去に行われましたが、内部ネットワークを通じて行われたとしても長いダウンタイムが発生したため、インターネットよりも効率的です
ログ配送
私が理解している限り、このアプローチは、マスター/スレーブを構成し、マスターDBの正確なコピーを読み取り専用のスレーブに転送することで、ダウンタイムを最小限に抑えます。上記のように、スレーブへのアクセスは必要ありません。データが破損することなくマスターDBのレプリカを作成する方法が必要です。
また、リソースの使用率の面でも非常に効率的で、マスターパフォーマンスにはあまり影響しません。
私はこのアプローチについて間違っているかもしれないので、遠慮なく修正してください。
データベースのミラーリング
私はそのアプローチにあまり気づいていませんが、有効なオプションのようです。リアルタイムで同期する必要はなく、マスターのパフォーマンスは非常に重要であるため、このアプローチを選択する場合は非同期が適しています。
その他のオプション？
そのサーバーはベアメタルハードウェア上で直接実行されるため、より低いレベルのソリューションは残念ながらオプションではありません。たぶんこれを行うためのより良い方法がありますか？
制約
説明したように、それらのデータベースは維持するのが困難なほどかなり大きいですが、それは別の問題です。
SQL Serverのバージョンは同じです（Microsoft SQL Server 2012 Enterprise 64ビット）。
2つのデータセンター間でネットワーク経由で転送する必要があるため、おそらくインターネット経由で転送する必要があります。最初の同期のために1つのサイトから別のサイトにディスクを送信することは、残念ながらオプションではありません。転送に何らかのセキュリティを設定することが理想的ですが、この状況を最大限に活用します。
これで、このタスクに対する私たちのニーズのかなり良い概要が得られるはずです。うまくいけば、以前にそのような状況に直面しなければならなかった人もいます。
単純なバックアップと復元は明らかに機能していません。また、いかなる種類の複製も考慮しません。
データベースミラーリングの設定は比較的簡単ですが、2つのサーバー間のリアルタイム接続、パートナーとエンドポイントの設定などが必要です。可用性グループを選択することもできますが、ネットワークの複雑さに加えて、両方のサーバーも必要です。同じWSFCのメンバーとして-両方が同じドメインに属している必要があります。これは、データセンターを移動するための一般的な設定ではありません（または一時的に機能させることもできます）。
私の投票は丸太の発送です。これの良い点は、すでに取っているバックアップとログバックアップを使用できることです（そうですか？）2つのデータベース間のリアルタイム接続を必ずしも持っている必要はありません-彼らはそれぞれについて知る必要はありませんその他、ミラーリング、パートナー、セキュリティなどのエンドポイントを設定する必要はありません。古いサーバーから新しいサーバーに復元できる場所にファイルを取得する方法が必要なだけです。事前にフルバックアップを取り、それを新しいサーバーに取得して復元し、その時点からカットオーバーの瞬間まで（差分の可能性があり）増分ログバックアップを適用できます。プロセスは実際には非常に単純で、問題が発生した場合にオンラインで利用できるログ配布に関するチュートリアルが多数あります。
Webアプリがデータベースと一緒に移動している場合、DNSが伝播するまでに時間がかかることがあるため、古いアプリの接続文字列を切り替えて、書き込み可能な状態になったら新しいデータベースサーバーのIPを指すようにすることができます。 、-切り替え後、およびTTL設定が厳しい場合でも、クライアントは引き続き古いWebサーバーにアクセスする可能性があります。すべては、プロバイダーがTTLをどれだけ尊重しているかに依存します。
最近、ミラーリングを使用して6つのデータベース間で15 TBを移行しました。非常にシンプルで、数秒のフェイルオーバー時間で完全に機能します。
編集：
2つの新しい仮想SQLサーバーがありました。データベースは、3つのサーバーから取得されたものであり、サーバーが大きくなりすぎて、それらがホストする小規模なデータベースのパフォーマンスに影響を与えていました。
プロセスは非常に簡単でした。
- 週末の完全バックアップが完了するのを待ちます
- 新しいサーバーに復元せずに復元
- それらの復元が完了したら、バックアップを一時停止します
- 元のファイルから最新のログバックアップまでの追加の復元を1つ実行し、リカバリを残さない
- 6つすべてでミラーリングを開始する
- バックアップを再開
ネットワークなどの負荷を軽減するためにフェイルオーバーする準備ができるまで、非同期モードのままにしておくことを選択しました。ミラーリングには、メンテナンス（インデックス/統計）やその他の大量のアクティビティ中に待ち時間が発生するという評判がありますが、私はしませんでしたそれが本当であることがわかります。手動フェイルオーバーの前に同期モードに切り替える必要があります。
次のメンテナンスウィンドウで、各データベースを手動でフェールオーバーし、いくつかの煙のテストの後、ミラーリングをオフにし、最終的に元のサーバーから古いデータファイルを削除しました。このプロセスの1つの奇妙な点は、ミラーリングされたデータベースに障害が発生すると、以前のプライマリがリカバリ状態のままになるため、それらを単にドロップするだけでは問題がない場合は、それらをオンラインに戻してからデタッチするか、任意の望ましい削除方法です。 。また、自動フェールオーバーが必要なかったため、これらのいずれについてもウィットネスを構成しませんでした。これは制御されたイベントでした。
さらに詳細が必要な場合はお知らせください。サーバーとネットワークの仕様は省略しましたが、必要に応じて提供できます。
ありがとう