スケールアウトされたクラウド データベース間のデータ移動Moving data between scaled-out cloud databases

お客様がサービスとしてのソフトウェアの開発者で、突然、アプリが多大な要求を受けた場合、その増加に対応する必要があります。If you are a Software as a Service developer, and suddenly your app undergoes tremendous demand, you need to accommodate the growth. そのため、データベース (シャード) を追加します。So you add more databases (shards). データの整合性を破壊することなく、新しいデータベースにデータを再分散する方法How do you redistribute the data to the new databases without disrupting the data integrity? Split-Merge ツールを使用して、データを制約付きデータベースから新しいデータベースに移動します。Use the split-merge tool to move data from constrained databases to the new databases.

Split-Merge ツールは、Azure Web サービスとして実行されます。The split-merge tool runs as an Azure web service. 管理者または開発者は、ツールを使用して、シャードレット (シャードからのデータ) を異なるデータベース (シャード) 間で移動します。An administrator or developer uses the tool to move shardlets (data from a shard) between different databases (shards). このツールは、シャード マップの管理を使用して、サービス メタデータ データベースを維持し、一貫したマッピングを保証します。The tool uses shard map management to maintain the service metadata database, and ensure consistent mappings.

概要

ダウンロードDownload

Microsoft.Azure.SqlDatabase.ElasticScale.Service.SplitMergeMicrosoft.Azure.SqlDatabase.ElasticScale.Service.SplitMerge

ドキュメントDocumentation

  1. エラスティック データベース Split-Merge ツールに関するチュートリアルElastic database Split-Merge tool tutorial
  2. Split-Merge セキュリティの構成Split-Merge security configuration
  3. Split-Merge セキュリティの構成Split-merge security considerations
  4. シャード マップの管理Shard map management
  5. 既存のデータベースを移行してスケールアウトMigrate existing databases to scale-out
  6. エラスティック データベース ツールElastic database tools
  7. エラスティック データベース ツールの用語集Elastic Database tools glossary

Split-Merge ツールを使用する理由Why use the split-merge tool

  • 柔軟性Flexibility

    アプリケーションは、単一の Azure SQL DB データベースの制限を超えて柔軟に拡張できる必要があります。Applications need to stretch flexibly beyond the limits of a single Azure SQL DB database. ツールを使用して、整合性を維持したまま、新しいデータベースに必要なデータを移動します。Use the tool to move data as needed to new databases while retaining integrity.

  • 分割して増加Split to grow

    爆発的な増加に対応するために全体的な容量を増やすには、容量ニーズを満たすために、データをシャーディングし、データを分散するデータベースの数を段階的に増やすことによって追加の容量を確保します。To increase overall capacity to handle explosive growth, create additional capacity by sharding the data and by distributing it across incrementally more databases until capacity needs are fulfilled. これは分割機能の典型的な例です。This is a prime example of the split feature.

  • マージして縮小Merge to shrink

    容量は、ビジネスの季節的な性質によって縮小させる必要があります。Capacity needs shrink due to the seasonal nature of a business. このツールを使用すると、ビジネスの成長が鈍化したときに、より少ないスケール単位に縮小できます。The tool lets you scale down to fewer scale units when business slows. Elastic Scale の Split-Merge サービスの "マージ" 機能を使用すると、この要件に対処できます。The ‘merge’ feature in the Elastic Scale split-merge Service covers this requirement.

  • シャードレットの移動によるホットスポットの管理Manage hotspots by moving shardlets

    データベースごとに複数のテナントがある場合、シャードレットをシャードに割り当てることが、一部のシャードの容量ボトルネックにつながります。With multiple tenants per database, the allocation of shardlets to shards can lead to capacity bottlenecks on some shards. これには、シャードレットを再び割り当てたり、ビジー状態のシャードレットを新しいシャードや使用率の低いシャードに移動したりする操作が必要になります。This requires re-allocating shardlets or moving busy shardlets to new or less utilized shards.

概念と主な機能Concepts & key features

  • お客様側でホストされるサービスCustomer-hosted services

    Split-Merge は、お客様側でホストされるサービスとして提供されます。The split-merge is delivered as a customer-hosted service. このサービスは、Microsoft Azure サブスクリプション内でデプロイし、ホストする必要があります。You must deploy and host the service in your Microsoft Azure subscription. NuGet からダウンロードするパッケージには構成テンプレートが含まれていて、これに特定のデプロイの情報を入力します。The package you download from NuGet contains a configuration template to complete with the information for your specific deployment. 詳細については、「 Elastic Scale の分割とマージ サービス チュートリアル 」を参照してください。See the split-merge tutorial for details. このサービスは Azure サブスクリプション内で実行されるため、サービスのセキュリティに関するほとんどの側面を制御および構成できます。Since the service runs in your Azure subscription, you can control and configure most security aspects of the service. 既定のテンプレートには、SSL、証明書ベースのクライアント認証、保存された資格情報の暗号化、DoS 対策、IP 制限を構成するためのオプションが含まれています。The default template includes the options to configure SSL, certificate-based client authentication, encryption for stored credentials, DoS guarding and IP restrictions. セキュリティの側面については、「 Elastic Scale のセキュリティの構成」を参照してください。You can find more information on the security aspects in the following document split-merge security configuration.

    既定では、デプロイされたサービスは、1 つの worker ロールと 1 つの Web ロールを使用して実行されます。The default deployed service runs with one worker and one web role. それぞれは、Azure Cloud Services の A1 VM サイズを使用します。Each uses the A1 VM size in Azure Cloud Services. これらの設定は、パッケージをデプロイするときに変更することはできませんが、実行中のクラウド サービスへのデプロイが成功した後に (Azure ポータルを通じて) 変更することができます。While you cannot modify these settings when deploying the package, you could change them after a successful deployment in the running cloud service, (through the Azure portal). 技術的な理由により、複数のインスタンスに worker ロールを構成しないでください。Note that the worker role must not be configured for more than a single instance for technical reasons.

  • シャード マップの統合Shard map integration

    Split-Merge サービスは、アプリケーションのシャード マップと対話します。The split-merge service interacts with the shard map of the application. Split-Merge サービスを使用して範囲を分割またはマージしたり、シャードレットをシャード間で移動したりするとき、サービスによってシャード マップが自動的に最新の状態に保たれます。When using the split-merge service to split or merge ranges or to move shardlets between shards, the service automatically keeps the shard map up-to-date. これを実現するために、サービスは、アプリケーションのシャード マップ マネージャー データベースに接続し、分割/マージ/移動要求の進行に伴って範囲とマッピングを管理します。To do so, the service connects to the shard map manager database of the application and maintains ranges and mappings as split/merge/move requests progress. これにより、Split-Merge 操作が実行されているときにシャード マップが常に最新の状態を示すことが保証されます。This ensures that the shard map always presents an up-to-date view when split-merge operations are going on. 分割、マージ、およびシャードレットの移動操作は、シャードレットのバッチをソース シャードからターゲット シャードに移動することによって実装されます。Split, merge and shardlet movement operations are implemented by moving a batch of shardlets from the source shard to the target shard. シャードレットの移動操作中、現在のバッチの対象のシャードレットは、シャード マップ内でオフラインとしてマークされ、 OpenConnectionForKey API を使用したデータ依存ルーティング接続に使用できなくなります。During the shardlet movement operation the shardlets subject to the current batch are marked as offline in the shard map and are unavailable for data-dependent routing connections using the OpenConnectionForKey API.

  • 一貫性のあるシャードレットの接続Consistent shardlet connections

    シャードレットの新しいバッチのデータの移動が開始されると、シャードレットを格納しているシャードへの、シャード マップによって提供されるすべてのデータ依存ルーティング接続が強制終了されます。さらに不整合を回避するために、データの移動操作中は、シャード マップ API からのシャードレットへの後続の接続がブロックされます。When data movement starts for a new batch of shardlets, any shard-map provided data-dependent routing connections to the shard storing the shardlet are killed and subsequent connections from the shard map APIs to the shardlets are blocked while the data movement is in progress in order to avoid inconsistencies. 同じシャード上の他のシャードレットへの接続も強制終了されますが、再試行すると成功します。Connections to other shardlets on the same shard will also get killed, but will succeed again immediately on retry. バッチが移動されると、シャードレットがターゲット シャードに対して再びオンラインとしてマークされ、ソース データがソース シャードから削除されます。Once the batch is moved, the shardlets are marked online again for the target shard and the source data is removed from the source shard. すべてのシャードレットが移動されるまで、すべてのバッチに対してこの手順が実行されます。The service goes through these steps for every batch until all shardlets have been moved. これにより、完全な移動/分割/マージ操作の進行中に接続の強制終了操作が複数回実行されることになります。This will lead to several connection kill operations during the course of the complete split/merge/move operation.

  • シャードレットの可用性の管理Managing shardlet availability

    前述のように、接続の強制終了をシャードレットの現在のバッチに制限すると、使用不可能となるシャードレットのスコープが一度に 1 つのバッチに限定されます。Limiting the connection killing to the current batch of shardlets as discussed above restricts the scope of unavailability to one batch of shardlets at a time. これは、分割/マージ操作の進行中にすべてのシャードレットに対してシャード全体がオフラインになるような方法よりも好ましいアプローチです。This is preferred over an approach where the complete shard would remain offline for all its shardlets during the course of a split or merge operation. 一度に移動する個別のシャードレットの数として定義されるバッチのサイズは、1 つの構成パラメーターです。The size of a batch, defined as the number of distinct shardlets to move at a time, is a configuration parameter. これは、アプリケーションの可用性とパフォーマンスのニーズに応じて分割/マージ操作ごとに定義できます。It can be defined for each split and merge operation depending on the application’s availability and performance needs. シャード マップでロックされている範囲は、指定されたバッチ サイズよりも大きくなる場合があります。Note that the range that is being locked in the shard map may be larger than the batch size specified. これは、サービスによって、データ内のシャーディング キー値の実際の数がバッチ サイズとほぼ一致するように範囲のサイズが選択されるためです。This is because the service picks the range size such that the actual number of sharding key values in the data approximately matches the batch size. これは、シャーディング キー値の数がスパースな場合に関して特に覚えておく必要があります。This is important to remember in particular for sparsely populated sharding keys.

  • メタデータのストレージMetadata storage

    Split-Merge サービスは、データベースを使用して、その状態を管理し、要求処理中のログを保持します。The split-merge service uses a database to maintain its status and to keep logs during request processing. ユーザーは、サブスクリプションにこのデータベースを作成し、このデータベースの接続文字列をサービス デプロイの構成ファイルに指定します。The user creates this database in their subscription and provides the connection string for it in the configuration file for the service deployment. ユーザーの組織の管理者も、要求の進行状況を確認したり、潜在的な障害に関する詳細な情報を調べたりするために、このデータベースに接続できます。Administrators from the user’s organization can also connect to this database to review request progress and to investigate detailed information regarding potential failures.

  • シャーディング対応Sharding-awareness

    Split-Merge サービスでは、(1) シャード化テーブル、(2) 参照テーブル、(3) 通常のテーブルが区別されます。The split-merge service differentiates between (1) sharded tables, (2) reference tables, and (3) normal tables. 移動/分割/マージ操作のセマンティクスは、使用されるテーブルの種類によって異なり、次のように定義されます。The semantics of a split/merge/move operation depend on the type of the table used and are defined as follows:

    • シャード化されたテーブルSharded tables

      分割/マージ/移動操作により、ソース シャードからターゲット シャードにシャードレットが移動されます。Split, merge, and move operations move shardlets from source to target shard. 要求全体が正常に完了した後、これらのシャードレットはソース上に存在しません。After successful completion of the overall request, those shardlets are no longer present on the source. ターゲット テーブルは、ターゲット シャード上に存在する必要があり、操作の処理の前にターゲット範囲にデータが含まれていてはいけません。Note that the target tables need to exist on the target shard and must not contain data in the target range prior to processing of the operation.

    • 参照テーブルReference tables

      参照テーブルの場合、分割/マージ/移動操作により、ソース シャードからターゲット シャードにデータがコピーされます。For reference tables, the split, merge and move operations copy the data from the source to the target shard. ただし、ターゲット上のテーブルに行が存在する場合、このテーブルのターゲット シャード上で変更はしません。Note, however, that no changes occur on the target shard for a given table if any row is already present in this table on the target. 参照テーブルのコピー操作を処理するには、テーブルが空になっている必要があります。The table has to be empty for any reference table copy operation to get processed.

    • その他のテーブルOther Tables

      その他のテーブルは、分割/マージ操作のソースまたはターゲットのどちらかに存在することができます。Other tables can be present on either the source or the target of a split and merge operation. Split-Merge サービスでは、すべてのデータの移動またはコピー操作に関してこれらのテーブルは無視されます。The split-merge service disregards these tables for any data movement or copy operations. ただし、制約がある場合にこれらのテーブルが操作を妨げる可能性があることに注意してください。Note, however, that they can interfere with these operations in case of constraints.

      参照テーブルとシャード化テーブルに関する情報は、シャード マップの SchemaInfo API によって提供されます。The information on reference vs. sharded tables is provided by the SchemaInfo APIs on the shard map. 次の例では、特定のシャード マップ マネージャー オブジェクトでこれらの API を使用しています。The following example illustrates the use of these APIs on a given shard map manager object:

      // Create the schema annotations
      SchemaInfo schemaInfo = new SchemaInfo();
      
      // Reference tables
      schemaInfo.Add(new ReferenceTableInfo("dbo", "region"));
      schemaInfo.Add(new ReferenceTableInfo("dbo", "nation"));
      
      // Sharded tables
      schemaInfo.Add(new ShardedTableInfo("dbo", "customer", "C_CUSTKEY"));
      schemaInfo.Add(new ShardedTableInfo("dbo", "orders", "O_CUSTKEY"));
      // Publish
      smm.GetSchemaInfoCollection().Add(Configuration.ShardMapName, schemaInfo);
      

      'region' テーブルと 'nation' テーブルは参照テーブルとして定義されており、分割/マージ/移動の各操作によってコピーされます。The tables ‘region’ and ‘nation’ are defined as reference tables and will be copied with split/merge/move operations. 一方、'customer' と 'orders' は共有テーブルとして定義されています。‘customer’ and ‘orders’ in turn are defined as sharded tables. C_CUSTKEYO_CUSTKEY はシャーディング キーとして機能します。C_CUSTKEY and O_CUSTKEY serve as the sharding key.

  • 参照整合性Referential Integrity

    Split-Merge サービスは、テーブル間の依存関係を分析し、外部キーと主キーのリレーションシップを使用して、参照テーブルとシャードレットを移動する操作をステージングします。The split-merge service analyzes dependencies between tables and uses foreign key-primary key relationships to stage the operations for moving reference tables and shardlets. 一般に、最初に参照テーブルが依存関係の順にコピーされ、次にシャードレットが各バッチ内での依存関係の順にコピーされます。In general, reference tables are copied first in dependency order, then shardlets are copied in order of their dependencies within each batch. これは、新しいデータが到着するときにターゲット シャード上の外部キーと主キーの制約が適用されるために必要な操作です。This is necessary so that FK-PK constraints on the target shard are honored as the new data arrives.

  • シャード マップの整合性と最終的な完了Shard Map Consistency and Eventual Completion

    エラーの場合、Split-Merge サービスは停止後に操作を再開して、進行中の要求を完了しようとします。In the presence of failures, the split-merge service resumes operations after any outage and aims to complete any in progress requests. ただし、ターゲット シャードが失われた場合や、修復できないほど危害を受けている場合など、回復できない状況もあります。However, there may be unrecoverable situations, e.g., when the target shard is lost or compromised beyond repair. このような状況では、移動されたと考えられるシャードレットがソース シャード上に残されたままになる場合があります。Under those circumstances, some shardlets that were supposed to be moved may continue to reside on the source shard. このサービスでは、必要なデータがターゲットに正常にコピーされた後でのみシャードレット マッピングが更新されることが保証されます。The service ensures that shardlet mappings are only updated after the necessary data has been successfully copied to the target. ソース上のシャードレットは、すべてのデータがターゲットにコピーされ、対応するマッピングが正常に更新された後で削除されます。Shardlets are only deleted on the source once all their data has been copied to the target and the corresponding mappings have been updated successfully. 削除操作は、ターゲット シャード上で範囲が既にオンラインになっているときにバックグラウンドで実行されます。The deletion operation happens in the background while the range is already online on the target shard. Split-Merge サービスでは、シャード マップに格納されているマッピングの正確性が常に保証されます。The split-merge service always ensures correctness of the mappings stored in the shard map.

Split-Merge のユーザー インターフェイスThe split-merge user interface

Split-Merge サービス パッケージには、worker ロールと Web ロールが含まれます。The split-merge service package includes a worker role and a web role. Web ロールは、対話的に Split-Merge 要求を送信するために使用します。The web role is used to submit split-merge requests in an interactive way. ユーザー インターフェイスの主要なコンポーネントは、次のとおりです。The main components of the user interface are as follows:

  • 操作の種類Operation Type

    オプション ボタンを使用して、この要求に対してサービスによって実行される操作の種類を制御します。The operation type is a radio button that controls the kind of operation performed by the service for this request. 分割、マージ、および移動のシナリオから選択することができます。You can choose between the split, merge and move scenarios. また、以前に送信した操作を取り消すこともできます。You can also cancel a previously submitted operation. 範囲シャード マップに分割/マージ/移動要求を使用できます。You can use split, merge and move requests for range shard maps. リスト シャード マップは、移動操作のみをサポートしています。List shard maps only support move operations.

  • シャード マップShard Map

    要求パラメーターの次のセクションでは、シャード マップと、シャード マップをホストするデータベースに関する情報を指定します。The next section of request parameters covers information about the shard map and the database hosting your shard map. 具体的には、Azure SQL Database サーバーの名前、シャード マップをホストするデータベース、シャード マップ データベースに接続するための資格情報、および最後にシャード マップの名前を指定する必要があります。In particular, you need to provide the name of the Azure SQL Database server and database hosting the shardmap, credentials to connect to the shard map database, and finally the name of the shard map. 現時点では、1 つの資格情報のセットのみを指定できます。Currently, the operation only accepts a single set of credentials. これらの資格情報には、シャード上のユーザー データだけでなく、シャード マップに対する変更を実行するための十分な権限が与えられている必要があります。These credentials need to have sufficient permissions to perform changes to the shard map as well as to the user data on the shards.

  • ソースの範囲 (分割/マージ)Source Range (split and merge)

    分割とマージ操作は、低値キーと高値キーを使用して範囲を処理します。A split and merge operation processes a range using its low and high key. 無制限の高値キーで操作を指定するには、「高キーは最大」チェックボックスをオンにして、高値キーフィールドを空のままにしておきます。To specify an operation with an unbounded high key value, check the “High key is max” check box and leave the high key field empty. 指定する範囲のキー値はシャード マップ内のマッピングと境界に正確に一致する必要はありません。The range key values that you specify do not need to precisely match a mapping and its boundaries in your shard map. 範囲の境界を全く指定しない場合は、サービスは自動的に最も近い範囲を推論します。If you do not specify any range boundaries at all the service will infer the closest range for you automatically. GetMappings.ps1 PowerShell スクリプトを使用すると、特定のシャード マップの現在のマッピングを取得できます。You can use the GetMappings.ps1 PowerShell script to retrieve the current mappings in a given shard map.

  • ソースの分割動作 (分割)Split Source Behavior (split)

    分割操作の場合は、ソースの範囲を分割するポイントを定義します。For split operations, define the point to split the source range. そのためには、分割操作を行うシャーディング キーを指定します。You do this by providing the sharding key where you want the split to occur. オプション ボタンを使用して、範囲の前半 (分割キーを除きます) と後半 (分割キーを含みます) のどちらを移動するかを指定します。Use the radio button specify whether you want the lower part of the range (excluding the split key) to move, or whether you want the upper part to move (including the split key).

  • ソース シャードレット (移動)Source Shardlet (move)

    移動操作は、ソースを示す範囲を必要としない点で、分割操作またはマージ操作とは異なります。Move operations are different from split or merge operations as they do not require a range to describe the source. 移動対象のソースは、移動しようとしているシャーディング キーの値によって識別されます。A source for move is simply identified by the sharding key value that you plan to move.

  • ターゲット シャード (分割)Target Shard (split)

    分割操作のソースに関する情報を指定した場合は、ターゲットの Azure SQL DB サーバーとデータベース名を指定してデータのコピー先を定義する必要があります。Once you have provided the information on the source of your split operation, you need to define where you want the data to be copied to by providing the Azure SQL Db server and database name for the target.

  • ターゲットの範囲 (マージ)Target Range (merge)

    マージ操作は、シャードレットを既存のシャードに移動します。Merge operations move shardlets to an existing shard. マージする既存の範囲の範囲境界を指定して既存のシャードを識別します。You identify the existing shard by providing the range boundaries of the existing range that you want to merge with.

  • バッチ サイズBatch Size

    バッチ サイズは、データ移動中に一度にオフライン化されるシャードレットの数を制御します。The batch size controls the number of shardlets that will go offline at a time during the data movement. バッチ サイズは整数値で指定します。シャードレットの長いダウンタイムを避けるには、小さな値を使用します。This is an integer value where you can use smaller values when you are sensitive to long periods of downtime for shardlets. 大きな値を指定すると、特定のシャードレットがオフラインになる時間が長くなりますが、パフォーマンスが向上する場合があります。Larger values will increase the time that a given shardlet is offline but may improve performance.

  • 操作 ID (キャンセル)Operation ID (Cancel)

    実行中の操作が不要になった場合は、対応するフィールドに操作 ID を指定することにより、操作を取り消すことができます。If you have an ongoing operation that is no longer needed, you can cancel the operation by providing its operation ID in this field. 操作 ID は、要求状態テーブル (セクション 8.1 を参照) または要求を送信した Web ブラウザーの出力から取得できます。You can retrieve the operation ID from the request status table (see Section 8.1) or from the output in the web browser where you submitted the request.

要件と制限Requirements and Limitations

Split-Merge サービスの現在の実装には、次の要件と制限が適用されます。The current implementation of the split-merge service is subject to the following requirements and limitations:

  • シャードに対して Split-Merge 操作を実行する前に、シャードが存在し、シャード マップに登録されている必要があります。The shards need to exist and be registered in the shard map before a split-merge operation on these shards can be performed.
  • このサービスは、操作の一部としてテーブルやその他のデータベース オブジェクトを自動的に作成しません。The service does not create tables or any other database objects automatically as part of its operations. これは、分割/マージ/移動操作を開始する前に、ターゲット シャード上にすべてのシャード化テーブルと参照テーブルのスキーマが存在している必要があることを意味します。This means that the schema for all sharded tables and reference tables needs to exist on the target shard prior to any split/merge/move operation. 特に、シャード化テーブルは、移動/分割/マージ操作で新しいシャードレットが追加される範囲内で空になっている必要があります。Sharded tables in particular are required to be empty in the range where new shardlets are to be added by a split/merge/move operation. そうでないと、ターゲット シャードでの初期の整合性チェックで不合格になります。Otherwise, the operation will fail the initial consistency check on the target shard. また、参照データは参照テーブルが空の場合にのみコピーされる点と、参照テーブルに対する他の同時書き込み操作に関して一貫性が保証されない点にも注意してください。Also note that reference data is only copied if the reference table is empty and that there are no consistency guarantees with regard to other concurrent write operations on the reference tables. 分割/マージ操作を実行したときに、参照テーブルに変更を加える他の書き込み操作がないことを確認することをお勧めします。We recommend this: when running split/merge operations, no other write operations make changes to the reference tables.
  • サービスでは、大きなシャードレットのパフォーマンスと信頼性を向上させるために、シャーディング キーを含む一意のインデックスまたはキーで設定される行 ID に依存しています。The service relies on row identity established by a unique index or key that includes the sharding key to improve performance and reliability for large shardlets. これにより、単なるシャーディング キー値よりも細かな粒度でデータを移動できます。This allows the service to move data at an even finer granularity than just the sharding key value. その結果、ログ領域と操作中に必要になるロックの量を削減できます。This helps to reduce the maximum amount of log space and locks that are required during the operation. 移動/分割/マージ要求でテーブルを使用する場合は、シャーディング キーを含む一意のインデックスまたは主キーをテーブルに作成することを検討してください。Consider creating a unique index or a primary key including the sharding key on a given table if you want to use that table with split/merge/move requests. パフォーマンス上の理由により、シャーディング キーは、キーまたはインデックスの先頭の列である必要があります。For performance reasons, the sharding key should be the leading column in the key or the index.
  • 要求の処理の過程で、一部のシャードレット データがソース シャードとターゲット シャードの両方に存在することがあります。During the course of request processing, some shardlet data may be present both on the source and the target shard. これは、シャードレットの移動時のエラーから保護するために必要です。This is necessary to protect against failures during the shardlet movement. Split-Merge とシャード マップの統合により、シャード マップ上で OpenConnectionForKey メソッドを使用するデータ依存ルーティング API を介した接続において、中間状態の一貫性が失われることはありません。The integration of split-merge with the shard map ensures that connections through the data-dependent routing APIs using the OpenConnectionForKey method on the shard map do not see any inconsistent intermediate states. ただし、 OpenConnectionForKey メソッドを使用せずにソース シャードまたはターゲット シャードに接続するときは、移動/分割/マージ要求の実行中に一貫性のない中間状態が発生する可能性があります。However, when connecting to the source or the target shards without using the OpenConnectionForKey method, inconsistent intermediate states might be visible when split/merge/move requests are going on. これらの接続では、タイミングや接続の基になるシャードによって、部分的な結果や重複する結果が生成される可能性があります。These connections may show partial or duplicate results depending on the timing or the shard underlying the connection. 現在、この制限には、Elastic Scale マルチシャード クエリによって確立される接続が含まれます。This limitation currently includes the connections made by Elastic Scale Multi-Shard-Queries.
  • Split-Merge サービスのメタデータ データベースは、異なるロール間では共有できません。The metadata database for the split-merge service must not be shared between different roles. たとえば、ステージング環境で実行されている Split-Merge サービスのロールは、実稼働環境ロールとは異なるメタデータ データベースを指し示す必要があります。For example, a role of the split-merge service running in staging needs to point to a different metadata database than the production role.

課金Billing

Split-Merge サービスは、Microsoft Azure サブスクリプションのクラウド サービスとして実行されます。The split-merge service runs as a cloud service in your Microsoft Azure subscription. そのため、クラウド サービスの料金がサービスのインスタンスに適用されます。Therefore charges for cloud services apply to your instance of the service. 移動/分割/マージ操作を頻繁に実行する場合を除き、Split-Merge クラウド サービスを削除することをお勧めします。Unless you frequently perform split/merge/move operations, we recommend you delete your split-merge cloud service. こうすることで、実行中のまたはデプロイされたクラウド サービス インスタンスに対して発生するコストを削減できます。That saves costs for running or deployed cloud service instances. 分割/マージの操作を実行する必要があるときはいつでも簡単に実行可能な構成を再デプロイして開始することができます。You can re-deploy and start your readily runnable configuration whenever you need to perform split or merge operations.

監視Monitoring

状態テーブルStatus tables

Split-Merge サービスでは、完了した要求と実行中の要求を監視するための RequestStatus テーブルがメタデータ ストア データベースに用意されています。The split-merge Service provides the RequestStatus table in the metadata store database for monitoring of completed and ongoing requests. このテーブルには、この Split-Merge サービスのインスタンスに送信されたそれぞれの Split-Merge 要求データが行として含まれます。The table lists a row for each split-merge request that has been submitted to this instance of the split-merge service. それぞれの要求に対して、次の情報が含まれます。It gives the following information for each request:

  • TimestampTimestamp

    要求が開始されたときの日付と時刻。The time and date when the request was started.

  • OperationIdOperationId

    要求を一意に識別する GUID。A GUID that uniquely identifies the request. この要求を使用して、まだ実行中の操作を取り消すこともできます。This request can also be used to cancel the operation while it is still ongoing.

  • 状態Status

    要求の現在の状態。The current state of the request. 実行中の要求に対しては、要求の現在のフェーズも表示されます。For ongoing requests, it also lists the current phase in which the request is.

  • CancelRequestCancelRequest

    要求が取り消されたかどうかを示すフラグ。A flag that indicates whether the request has been canceled.

  • 進行状況Progress

    推定される操作の進捗状況。A percentage estimate of completion for the operation. 値 50 は、操作が約 50% 完了していることを示します。A value of 50 indicates that the operation is approximately 50% complete.

  • 詳細Details

    詳細な進捗状況レポートを提供する XML 値。An XML value that provides a more detailed progress report. 行のセットがソースからターゲットにコピーされるときに、進捗状況レポートが定期的に更新されます。The progress report is periodically updated as sets of rows are copied from source to target. エラーまたは例外が発生した場合、この列にはエラーに関するより詳細な情報も含まれます。In case of failures or exceptions, this column also includes more detailed information about the failure.

Azure DiagnosticsAzure Diagnostics

Split-Merge サービスは、監視と診断を行うために Azure SDK 2.5 に基づく Azure Diagnostics を使用します。The split-merge service uses Azure Diagnostics based on Azure SDK 2.5 for monitoring and diagnostics. 診断構成を制御する方法については、次の記事で説明されています。Azure Cloud Services と Virtual Machines の診断機能の有効化に関する記事You control the diagnostics configuration as explained here: Enabling Diagnostics in Azure Cloud Services and Virtual Machines. ダウンロード パッケージには、Web ロール用と worker ロール用の 2 つの診断構成が含まれています。The download package includes two diagnostics configurations - one for the web role and one for the worker role. これには、パフォーマンス カウンター、IIS ログ、Windows イベント ログ、および Split-Merge アプリケーション イベント ログを記録するための定義が含まれます。It includes the definitions to log Performance Counters, IIS logs, Windows Event Logs, and split-merge application event logs.

診断のデプロイDeploy Diagnostics

注意

この記事は、新しい Azure PowerShell Az モジュールを使用するために更新されました。This article has been updated to use the new Azure PowerShell Az module. Az モジュールと AzureRM の互換性の詳細については、「Introducing the new Azure PowerShell Az module (新しい Azure PowerShell Az モジュールの概要)」を参照してください。To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. インストール手順については、Azure PowerShell のインストール を参照してください。For installation instructions, see Install Azure PowerShell.

重要

PowerShell Azure Resource Manager モジュールは Azure SQL Database で引き続きサポートされますが、今後の開発はすべて Az.Sql モジュールを対象に行われます。The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. これらのコマンドレットについては、「AzureRM.Sql」を参照してください。For these cmdlets, see AzureRM.Sql. Az モジュールと AzureRm モジュールのコマンドの引数は実質的に同じです。The arguments for the commands in the Az module and in the AzureRm modules are substantially identical.

NuGet パッケージで提供される Web ロール用と worker ロール用の診断構成を使用して、監視と診断を有効にするには、Azure PowerShell を使用して次のコマンドを実行します。To enable monitoring and diagnostics using the diagnostic configuration for the web and worker roles provided by the NuGet package, run the following commands using Azure PowerShell:

    $storage_name = "<YourAzureStorageAccount>"
    $key = "<YourAzureStorageAccountKey"
    $storageContext = New-AzStorageContext -StorageAccountName $storage_name -StorageAccountKey $key  
    $config_path = "<YourFilePath>\SplitMergeWebContent.diagnostics.xml"
    $service_name = "<YourCloudServiceName>"
    Set-AzureServiceDiagnosticsExtension -StorageContext $storageContext -DiagnosticsConfigurationPath $config_path -ServiceName $service_name -Slot Production -Role "SplitMergeWeb"
    $config_path = "<YourFilePath>\SplitMergeWorkerContent.diagnostics.xml"
    $service_name = "<YourCloudServiceName>"
    Set-AzureServiceDiagnosticsExtension -StorageContext $storageContext -DiagnosticsConfigurationPath $config_path -ServiceName $service_name -Slot Production -Role "SplitMergeWorker"

診断設定を構成してデプロイする方法の詳細については、次の記事で説明されています:Azure Cloud Services と Virtual Machines の診断機能の有効化に関する記事You can find more information on how to configure and deploy diagnostics settings here: Enabling Diagnostics in Azure Cloud Services and Virtual Machines.

診断の取得Retrieve diagnostics

診断には、Visual Studio サーバー エクスプローラーのサーバー エクスプローラー ツリーの Azure の部分から簡単にアクセスできます。You can easily access your diagnostics from the Visual Studio Server Explorer in the Azure part of the Server Explorer tree. Visual Studio インスタンスを開き、メニュー バーで [ビュー]、[サーバー エクスプローラー] の順にクリックします。Open a Visual Studio instance, and in the menu bar click View, and Server Explorer. Azure のアイコンをクリックして Azure サブスクリプションに接続します。Click the Azure icon to connect to your Azure subscription. 次に、Azure、[ストレージ]、[<your storage account>]、[テーブル]、[WADLogsTable] の順に移動します。Then navigate to Azure -> Storage -> <your storage account> -> Tables -> WADLogsTable. 詳しくは、「Server Explorer」(サーバー エクスプローラー) をご覧ください。For more information, see Server Explorer.

WADLogsTable

上の図で強調表示されている WADLogsTable には、Split-Merge サービスのアプリケーション ログからの詳細なイベントが含まれています。The WADLogsTable highlighted in the figure above contains the detailed events from the split-merge service’s application log. ダウンロードしたパッケージの既定の構成は、運用環境のデプロイを対象にしていることに注意してください。Note that the default configuration of the downloaded package is geared towards a production deployment. そのため、サービス インスタンスからログおよびカウンターが取得される間隔が長くなっています (5 分)。Therefore the interval at which logs and counters are pulled from the service instances is large (5 minutes). テストと開発用には、Web ロールまたは worker ロールの診断設定をニーズに合わせて調整して、間隔を短くすることができます。For test and development, lower the interval by adjusting the diagnostics settings of the web or the worker role to your needs. Visual Studio サーバー エクスプローラー (上図参照) でロールを右クリックし、[診断構成] ダイアログ ボックスで、[転送間隔] の値を調整します。Right-click on the role in the Visual Studio Server Explorer (see above) and then adjust the Transfer Period in the dialog for the Diagnostics configuration settings:

構成

パフォーマンスPerformance

一般に、Azure SQL Database の上位のより高パフォーマンスのサービス階層ほど、より高いパフォーマンスを期待できます。In general, better performance is to be expected from the higher, more performant service tiers in Azure SQL Database. 上位のサービス階層で提供されるより優れた IO、CPU、およびメモリ割り当ては、Split-Merge サービスが使用する一括コピーおよび削除操作に役立ちます。Higher IO, CPU and memory allocations for the higher service tiers benefit the bulk copy and delete operations that the split-merge service uses. そのため、定義された一定期間のデータベースに対してのみサービス階層を増やします。For that reason, increase the service tier just for those databases for a defined, limited period of time.

サービスでは、検証クエリが通常の操作の一部としても実行されます。The service also performs validation queries as part of its normal operations. 検証クエリは、ターゲット範囲に想定外のデータが存在していないことを確認して、すべての分割/マージ/移動操作が一貫性のある状態で開始されることを保証します。These validation queries check for unexpected presence of data in the target range and ensure that any split/merge/move operation starts from a consistent state. これらのクエリは、操作のスコープと要求の定義の一部として提供されたバッチ サイズによって定義されたシャーディング キー範囲に作用します。These queries all work over sharding key ranges defined by the scope of the operation and the batch size provided as part of the request definition. これらのクエリは、先頭の列にシャーディング キーを含むインデックスがあるときに最高のパフォーマンスを発揮します。These queries perform best when an index is present that has the sharding key as the leading column.

さらに、先頭の列にシャーディング キーを含む一意性プロパティにより、サービスは、ログ領域とメモリに関してリソースの消費を制限する最適化されたアプローチを使用できます。In addition, a uniqueness property with the sharding key as the leading column will allow the service to use an optimized approach that limits resource consumption in terms of log space and memory. (一般的に 1 GB 以上の) 大きなサイズのデータを移動するには、この一意性プロパティが必要です。This uniqueness property is required to move large data sizes (typically above 1GB).

アップグレードする方法How to upgrade

  1. Split-Merge サービスのデプロイ」の手順に従います。Follow the steps in Deploy a split-merge service.
  2. Split-Merge のデプロイ用のクラウド サービス構成ファイルを変更して、新しい構成パラメーターを反映します。Change your cloud service configuration file for your split-merge deployment to reflect the new configuration parameters. 新しい必須のパラメーターは、暗号化に使用される証明書に関する情報です。A new required parameter is the information about the certificate used for encryption. これを簡単に行うには、ダウンロードした新しい構成テンプレート ファイルを既存の構成と比較します。An easy way to do this is to compare the new configuration template file from the download against your existing configuration. Web ロールと worker ロールの「DataEncryptionPrimaryCertificateThumbprint」と「DataEncryptionPrimary」に、必ず設定を追加するようにしてください。Make sure you add the settings for “DataEncryptionPrimaryCertificateThumbprint” and “DataEncryptionPrimary” for both the web and the worker role.
  3. Azure に更新をデプロイする前に、現在実行中のすべての Split-Merge 操作が完了していることを確認します。Before deploying the update to Azure, ensure that all currently running split-merge operations have finished. これは、実行中の要求の Split-Merge メタデータのデータベースで RequestStatus と PendingWorkflows テーブルを照会することで簡単に行えます。You can easily do this by querying the RequestStatus and PendingWorkflows tables in the split-merge metadata database for ongoing requests.
  4. 新しいパッケージと更新されたサービス構成ファイルで、Azure サブスクリプションの Split-Merge の既存のクラウド サービスのデプロイを更新します。Update your existing cloud service deployment for split-merge in your Azure subscription with the new package and your updated service configuration file.

アップグレードするために Split-Merge の新しいメタデータ データベースをプロビジョニングする必要はありません。You do not need to provision a new metadata database for split-merge to upgrade. 新しいバージョンは、既存のメタデータ データベースを新しいバージョンに自動的にアップグレードします。The new version will automatically upgrade your existing metadata database to the new version.

ベスト プラクティスとトラブルシューティングBest practices & troubleshooting

  • テスト テナントを定義し、複数のシャードにまたがるテスト テナントで最も重要な分割/マージ/移動操作を実行します。Define a test tenant and exercise your most important split/merge/move operations with the test tenant across several shards. すべてのメタデータが適切にシャード マップ内に定義され、操作が制約または外部キーに違反しないことを確認できます。Ensure that all metadata is defined correctly in your shard map and that the operations do not violate constraints or foreign keys.
  • データ サイズに関連する問題が発生するのを防ぐには、テスト テナントのデータのサイズを、最大のテナントの最大データ サイズよりも大きく保ちます。Keep the test tenant data size above the maximum data size of your largest tenant to ensure you are not encountering data size related issues. これは、1 つのテナントの移動にかかる時間の上限を評価する場合にも役立ちます。This helps you assess an upper bound on the time it takes to move a single tenant around.
  • スキーマで削除が許可されることを確認します。Make sure that your schema allows deletions. Split-Merge サービスを使用するには、データがターゲットに正常にコピーされた後でソース シャードからデータを削除できる必要があります。The split-merge service requires the ability to remove data from the source shard once the data has been successfully copied to the target. たとえば、 トリガーを削除する と、サービスがソースのデータを削除できなくなり、操作が失敗することがあります。For example, delete triggers can prevent the service from deleting the data on the source and may cause operations to fail.
  • シャーディング キーが主キーまたは一意のインデックスの定義の先頭の列であることを確認します。The sharding key should be the leading column in your primary key or unique index definition. これにより、分割/マージ検証クエリと、シャーディング キー範囲に常に作用する実際のデータの移動と削除操作の最善のパフォーマンスが保証されます。That ensures the best performance for the split or merge validation queries, and for the actual data movement and deletion operations which always operate on sharding key ranges.
  • データベースが配置されているリージョンとデータ センターに Split-Merge サービスを併置します。Collocate your split-merge service in the region and data center where your databases reside.

その他のリソース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.