ネットワーク上でダウンタイムの少ない巨大なSQL Serverデータベースを移行する最良の方法

問題定義

データベースサーバーを他のデータセンターに転送する必要があります。Microsoft SQL Server 2012 Enterprise（64ビット）で実行され、約2TBと1TBの2つのデータベースが含まれています。

ダウンタイムがほとんどないか、まったくないことが理想的です。

仕事量

これらのデータベースは.NET Webサイトに使用され、常に更新されています。

ただし、週末に利用できなくても問題ありません。現在使用中のDBは、新しいDBに切り替えるまで使用中の唯一のDBのままです。

この切り替えは、理想的には、DBが更新されていないことを確認しながら、新しいDBサーバーを指すようにDNSエントリを変更するだけで行われます。

また、1つのサーバーから別のサーバーへの切り替え（ダウンタイム）が低く抑えられている限り、この操作にかかる時間は実際には重要ではありません。

考慮されるアプローチ

• バックアップと復元

  これは過去に行われたことがありますが、内部ネットワークを介して行われたにもかかわらず、インターネットよりも効率的にダウンタイムが長くなりました

• ログ配布

  私の知る限り、このアプローチは、マスター/スレーブを構成し、マスターDBの正確なコピーを読み取り専用のスレーブに転送することにより、ダウンタイムを最小限に抑えます。上記のように、スレーブへのアクセスは不要であり、データ破損なしでマスターDBのレプリカを保持する方法が必要です。

  また、リソース使用率の面でも非常に効率的であるようで、マスターのパフォーマンスにはほとんど影響しません。

  私はこのアプローチについて間違っているかもしれませんので、私を修正してください。

• データベースミラーリング

  私はそのアプローチをあまり認識していませんが、有効なオプションのようです。リアルタイムで同期する必要はなく、マスターのパフォーマンスは非常に重要であるため、このアプローチを選択する場合は非同期が最適です。

• 別のオプション？

  このサーバーはベアメタルハードウェア上で直接実行されるため、残念ながら低レベルのソリューションはオプションではありません。たぶんこれを達成するためのより良い方法がありますか？

制約

説明したように、これらのデータベースは維持するのが難しいほど大きなものですが、それは別の問題です。

SQL Serverのバージョンは同じです（Microsoft SQL Server 2012 Enterprise 64ビット）。

2つのデータセンター間のネットワーク経由で転送する必要があるため、おそらくインターネット経由で転送する必要があります。最初の同期のために、あるサイトから別のサイトにディスクを送信することは、残念ながらオプションではありません。転送に何らかのセキュリティを持たせることが理想的ですが、この状況を最大限に活用します。

これにより、このタスクに対する私たちのニーズの非常に良い概要が得られるはずです。

直接的なバックアップと復元は明らかに外にあります。また、いかなる種類の複製も考慮しません。

データベースミラーリングは比較的簡単にセットアップできますが、2つのサーバー間のリアルタイム接続、パートナーとエンドポイントのセットアップなどが必要です。可用性グループはオプションかもしれませんが、ネットワークの複雑さに加えて、両方のサーバーも必要です。同じWSFCのメンバーとして-つまり、両方が同じドメインに存在する必要があります。これは、データセンターの移動のための典型的なセットアップではありません（または一時的に動作するようにできます）。

私の投票はログ配布になります。これの良いところは、すでに取っているバックアップとログバックアップを使用できることです（右？）、必ずしも2つのデータベース間のリアルタイム接続を持っている必要はありません-それぞれについて知る必要はありませんその他、ミラーリング、パートナー、セキュリティなどのエンドポイントを設定する必要はありません。古いサーバーから新しいサーバーに復元できる場所にファイルを取得する方法が必要なだけです。完全バックアップを事前に十分に取って、新しいサーバーに引き継いで復元し、その時点からカットオーバーの瞬間まで増分ログバックアップを適用することができます。プロセスは実際には非常に簡単であり、問​​題に遭遇した場合はオンラインでログ配布に関する多くのチュートリアルが利用できます。

Webアプリがデータベースと共に移動している場合、DNSは伝播するのに時間がかかることがあるため、古いアプリの接続文字列を切り替えて、書き込み可能になったら新しいデータベースサーバーのIPを指すようにすることができます。なぜなら、切り替え後でも、TTL設定が厳しい場合でも、クライアントは引き続き古いWebサーバーにアクセスする可能性があるからです。それはすべて、プロバイダーがあなたのTTLをどの程度尊重しているかによって決まります。

私は最近、ミラーリングを使用して6つのデータベース間で15 TBを移行しました。非常にシンプルで、わずか数秒のフェイルオーバー時間で完璧に機能しました。

編集：

2つの新しい仮想化されたSQL Serverがありました。データベースは、単純に成長した3つのサーバーからのものであり、それらでホストされている小規模なデータベースのパフォーマンスに影響を与えていました。

プロセスは非常に簡単でした。

1. 週末の完全バックアップが完了するまで待ちます
2. 新しいサーバーへの復元なしで復元する
3. それらの復元が完了したら、バックアップを一時停止します
4. オリジナルからの最新のログバックアップまで1回追加の復元を実行し、復元なし
5. 6つすべてでミラーリングを開始する
6. バックアップを再開する

ネットワークの負荷などを減らすためにフェイルオーバーする準備ができるまで、非同期モードのままにしておくことを選択しました。ミラーリングは、メンテナンス（インデックス/統計）およびその他の大量のアクティビティ中に遅延を引き起こすという評判がありますが、そうしませんでしたそれが真実であることがわかります。手動フェールオーバーの前に同期モードに切り替える必要があります。

次のメンテナンスウィンドウで、各データベースを手動でフェールオーバーし、いくつかの煙テストの後、ミラーリングをオフにし、最終的に元のサーバーから古いデータファイルを削除しました。このプロセスの1つの癖は、ミラー化されたデータベースに障害が発生すると、以前のプライマリを回復状態のままにするため、それらを単にドロップすることに不安がない限り、それらをオンラインに戻してからデタッチする必要があります。 。また、自動フェールオーバーが必要ないため、このいずれの監視も構成しませんでした。これは制御されたイベントでした。

さらに詳細が必要な場合はお知らせください。サーバーとネットワークの仕様は省略しましたが、必要に応じて提供できます。

ありがとう