次の方法で共有

Azure SQL データ同期のベスト プラクティス

  • [アーティクル]

適用対象: Azure SQL データベース

重要

SQL データ同期 は、2027 年 9 月 30 日に廃止される予定です。 代替のデータ レプリケーション/同期ソリューションへの移行を検討してください。

この記事では、Azure SQL データ同期のベスト プラクティスについて説明します。

SQL データ同期の概要については、「Azure のSQL データ同期とは?」を参照してください。

セキュリティと信頼性

クライアント エージェント

  • ネットワーク サービスのアクセス許可を持つ最低限必要な特権ユーザー アカウントを使用して、クライアント エージェントをインストールします。
  • SQL Server がインストールされているサーバーとは異なるサーバーに、クライアント エージェントをインストールします。
  • オンプレミス データベースを複数のエージェントに登録しないでください。
    • これは、同期グループが異なるさまざまなテーブルを同期する場合でも、行わないでください。
    • オンプレミス データベースを複数のクライアント エージェントに登録すると、同期グループのいずれかを削除したときに問題が発生します。

最低限必要な特権が付与されたデータベース アカウント

  • 同期のセットアップの場合:

    • SQL Server アクセス許可: CREATE/ALTER TABLE、ALTER DATABASE、CREATE PROCEDURE、SELECT/ALTER SCHEMA、CREATE TYPE。 これらのアクセス許可は、組み込みのデータベース ロール ddl_admin に (他のアクセス許可と共に) 含まれます。
    • リソース グループ レベルでは、SQL DB 共同作成者ロールのメンバーシップが必要です。 詳細については、Azure portal を使用して Azure ロールを割り当てる方法に関するページを参照してください。 共同作成者や所有者などのより広範なロールのメンバーシップも、既に割り当てられている場合は機能します。
    • サブスクリプション レベルのアクセス許可は必要ありませんが、サブスクリプションの複数の Azure Data Sync 実装に必要なアクセス許可を与える簡単な方法 (ただし、"最小限必須" ではない) を提供できることがあります。 非推奨の元の API では、これらの Azure RBAC アクセス許可が必要でしたが、使用できなくなりました。
      • "Microsoft.Sql/locations/syncMemberOperationResults/read"
      • "Microsoft.Sql/locations/syncAgentOperationResults/read"
      • "Microsoft.Sql/locations/syncGroupOperationResults/read"

  • 継続的な同期。

    • SQL Server アクセス許可: 同期で選択されたユーザー テーブルの SELECT、INSERT、UPDATE、DELETE アクセス許可。 ユーザー定義テーブル形の EXECUTE アクセス許可。
    • SQL Server アクセス許可: 同期メタデータとシステム作成追跡テーブルの SELECT、INSERT、UPDATE、DELETE アクセス許可。 サービスによって作成されたストアド プロシージャの EXECUTE アクセス許可。
      • DataSync スキーマは、ハブおよびメンバー データベースのシステム作成オブジェクトに使用されます。
      • dss スキーマと TaskHosting スキーマは、同期メタデータ データベースのシステム作成オブジェクトに使用されます。

  • プロビジョニング解除。

    • SQL Server アクセス許可: 同期のあらゆるテーブル部分の ALTER、同期メタデータ テーブルの SELECT と DELETE、同期追跡テーブル、ストアド プロシージャ、ユーザー定義型の CONTROL。
    • クリーンアップの場合、DataSync、dss、TaskHosting スキーマのシステム作成オブジェクトを削除します。

Azure SQL Database では、単一の資格情報セットのみをサポートしています。 この制約内でこれらのタスクを行うため、次のオプションを検討してください。

  • フェーズごとに資格情報を変更します (たとえば、セットアップには credentials1 を使用し、継続的な同期には credentials2 を使用します)。
  • 資格情報のアクセス許可を変更します (つまり、同期の設定後にアクセス許可を変更します)。

監査

同期グループ内のデータベース レベルで監査を有効にすることをお勧めします。 Azure SQL データベースの監査を有効にする方法、またはSQL Server データベースの監査を有効にする方法について説明します。

セットアップ

データベースの考慮事項と制約

データベース サイズ

新しいデータベースを作成するときは、デプロイするデータベースよりも常に大きいサイズになるように最大サイズを設定します。 デプロイするデータベースより大きい最大サイズを設定していない場合、同期は失敗します。 SQL データ同期では自動拡張が行われませんが、ALTER DATABASE コマンドを実行して、作成後にデータベースのサイズを増やすことができます。 データベースのサイズが確実に制限を超えないようにしてください。

重要

SQL データ同期では、各データベースで追加のメタデータを格納します。 必要な領域を計算するときに、このメタデータを必ず考慮してください。 追加されるオーバーヘッドの量は、テーブルの幅 (たとえば、幅が狭いテーブルでは必要なオーバーヘッドが増えます) とトラフィックの量に関係しています。

テーブルの考慮事項と制約

テーブルを選択する

データベース内のすべてのテーブルを同期グループに含める必要はありません。 同期グループに含めるテーブルは、効率性とコストに影響します。 業務上必要な場合のみ、テーブルと、そのテーブルが依存しているテーブルを同期グループに含めます。

主キー

同期グループ内の各テーブルには主キーが必要です。 SQL データ同期は、主キーを持たないテーブルと同期できません。

運用環境で SQL データ同期を使用する前に、初期同期と継続的な同期のパフォーマンスをテストしてください。

空のテーブルが最高のパフォーマンスを提供する

初期化時には空のテーブルが最高のパフォーマンスを提供します。 ターゲット テーブルが空の場合、データ同期は一括挿入を使用してデータを読み込みます。 それ以外の場合、データ同期は行単位の比較と挿入を行って競合を確認します。 ただし、パフォーマンスが重要でない場合は、既にデータが含まれているテーブル間の同期を設定することができます。

同期先データベースのプロビジョニング

SQL データ同期は、データベースの基本的な自動プロビジョニングを提供します。

このセクションでは、SQL データ同期のプロビジョニングの制限事項について説明します。

自動プロビジョニングの制限事項

SQL データ同期には、自動プロビジョニングについて次のような制限事項があります。

  • 選択できるのは同期先テーブルに作成された列のみです。 同期グループに含まれていない列はすべて、同期先テーブルにプロビジョニングされません。
  • 選択した列のインデックスだけが作成されます。 同期元テーブルのインデックスに同期グループに含まれていない列がある場合、それらのインデックスは同期先テーブルにプロビジョニングされません。
  • XML 型の列のインデックスはプロビジョニングされません。
  • データ同期では、次の 2 つのインデックス プロパティのみがサポートされています: Unique、Clustered/Non-Clustered。 IGNORE_DUP_KEY、Where フィルター述語など、インデックスのその他のプロパティはサポートされておらず、ソース インデックスでこれらのプロパティが設定されていても、同期先インデックスはこれらのプロパティなしでプロビジョニングされます。
  • CHECK 制約はプロビジョニングされません。
  • 同期元テーブルの既存のトリガーはプロビジョニングされません。
  • ビューとストアド プロシージャは同期先データベースに作成されません。
  • 外部キー制約の UPDATE CASCADE および ON DELETE CASCADE アクションは、同期先テーブルに再作成されません。
  • 精度が 28 を超える decimal 列または numeric 列がある場合、SQL データ同期で同期中に変換オーバーフローの問題が発生する可能性があります。decimal 列または numeric 列の精度を 28 以下に制限することをお勧めします。

推奨事項

  • サービスをテストする場合にのみ、SQL データ同期の自動プロビジョニング機能を使用します。
  • 運用環境では、データベース スキーマをプロビジョニングします。

ハブ データベースを配置する場所

企業とクラウド間のシナリオ

待機時間を最小限に抑えるために、同期グループのデータベース トラフィックが最も集中する場所の近くにハブ データベースを保持します。

クラウド間のシナリオ

  • 同期グループのすべてのデータベースが 1 つのデータセンターにある場合は、同じデータセンターにハブを配置します。 この構成により、待機時間と、データセンター間でのデータ転送のコストが削減されます。
  • 同期グループのデータベースが複数のデータセンターにある場合は、大多数のデータベースおよびデータベース トラフィックと同じデータセンターにハブを配置します。

混合シナリオ

企業とクラウドの間のシナリオと、クラウド間のシナリオが混在している場合など、複雑な同期グループ構成になっている場合に、上記のガイドラインを適用します。

同期

時間とコストがかかる初期同期の回避

このセクションでは、同期グループの初期同期について説明します。 初期同期に余計な時間がかかったり、必要以上にコストがかかったりしないようにする方法を説明します。

初期同期のしくみ

同期グループを作成する場合、最初は 1 つのデータベースのデータだけを使用します。 複数のデータベースにデータがあると、SQL データ同期は、解決が必要な競合としてそれぞれの行を扱います。 この競合の解決のために、初期同期に時間がかかります。 複数のデータベースにデータがあると、データベースのサイズによって、初期同期に数日や数か月かかる場合があります。

複数のデータベースが別々のデータセンターにある場合、それぞれの行が異なるデータセンター間を行き来することになります。 これにより、初期同期のコストが増加します。

推奨

可能であれば、最初は同期グループのいずれかのデータベースのデータだけを使用します。

同期ループを避ける設計

同期ループは、同期グループ内で循環参照がある場合に発生します。 このシナリオでは、1 つのデータベースにおける各変更が、同期グループ内の複数のデータベース間で際限なく循環的にレプリケートされます。

パフォーマンスの低下とコストの大幅な増加を引き起こす可能性があるため、必ず同期ループを回避するようにしてください。

反映されない変更

変更が反映されない理由

次のいずれかの原因で、変更が反映されない場合があります。

  • スキーマまたはデータ型に互換性がない。
  • null 非許容列に null 値を挿入している。
  • 外部キー制約に違反している。

変更が反映されないとどうなるか

  • 同期グループが [警告] 状態で表示されます。
  • ポータル UI のログ ビューアーに詳細が表示されます。
  • 45 日経っても問題が解決しない場合、データベースは最新ではなくなります。

Note

これらの変更が反映されることはありません。 このシナリオにおいて回復する唯一の方法は、同期グループを再作成することです。

推奨

ポータルとログ インターフェイスを使用して、同期グループとデータベースの正常性を定期的に監視します。

メンテナンス

データベースと同期グループが古くならないようにする

同期グループまたは同期グループ内のデータベースが最新でなくなる場合があります。 同期グループの状態が [Out-of-date](最新ではありません) の場合、同期グループは機能しなくなります。 データベースの状態が [Out-of-date](最新ではありません) の場合、データが失われる可能性があります。 このシナリオからの回復を試みるよりも、このシナリオを回避することをお勧めします。

データベースが古くならないようにする

データベースが 45 日以上オフラインになっている場合、データベースの状態が [Out-of-date](最新ではありません) に設定されます。 データベースが [Out-of-date](最新ではありません) の状態になることを回避するために、45 日以上オフラインになっているデータベースがないことを確認します。

同期グループが古くならないようにする

同期グループ内での変更が、45 日以上経っても同期グループの残りのデータベースに反映されていない場合、同期グループの状態が [Out-of-date](最新ではありません) に設定されます。 同期グループが [Out-of-date](最新ではありません) の状態になることを回避するために、同期グループの履歴ログを定期的に確認します。 すべての競合が解決され、同期グループのデータベース全体に変更が正常に反映されていることを確認します。

次のいずれかの原因で、同期グループに変更が反映されない場合があります。

  • テーブル間でスキーマに互換性がない。
  • テーブル間でデータに互換性がない。
  • null 値が許可されていない列に、null 値が含まれた行が挿入されている。
  • 外部キー制約に違反する値で行が更新されている。

同期グループが古くなることを防ぐには、次のことを行います。

  • スキーマを更新して、失敗した行に含まれている値を許可します。
  • 外部キーの値を更新して、失敗した行に含まれている値を含めます。
  • 失敗した行のデータ値を更新して、ターゲット データベースのスキーマまたは外部キーと互換性を持たせます。

プロビジョニング解除の問題を回避する

状況によっては、クライアント エージェントへのデータベースの登録を解除すると、同期に失敗することがあります。

シナリオ

  1. SQL データベース インスタンスと、ローカル エージェント 1 に関連付けられている SQL Server データベースを使用して、同期グループ A が作成されました。
  2. 同じオンプレミス データベースがローカル エージェント 2 に登録されています (このエージェントは、どの同期グループにも関連付けられていません)。
  3. ローカル エージェント 2 からオンプレミス データベースの登録を解除すると、オンプレミス データベースの同期グループ A の追跡およびメタ テーブルが削除されます。
  4. 同期グループ A の操作は、"The current operation could not be completed because the database is not provisioned for sync or you do not have permissions to the sync configuration tables" (データベースが同期用にプロビジョニングされていないか、同期構成テーブルへのアクセス許可がないため、現在の操作を完了できませんでした) というエラーが表示されて失敗します。

解決策

このシナリオを回避するには、1 つのデータベースを複数のエージェントに登録しないようにします。

このシナリオから回復するには、次の手順に従います。

  1. データベースが属している各同期グループからデータベースを削除します。
  2. データベースを削除した各同期グループにデータベースを戻します。
  3. 影響を受けた各同期グループをデプロイします (この操作によりデータベースをプロビジョニングします)。

同期グループの変更

同期グループからデータベースを削除した後、変更のいずれかをデプロイするまで同期グループを編集しないでください。

その代わりにまず、同期グループからデータベースを削除します。 次に、この変更をデプロイし、プロビジョニング解除が完了するまで待ちます。 プロビジョニング解除が完了したら、同期グループを編集して変更をデプロイできます。

データベースを削除した後、変更のいずれかをデプロイする前に同期グループを編集すると、いずれか一方の操作が失敗します。 ポータルのインターフェイスが不整合な状態になる場合があります。 その場合は、ページを更新することで正しい状態を復元できます。

スキーマ更新のタイムアウトを回避する

複雑なスキーマを同期する場合、同期メタデータ データベースの SKU が低いと (例: Basic)、スキーマ更新時に「操作のタイムアウト」が発生する可能性があります。

解決策

この問題を軽減するには、同期メタデータ データベース リソースのスケールアップを検討してください。

関連するコンテンツ

SQL データ同期の詳細については、以下を参照してください。

SQL Database の詳細については、以下をご覧ください。