適用対象:
Azure SQL データベース
RecoveryManager クラスを使用すると、ADO.NET アプリケーションで、シャード化されたデータベース環境におけるグローバル シャード マップ (GSM) とローカル シャード マップ (LSM) 間の不整合を簡単に検出して修正できます。
GSM と LSM はシャード化環境内の各データベースのマッピングを追跡します。 場合によっては、GSM と LSM の間で断絶が発生します。 その場合は、 RecoveryManager クラスを使用して、中断を検出して修復します。
RecoveryManager クラスは、スケーラブルなクラウド データベースの構築の一部です。
用語の定義については、「 Elastic Database ツールの用語集」を参照してください。
ShardMapManagerを使用してシャード 化されたソリューション内のデータを管理する方法を理解するには、「シャード マップ マネージャーを使用してデータベースをスケールアウトする」を参照してください。
Recovery Manager を使用する理由
シャード化されたデータベース環境では、データベースごとに 1 つのテナントがあり、サーバーごとに多数のデータベースがあります。 また、環境に多くのサーバーが存在する場合もあります。 各データベースはシャード マップでマッピングされるため、呼び出しを適切なサーバーとデータベースにルーティングできます。 データベースは、シャーディング キーに従って追跡されます。各シャードにはキー値の範囲が割り当てられます。 たとえば、シャーディング キーは、"D" から "F" までの顧客名を表します。すべてのシャード (データベースとも呼ばれます) とそのマッピング範囲のマッピングは、 グローバル シャード マップ (GSM) に含まれています。 各データベースには、シャードに属している範囲のマップも保持されます。これをローカル シャード マップ (LSM) と呼びます。 アプリがシャードに接続すると、すばやく取得できるようにマッピングがアプリにキャッシュされます。 LSM は、キャッシュされたデータの検証に使用されます
GSM と LSM は、次の理由により同期しなくなる可能性があります。
- 使用されていないと思われる範囲のシャードの削除またはシャードの名前変更 シャードを削除すると、孤立したシャード マッピングが発生します。 同様に、データベースの名前を変更した場合も、孤立したシャード マッピングが発生します。 変更の意図によっては、シャードを削除するか、シャードの場所を更新する必要があります。 削除されたデータベースを復旧するには、「 Azure SQL Database のバックアップからデータベースを復元する」を参照してください。
- geo フェールオーバー イベントの発生。 続行するには、アプリケーションのシャード マップ マネージャーのサーバー名とデータベース名を更新し、シャード マップ内のすべてのシャードのシャード マッピングの詳細を更新する必要があります。 ジオフェイルオーバーが発生した場合、このような復旧ロジックはフェイルオーバーワークフロー内で自動化する必要があります。 復旧操作を自動化すると、geo 対応データベースを円滑に管理でき、ユーザーによる手動操作もなくすことができます。 データ センターの停止が発生した場合にデータベースを復旧するオプションについては、 Azure SQL Database のビジネス継続性 と ディザスター リカバリーのガイダンス (Azure SQL Database) を参照してください。
- シャード データベースまたは
ShardMapManagerデータベースのいずれかが過去の特定の時点に復元されました。 バックアップを使用した特定の時点への復旧の詳細については、「 Azure SQL Database のバックアップからデータベースを復元する」を参照してください。
Azure SQL Database Elastic Database ツール、geo レプリケーション、および復元の詳細については、次を参照してください。
ShardMapManager から RecoveryManager を取得する
最初の手順では、 RecoveryManager インスタンスを作成します。
GetRecoveryManager メソッドを実行すると、現在の ShardMapManager インスタンスのリカバリ マネージャーが返されます。 シャード マップの不整合に対処するには、まず、特定のシャード マップの RecoveryManager を取得する必要があります。
ShardMapManager smm = ShardMapManagerFactory.GetSqlShardMapManager(smmConnectionString,
ShardMapManagerLoadPolicy.Lazy);
RecoveryManager rm = smm.GetRecoveryManager();
この例では、 RecoveryManager は ShardMapManagerから初期化されます。
ShardMapManagerを含むShardMapも既に初期化されています。
このアプリケーション コードはシャード マップ自体を操作するため、ファクトリ メソッドで使用される資格情報 (前の例では、 smmConnectionString) は、接続文字列によって参照される GSM データベースに対する読み取り/書き込みアクセス許可を持つ資格情報である必要があります。 これらの資格情報は、通常、データ依存ルーティングの接続で使用される資格情報とは異なります。 詳細については、「 Elastic Database クライアント ライブラリへのアクセスに使用される資格情報」を参照してください。
シャードが削除された後に ShardMap からシャードを削除する
DetachShard メソッド を実行すると、シャード マップから特定のシャードがデタッチされ、そのシャードに関連付けられたマッピングが削除されます。
-
___locationパラメーターは、デタッチされるシャードの場所、具体的にはサーバー名とデータベース名を指します。 -
shardMapNameパラメーターはシャード マップ名です。 これは、複数のシャード マップが同じシャード マップ マネージャーによって管理されている場合のみ必須です。 省略可能。
重要
この手法は、更新されたマッピングの範囲が空であることが確実な場合にのみ使用します。 これらのメソッドは、移動される範囲のデータをチェックしないため、コードにチェックを含めるのが最善です。
次の例では、シャードをシャード マップから削除します。
rm.DetachShard(s.Location, customerMap);
シャード マップには、シャードを削除する前の GSM 内におけるシャードの場所が反映されます。 シャードが削除されたため、これは意図的なものであると見なされ、シャーディング キーの範囲は使用されなくなりました。 そうでない場合は、ポイント イン タイム リストアを実行して 過去の特定の時点シャドーを復元するには。 (その場合は、次のセクションを確認してシャードの不整合を検出します)。復旧するには、「 Azure SQL Database のバックアップからデータベースを復元する」を参照してください。
データベースの削除は意図的なものであると想定されているため、最終的な管理クリーンアップアクションは、シャード マップ マネージャーでシャードへのエントリを削除することです。 これにより、アプリケーションが予期しない範囲に誤って情報を書き込むのを防ぐことができます。
マッピングの違いを検出する
DetectMappingDifferences メソッド を実行すると、シャード マップ (ローカルとグローバルのいずれか) のうち 1 つが唯一の情報源として選択されて返され、両方のシャード マップ (GSM および LSM) でマッピングが調整されます。
rm.DetectMappingDifferences(___location, shardMapName);
-
___locationは、サーバー名とデータベース名を指定します。 -
shardMapNameパラメーターはシャード マップ名です。 これは、複数のシャード マップが同じシャード マップ マネージャーによって管理されている場合のみ必須です。 省略可能。
マッピングの違いを解決する
ResolveMappingDifferences メソッド を実行すると、シャード マップ (ローカルとグローバルのいずれか) のうち 1 つが唯一の情報源として選択され、両方のシャード マップ (GSM および LSM) でマッピングが調整されます。
ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);
-
RecoveryTokenパラメーターは、特定のシャードの GSM と LSM のマッピングの違いを列挙します。 - MappingDifferenceResolution 列挙体 は、シャード マッピングの相違点を解決するためのメソッドを指定するために使用します。
-
MappingDifferenceResolution.KeepShardMappingLSM に正確なマッピングが含まれている場合は、シャード内のマッピングを使用することをお勧めします。 これは通常、フェールオーバーがある場合です。シャードは新しいサーバー上に存在するようになりました。 シャードは最初に (RecoveryManager.DetachShardメソッドを使用して) GSM から削除する必要があるため、GSM にマッピングは存在しなくなります。 そのため、LSM を使って、シャード マッピングを再確立する必要があります。
シャードを復元した後の ShardMap へのシャードのアタッチ
AttachShard メソッド を実行すると、特定のシャードがシャード マップにアタッチされます。 その後、シャード マップの不整合が検出され、復元された時点のシャードと一致するようにマッピングが更新されます。 ポイントインタイム リストアは既定でタイムスタンプが追加された新しいデータベースに設定されるため、データベースの名前も元のデータベース名 (シャードが復元される前) を反映するように変更されると想定されます。
rm.AttachShard(___location, shardMapName)
-
___locationパラメーターは、接続されているシャードのサーバー名とデータベース名です。 -
shardMapNameパラメーターはシャード マップ名です。 これは、複数のシャード マップが同じシャード マップ マネージャーによって管理されている場合のみ必須です。 省略可能。
この例では、以前の時点から最近復元されたシャード マップにシャードを追加します。 シャード (つまり、LSM 内のシャードのマッピング) が復元されたため、GSM のシャード エントリと矛盾している可能性があります。 このコード例では、外部でシャードが復元され、データベースの元の名前に変更されています。 復元されたので、LSM 内のマッピングが信頼できるマッピングであると見なされます。
rm.AttachShard(s.Location, customerMap);
var gs = rm.DetectMappingDifferences(s.Location);
foreach (RecoveryToken g in gs)
{
rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
}
シャードの geo フェールオーバー (復元) の後のシャードの場所を更新する
geo フェールオーバーがある場合、セカンダリ データベースは書き込みアクセス可能になり、新しいプライマリ データベースになります。 サーバーの名前と、データベース (構成によっては) が元のプライマリと異なる場合があります。 そのため、GSM と LSM のシャードのマッピング エントリを修正する必要があります。 同様に、データベースを別の名前、別の場所、または以前の時点に復元した場合も、シャード マップで不整合が生じている可能性があります。 適切なデータベースへのオープンな接続の分配は、シャード マップ マネージャーが処理します。 分配は、シャード マップ内のデータと、アプリケーション要求の対象であるシャーディング キーに基づいて行われます。 ジオフェイルオーバー後、この情報は復旧したデータベースの正確なサーバー名、データベース名、シャードマッピングで更新される必要があります。
ベスト プラクティス
geo フェールオーバーと復旧は一般的に、アプリケーションのクラウド管理者が Azure SQL Database のビジネス継続性機能を意図的に使用して管理する操作です。 ビジネス継続性の計画には、ビジネス運営を中断なく確実に続行できるプロセス、手順、手段が必要です。
RecoveryManager クラスの一部として使用できるメソッドは、このワークフロー内で使用して、実行された復旧アクションに基づいて GSM と LSM が up-to日付に保持されるようにする必要があります。 フェールオーバー後に GSM と LSM に正確な情報が反映されていることを正しく確認するには、次の 5 つの基本的な手順を実行します。 これらの手順を実行するアプリケーション コードを、既存のツールやワークフローに統合できます。
- ShardMapManager から
RecoveryManagerを取得します。 - シャード マップから使用しなくなったシャードをデタッチします。
- 新しいシャードの場所を含むシャード マップに、新しいシャードをアタッチします。
- GSM と LSM のマッピングの不整合が検出されます。
- GSM と LSM の相違点を、LSM を信頼して解決します。
この例では、次の手順を実行します。
フェールオーバーの前に、シャードの場所が反映されているシャード マップからシャードを削除します。
新しいシャードの場所を反映させるために、シャードをシャード マップに追加します（パラメーター
Configuration.SecondaryServerは新しいサーバー名であり、データベース名は変わりません）。各シェードの GSM と LSM のマッピングの相違点を検出して、回復トークンを取得します。
各シャードの LSM のマッピングを信頼して、不整合を解決します。
var shards = smm.GetShards(); foreach (shard s in shards) { if (s.Location.Server == Configuration.PrimaryServer) { ShardLocation slNew = new ShardLocation(Configuration.SecondaryServer, s.Location.Database); rm.DetachShard(s.Location); rm.AttachShard(slNew); var gs = rm.DetectMappingDifferences(slNew); foreach (RecoveryToken g in gs) { rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping); } } }
関連するコンテンツ
まだ弾力性データベース ツールを使用していない場合は、 ファースト ステップ ガイドを参照してください。 ご質問がある場合は、SQL Database に関する Microsoft Q&A 質問ページを参照してください。機能に関するご要望は、SQL Database に関するフィードバック フォーラムで新しいアイデアを追加したり、既存のアイデアに投票したりしてください。