RecoveryManager クラスを使用したシャード マップに関する問題の解決Using the RecoveryManager class to fix shard map problems

RecoveryManager クラスを使用すると、ADO.NET アプリケーションで、シャード化されたデータベース環境におけるグローバル シャード マップ (GSM) とローカル シャード マップ (LSM) 間の不整合を簡単に検出して修正できます。The RecoveryManager class provides ADO.NET applications the ability to easily detect and correct any inconsistencies between the global shard map (GSM) and the local shard map (LSM) in a sharded database environment.

GSM と LSM はシャード化環境内の各データベースのマッピングを追跡します。The GSM and LSM track the mapping of each database in a sharded environment. 場合によっては、GSM と LSM の間で断絶が発生します。Occasionally, a break occurs between the GSM and the LSM. その場合は、RecoveryManager クラスを使用して断絶を検出し、修復します。In that case, use the RecoveryManager class to detect and repair the break.

RecoveryManager クラスは、 Elastic Database クライアント ライブラリに含まれています。The RecoveryManager class is part of the Elastic Database client library.

シャード マップ

用語の定義については、「 Elastic Database ツールの用語集」を参照してください。For term definitions, see Elastic Database tools glossary. ShardMapManager を使用してシャーディング ソリューション内のデータを管理する方法については、「 シャード マップの管理」を参照してください。To understand how the ShardMapManager is used to manage data in a sharded solution, see Shard map management.

Recovery Manager を使用する理由Why use the recovery manager

シャード化データベース環境では、データベースごとに 1 つのテナントがあり、サーバーごとに多くのデータベースがあります。In a sharded database environment, there is one tenant per database, and many databases per server. また、環境に多くのサーバーが存在する場合もあります。There can also be many servers in the environment. 各データベースはシャード マップでマッピングされるため、呼び出しを適切なサーバーとデータベースにルーティングできます。Each database is mapped in the shard map, so calls can be routed to the correct server and database. データベースは、シャーディング キーに従って追跡されます。各シャードにはキー値の範囲が割り当てられます。Databases are tracked according to a sharding key, and each shard is assigned a range of key values. たとえば、あるシャーディング キーは、"D" ~ "F" の顧客名を表します。For example, a sharding key may represent the customer names from "D" to "F." すべてのシャード (データベース) のマッピングとそのマッピング範囲は、グローバル シャード マップ (GSM) に保持されます。The mapping of all shards (aka databases) and their mapping ranges are contained in the global shard map (GSM). 各データベースには、シャードに属している範囲のマップも保持されます。これをローカル シャード マップ (LSM) と呼びます。Each database also contains a map of the ranges contained on the shard that is known as the local shard map (LSM). アプリがシャードに接続すると、すばやく取得できるようにマッピングがアプリにキャッシュされます。When an app connects to a shard, the mapping is cached with the app for quick retrieval. LSM は、キャッシュされたデータの検証に使用されます The LSM is used to validate cached data.

GSM と LSM は、次の理由により、同期されなくなる可能性があります。The GSM and LSM may become out of sync for the following reasons:

  1. 使用されていないと思われる範囲のシャードの削除またはシャードの名前変更The deletion of a shard whose range is believed to no longer be in use, or renaming of a shard. シャードを削除すると、孤立したシャード マッピングが発生します。Deleting a shard results in an orphaned shard mapping. 同様に、データベースの名前を変更した場合も、孤立したシャード マッピングが発生します。Similarly, a renamed database can cause an orphaned shard mapping. 変更の目的に応じて、シャードの削除が必要になることもあれば、シャードの場所を更新するだけで済むこともあります。Depending on the intent of the change, the shard may need to be removed or the shard location needs to be updated. 削除されたデータベースを回復するには、削除されたデータベースの復元に関する記事を参照してください。To recover a deleted database, see Restore a deleted database.
  2. geo フェールオーバー イベントの発生。A geo-failover event occurs. 続行するには、アプリケーションのシャード マップ マネージャーのサーバー名とデータベース名を更新し、シャード マップ内のすべてのシャードのシャード マッピングの詳細を更新する必要があります。To continue, one must update the server name, and database name of shard map manager in the application and then update the shard mapping details for all shards in a shard map. geo フェールオーバーが発生する場合は、フェールオーバー ワークフロー内でこのような復旧ロジックを自動化しておく必要があります。If there is a geo-failover, such recovery logic should be automated within the failover workflow. 復旧操作を自動化すると、geo 対応データベースを円滑に管理でき、ユーザーによる手動操作もなくすことができます。Automating recovery actions enables a frictionless manageability for geo-enabled databases and avoids manual human actions. データ センターの停止が発生した場合にデータベースを復元するオプションの詳細については、ビジネス継続性に関する記事およびディザスター リカバリーに関する記事をご覧ください。To learn about options to recover a database if there is a data center outage, see Business Continuity and Disaster Recovery.
  3. シャード化データベースまたは ShardMapManager データベースが以前の時点に復元された。Either a shard or the ShardMapManager database is restored to an earlier point-in time. バックアップを使った特定の時点への復旧については、バックアップを使用した復旧に関する記事をご覧ください。To learn about point in time recovery using backups, see Recovery using backups.

Azure SQL Database の Elastic Database ツール、geo レプリケーション、および復元の詳細については、以下をご覧ください。For more information about Azure SQL Database Elastic Database tools, geo-replication and Restore, see the following:

RecoveryManager からの ShardMapManager の取得Retrieving RecoveryManager from a ShardMapManager

最初の手順は、RecoveryManager インスタンスの作成です。The first step is to create a RecoveryManager instance. GetRecoveryManager メソッドを実行すると、現在の ShardMapManager インスタンスのリカバリ マネージャーが返されます。The GetRecoveryManager method returns the recovery manager for the current ShardMapManager instance. シャード マップ内の不整合を解決するには、最初に、特定のシャード マップの RecoveryManager を取得する必要があります。To address any inconsistencies in the shard map, you must first retrieve the RecoveryManager for the particular shard map.

 ShardMapManager smm = ShardMapManagerFactory.GetSqlShardMapManager(smmConnectionString,  
          ShardMapManagerLoadPolicy.Lazy);
          RecoveryManager rm = smm.GetRecoveryManager();

この例では、RecoveryManager が ShardMapManager から初期化されています。In this example, the RecoveryManager is initialized from the ShardMapManager. ShardMap が含まれた ShardMapManager も既に初期化されています。The ShardMapManager containing a ShardMap is also already initialized.

このアプリケーション コードではシャード マップを直接操作しないため、ファクトリ メソッドで使われる資格情報 (前の例では smmConnectionString) は、接続文字列が参照する GSM データベースに対する読み取り/書き込みアクセス許可を持つ資格情報である必要があります。Since this application code manipulates the shard map itself, the credentials used in the factory method (in the preceding example, smmConnectionString) should be credentials that have read-write permissions on the GSM database referenced by the connection string. これらの資格情報は、通常、データ依存ルーティングの接続で使用される資格情報とは異なります。These credentials are typically different from credentials used to open connections for data-dependent routing. 詳細については、 エラスティック データベース クライアントにおける資格情報の使用に関するページを参照してください。For more information, see Using credentials in the elastic database client.

シャードを削除した後の ShardMap からのシャードの削除Removing a shard from the ShardMap after a shard is deleted

DetachShard メソッド を実行すると、シャード マップから特定のシャードがデタッチされ、そのシャードに関連付けられたマッピングが削除されます。The DetachShard method detaches the given shard from the shard map and deletes mappings associated with the shard.

  • Location パラメーターはシャードの場所、具体的には、デタッチするシャードのサーバー名とデータベース名です。The location parameter is the shard location, specifically server name and database name, of the shard being detached.
  • shardMapName パラメーターは、シャード マップの名前です。The shardMapName parameter is the shard map name. これは、複数のシャード マップが同じシャード マップ マネージャーによって管理されている場合のみ必須です。This is only required when multiple shard maps are managed by the same shard map manager. 省略可能。Optional.

重要

この手法は、更新されるマッピング用の範囲が空であることが確実である場合のみ使用します。Use this technique only if you are certain that the range for the updated mapping is empty. 上記の方法では、移動される範囲のデータはチェックされないため、コード内にチェックを含めることが最善です。The methods above do not check data for the range being moved, so it is best to include checks in your code.

次の例では、シャードをシャード マップから削除します。This example removes shards from the shard map.

rm.DetachShard(s.Location, customerMap);

シャード マップには、シャードを削除する前の GSM 内におけるシャードの場所が反映されます。The shard map reflects the shard location in the GSM before the deletion of the shard. シャードが削除されたため、これは意図的な操作であり、シャーディング キー範囲が使用されなくなったと見なされます。Because the shard was deleted, it is assumed this was intentional, and the sharding key range is no longer in use. そうでない場合は、ポイント イン タイム リストアを実行してIf not, you can execute point-in time restore. 過去の特定の時点からシャードを回復できます。to recover the shard from an earlier point-in-time. その場合、以下のセクションで、シャードの不整合の検出について確認してください。回復するには、Point in time recovery (特定の時点への復旧) に関する記事を参照してください。(In that case, review the following section to detect shard inconsistencies.) To recover, see Point in time recovery.

データベースの削除は意図的な操作であることを前提とするため、最終的なクリーンアップ管理操作は、シャード マップ マネージャーでシャードのエントリを削除することです。Since it is assumed the database deletion was intentional, the final administrative cleanup action is to delete the entry to the shard in the shard map manager. これによって、アプリケーションが誤って予期しない範囲に情報を書き込むことがなくなります。This prevents the application from inadvertently writing information to a range that is not expected.

マッピングの相違点を検出するにはTo detect mapping differences

DetectMappingDifferences メソッド を実行すると、シャード マップ (ローカルとグローバルのいずれか) のうち 1 つが唯一の情報源として選択されて返され、両方のシャード マップ (GSM および LSM) でマッピングが調整されます。The DetectMappingDifferences method selects and returns one of the shard maps (either local or global) as the source of truth and reconciles mappings on both shard maps (GSM and LSM).

rm.DetectMappingDifferences(location, shardMapName);
  • location では、サーバー名とデータベース名を指定します。The location specifies the server name and database name.
  • shardMapName パラメーターは、シャード マップの名前です。The shardMapName parameter is the shard map name. これは、複数のシャード マップが同じシャード マップ マネージャーによって管理されている場合のみ必須です。This is only required if multiple shard maps are managed by the same shard map manager. 省略可能。Optional.

マッピングの相違点を解決するにはTo resolve mapping differences

ResolveMappingDifferences メソッド を実行すると、シャード マップ (ローカルとグローバルのいずれか) のうち 1 つが唯一の情報源として選択され、両方のシャード マップ (GSM および LSM) でマッピングが調整されます。The ResolveMappingDifferences method selects one of the shard maps (either local or global) as the source of truth and reconciles mappings on both shard maps (GSM and LSM).

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);
  • RecoveryToken パラメーターには、特定のシャードの GSM と LSM のマッピングの相違点を列挙します。The RecoveryToken parameter enumerates the differences in the mappings between the GSM and the LSM for the specific shard.
  • MappingDifferenceResolution 列挙体 は、シャード マッピングの相違点を解決するためのメソッドを指定するために使用します。The MappingDifferenceResolution enumeration is used to indicate the method for resolving the difference between the shard mappings.
  • LSM に正確なマッピングが含まれていて、そのため、シャード内のマッピングを使う必要のあるイベントでは、MappingDifferenceResolution.KeepShardMapping を使うことをお勧めします。MappingDifferenceResolution.KeepShardMapping is recommended that when the LSM contains the accurate mapping and therefore the mapping in the shard should be used. これは通常、フェールオーバーが発生した場合に当てはまります。そのような状況では、新しいサーバーにシャードが存在します。This is typically the case if there is a failover: the shard now resides on a new server. 最初に (RecoveryManager.DetachShard メソッドを使用して) GSM からシャードを削除する必要があるため、マッピングは GSM には存在しなくなります。Since the shard must first be removed from the GSM (using the RecoveryManager.DetachShard method), a mapping no longer exists on the GSM. そのため、LSM を使って、シャード マッピングを再確立する必要があります。Therefore, the LSM must be used to re-establish the shard mapping.

シャードを復元した後の ShardMap へのシャードのアタッチAttach a shard to the ShardMap after a shard is restored

AttachShard メソッド を実行すると、特定のシャードがシャード マップにアタッチされます。The AttachShard method attaches the given shard to the shard map. その後、シャード マップの不整合が検出され、復元された時点のシャードと一致するようにマッピングが更新されます。It then detects any shard map inconsistencies and updates the mappings to match the shard at the point of the shard restoration. ポイントインタイム リストアでは既定で新しいデータベースにタイムスタンプが付加されるため、(シャードの復元の実行前に) 元のデータベース名を反映するようにデータベース名が変更されていることを前提とします。It is assumed that the database is also renamed to reflect the original database name (before the shard was restored), since the point-in time restoration defaults to a new database appended with the timestamp.

rm.AttachShard(location, shardMapName)
  • location パラメーターは、アタッチするシャードのサーバー名とデータベース名です。The location parameter is the server name and database name, of the shard being attached.
  • shardMapName パラメーターは、シャード マップの名前です。The shardMapName parameter is the shard map name. これは、複数のシャード マップが同じシャード マップ マネージャーによって管理されている場合のみ必須です。This is only required when multiple shard maps are managed by the same shard map manager. 省略可能。Optional.

この例では、以前の時点から最近復元されたシャード マップにシャードを追加します。This example adds a shard to the shard map that has been recently restored from an earlier point-in time. シャード (厳密には LSM 内のシャードのマッピング) が復元されたため、GSM 内のシャード エントリと不整合が生じている可能性があります。Since the shard (namely the mapping for the shard in the LSM) has been restored, it is potentially inconsistent with the shard entry in the GSM. このコード例では、外部でシャードが復元され、データベースの元の名前に変更されています。Outside of this example code, the shard was restored and renamed to the original name of the database. LSM 内のマッピングは復元されたため、信頼されたマッピングであると見なします。Since it was restored, it is assumed the mapping in the LSM is the trusted mapping.

rm.AttachShard(s.Location, customerMap);
var gs = rm.DetectMappingDifferences(s.Location);
   foreach (RecoveryToken g in gs)
    {
    rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
    }

シャードの geo フェールオーバー (復元) の後のシャードの場所の更新Updating shard locations after a geo-failover (restore) of the shards

geo フェールオーバーが発生する場合は、セカンダリ データベースが書き込みアクセス許可を与えられて、新しいプライマリ データベースになります。If there is a geo-failover, the secondary database is made write accessible and becomes the new primary database. サーバーの名前が、場合によっては (構成による) データベースの名前も、元のプライマリと異なっている今年があります。The name of the server, and potentially the database (depending on your configuration), may be different from the original primary. そのため、GSM と LSM のシャードのマッピング エントリを修正する必要があります。Therefore the mapping entries for the shard in the GSM and LSM must be fixed. 同様に、データベースを別の名前、別の場所、または以前の時点に復元した場合も、シャード マップで不整合が生じている可能性があります。Similarly, if the database is restored to a different name or location, or to an earlier point in time, this might cause inconsistencies in the shard maps. 適切なデータベースへのオープンな接続の分配は、シャード マップ マネージャーが処理します。The Shard Map Manager handles the distribution of open connections to the correct database. 分配は、シャード マップ内のデータと、アプリケーション要求の対象であるシャーディング キーに基づいて行われます。Distribution is based on the data in the shard map and the value of the sharding key that is the target of the applications request. geo フェールオーバー後は、この情報を、回復されたデータベースの正確なサーバー名、データベース名、およびシャード マッピングを使用して更新する必要があります。After a geo-failover, this information must be updated with the accurate server name, database name and shard mapping of the recovered database.

ベスト プラクティスBest practices

geo フェールオーバーと復旧は一般的に、アプリケーションのクラウド管理者が Azure SQL データベースのビジネス継続性機能の 1 つを意図的に使用して管理する操作です。Geo-failover and recovery are operations typically managed by a cloud administrator of the application intentionally utilizing one of Azure SQL databases business continuity features. ビジネス継続性の計画には、ビジネス運営を中断なく確実に続行できるプロセス、手順、手段が必要です。Business continuity planning requires processes, procedures, and measures to ensure that business operations can continue without interruption. 実行する復旧アクションに基づいて GSM と LSM が最新の状態に維持されるように、RecoveryManager クラスの一部として提供されているメソッドをこのワークフロー内で使用してください。The methods available as part of the RecoveryManager class should be used within this work flow to ensure the GSM and LSM are kept up-to-date based on the recovery action taken. フェールオーバー後に GSM と LSM に正確な情報が反映されていることを正しく確認するには、次の 5 つの基本的な手順を実行します。There are five basic steps to properly ensuring the GSM and LSM reflect the accurate information after a failover event. これらの手順を実行するアプリケーション コードを、既存のツールやワークフローに統合できます。The application code to execute these steps can be integrated into existing tools and workflow.

  1. Recovery Manager を ShardMapManager から取得します。Retrieve the RecoveryManager from the ShardMapManager.
  2. シャード マップから使用しなくなったシャードをデタッチします。Detach the old shard from the shard map.
  3. 新しいシャードの場所を含むシャード マップに、新しいシャードをアタッチします。Attach the new shard to the shard map, including the new shard location.
  4. GSM と LSM のマッピングの不整合が検出されます。Detect inconsistencies in the mapping between the GSM and LSM.
  5. GSM と LSM の相違点を、LSM を信頼して解決します。Resolve differences between the GSM and the LSM, trusting the LSM.

この例では、次の手順を実行します。This example performs the following steps:

  1. フェールオーバーの前に、シャードの場所が反映されているシャード マップからシャードを削除します。Removes shards from the Shard Map that reflect shard locations before the failover event.

  2. 新しいシャード場所が ("Configuration.SecondaryServer" パラメーターは、サーバー名は新しく、データベース名は同じです) が反映されているシャード マップにシャードをアタッチします。Attaches shards to the Shard Map reflecting the new shard locations (the parameter "Configuration.SecondaryServer" is the new server name but the same database name).

  3. 各シェードの GSM と LSM のマッピングの相違点を検出して、回復トークンを取得します。Retrieves the recovery tokens by detecting mapping differences between the GSM and the LSM for each shard.

  4. 各シャードの LSM のマッピングを信頼して、不整合を解決します。Resolves the inconsistencies by trusting the mapping from the LSM of each shard.

    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);
             }
         }
     }
    

その他のリソースAdditional resources

まだ弾力性データベース ツールを使用していない場合は、Not using elastic database tools yet? ファースト ステップ ガイドを参照してください。Check out our Getting Started Guide. 質問がある場合は、SQL Database のフォーラムに投稿してください。機能に関するご要望は、SQL Database に関するフィードバック フォーラムにお寄せください。For questions, please reach out to us on the SQL Database forum and for feature requests, please add them to the SQL Database feedback forum.