マネージド ディザスター リカバリー

マネージド ディザスター リカバリー (DR) は、リージョンの障害から数分で復旧できるように、Azure Databricksデプロイをセカンダリ リージョンにレプリケートします。 Azure Databricksは、レプリケーション パイプライン、セカンダリ内のレプリケートされたカタログの状態、およびフェールオーバー プロセスを管理します。 レプリケーション スクリプトの作成や保守は行いません。

一般的な DR の概念やベスト プラクティスなど、ディザスター リカバリーに対する手動アプローチについては、「 ディザスター リカバリー」を参照してください。

Important

Managed DR は利用が制限されています。 Azure Databricks アカウント チームを通じてアクセスを申請します。 Azure Databricks受け入れられた後、アカウントでマネージド DR を有効にします。

マネージド ディザスター リカバリーとは

マネージド DR は、既に操作しているワークスペースとメタストアの上に配置されます。 2 つのAzure Databricks ワークスペース (プライマリ リージョンに 1 つとセカンダリ リージョンに 1 つ、各リージョンにメタストア) を用意します。 続いて マネージド DR:

  • オプトインしたカテゴリをプライマリからセカンダリへ継続的にレプリケートします。 どちらのカテゴリも、それぞれ独立して任意です。つまり、Unity Catalog のメタデータとマネージド テーブル データ、およびノートブック、ジョブ、SQL ウェアハウス、クラスター、ACL などのワークスペース アセットです。
  • オプションの安定した URL を提供します。これは、常に現在のプライマリを指す単一の接続文字列であるため、クライアントは再構成せずにフェールオーバー後も動作し続けます。
  • DR テスト時や実際の障害発生時に、必要なタイミングでフェールオーバーを実行できるようにします。

ワークスペース資産 ID はリージョン間で保持されるため、ID によってワークスペース資産を参照する URL はフェールオーバー後も解決されます。

レプリケートされる内容

マネージド DR では、レプリケーション サイクルごとに次の内容をレプリケートできます。 どちらのカテゴリも省略可能であるため、次のいずれかまたは両方を有効にすることができます。

  • Unity Catalog のメタデータとデータ: Unity Catalog は、Delta Lake 内のテーブルを管理しており、データ、外部テーブルとボリューム (メタデータのみ)、ビュー、関数、すべてのアクセス許可が含まれます。 カタログの分離モードがレプリケートされます。 ソース カタログが開いている場合、レプリカは開いています。 ソースが分離され、プライマリ ワークスペースにバインドされている場合、レプリカは分離され、セカンダリ ワークスペースにバインドされます。
  • ワークスペース アセット: ノートブック、ジョブ、SQL ウェアハウス、クラスター、AI/BI ダッシュボードの下書き、ファイル、フォルダー、およびそれらの ACL。 SQLウェアハウスはSTOPPED状態で、クラスターはTERMINATED状態でレプリケートされます。 セカンダリのジョブ スケジュールは一時停止されます。

レプリケートされたオブジェクトの所有権

マネージド DR がセカンダリにレプリケートされたセキュリティ保護可能なリソース (カタログ、スキーマ、テーブル、ビュー、関数、またはボリューム) を作成する場合、Unity カタログはオブジェクトを作成する ID に所有権を割り当てるので、初期所有者はレプリケーションを実行するAzure Databricks サービス プリンシパルです。 マネージド DR は、プライマリ内の対応するセキュリティ保護可能なリソースの所有者と一致するようにレプリカの所有権を転送します。

プライマリのセキュリティ保護可能なリソースの所有者がアカウントから削除されたユーザーである場合、マネージド DR は、存在しなくなったプリンシパルに所有権を譲渡できません。 この場合、保護対象のレプリカは、Azure Databricks サービス プリンシパルを所有者として保持します。 これを解決するには、プライマリ側の保護可能オブジェクトに有効な所有者を割り当て、DR へそれをレプリケートさせます。

必要条件

  • プライマリ リージョンとセカンダリ リージョンの両方の Premium プラン 上のワークスペース。
  • 両方のワークスペースで有効になっている Mission Critical ワークスペース アドオン。 両方のワークスペースで Mission Critical を有効にするを参照してください。
  • 両方のワークスペースで有効になっているサーバーレス コンピューティング。 サーバーレス コンピューティングは、ほとんどの Unity カタログ対応ワークスペースで既定で使用できます。 「サーバーレス コンピューティングに接続する」を参照してください。
  • レプリケートする予定のカタログによって使用されるすべての外部の場所に対して 、すべての特権 を持つアカウント管理者ロール。
  • 有効なすべてのワークスペースに対するアカウント レベルの SSO と、SCIM を介してアカウントに同期された ID により、ユーザー、グループ、およびサービス プリンシパルが両方のリージョンに存在します。
  • 安定した URL の場合: Azure Databricks ドメイン用にプロビジョニングされたカスタム URL (アカウント チームに問い合わせる) とアカウント レベルの OAuth。
  • セカンダリ リージョン内のセカンダリ ワークスペースと Unity カタログ メタストア、同じAzure Databricks アカウント内、プライマリと同じクラウド上。 セカンダリ ワークスペースは、プライマリのネットワーク、Private Link、カスタマー マネージド キーの構成と一致している必要があります。 セカンダリ メタストアには、レプリケートされたカタログと名前を共有するカタログを含めてはなりません。 ワークスペース資産のレプリケーションの場合、Azure Databricksは、初期レプリケーションが完了したときに、セカンダリ ワークスペース内の既存のスコープ内資産をすべて削除します。 スコープ外の資産は影響を受けないため、セカンダリ ワークスペースを空にする必要はありません。
  • プライマリ カタログで参照される各項目に対応する、セカンダリ リージョン内の外部ロケーションとストレージ資格情報。 マネージド DR では、外部の場所やストレージ資格情報は自動的にレプリケートされません。セカンダリで作成する必要があります。

セカンダリ ワークスペースのサーバーレス コンピューティングはリージョン間レプリケーション中にソース ストレージから読み取るため、ソース ストレージとセカンダリ ストレージの両方でAzure Databricksサーバーレス ネットワーク アクセスを双方向に許可する必要があります。

ソース ストレージまたは DBFS ルートへのネットワーク アクセスを制限する場合は、ソース ストレージ ファイアウォールでセカンダリ リージョンのコントロール プレーン IP アドレスと、セカンダリ DBFS ファイアウォールのプライマリ リージョンのコントロール プレーン IP アドレスも許可します。 各リージョンで許可するコントロール プレーンの IP アドレスについては、Azure Databricks コントロール プレーンへの受信を参照してください。

  • セカンダリ リージョンの Azure Databricks アクセス コネクタ。これにはセカンダリ ストレージ アカウントに対するStorage Blob データ共同作成者ロールが割り当てられており、セカンダリ ワークスペースでストレージ資格情報として追加されています。
  • セカンダリ ワークスペースに割り当てられたセカンダリ リージョンのネットワーク接続構成 (NCC) により、サーバーレス コンピューティングはプライベート エンドポイント経由でストレージに到達できます。 「Azure リソースへのプライベート接続を構成する」を参照してください。
  • レプリケートされたカタログによって参照されるすべてのソースおよびセカンダリ ストレージ アカウントへのプライベート エンドポイント。 ADLS Gen2 ストレージの場合は、各アカウントの dfs と blob の両方のサブリソースのプライベート エンドポイントを作成します。 Azure ポータルで承認します。

両方のワークスペースで Mission Critical を有効にする

フェールオーバー グループを作成する前に、プライマリ ワークスペースとセカンダリ ワークスペースの両方で Mission Critical アドオンを有効にします。 アドオンを有効にする各ワークスペースのコンピューティング使用量は、ミッション クリティカル率で課金されます。 現在の料金については、Azure Databricks アカウント チームにお問い合わせください。

  1. アカウント コンソールで、[ ワークスペース] をクリックし、ワークスペースをクリックします。
  2. [アドオン] タブ を クリックします。
  3. ミッション クリティカル カードで、トグルをオンにして確認します。

セカンダリ ワークスペースについても同じ操作を繰り返します。

任意: 固定 URL

Azure Databricksでは、安定した URL を使用することをお勧めします。 安定した URL は常に現在のプライマリ ワークスペースに解決されるため、フェールオーバー後に接続するクライアントを再構成する必要はありません。 元のワークスペース URL は、そのワークスペースに直接アクセスするために有効なままですが、フェールオーバー後も古いプライマリ (現在はセカンダリ) を指し続けます。 元のワークスペース URL ではなく、安定した URL で次のダウンストリーム クライアントをポイントします。

  • Azure Databricks Web UI。
  • SQL ウェアハウスへの JDBC および ODBC 接続。
  • REST API の直接要求。

安定した URL は、フロントエンド (受信) Private Linkでサポートされます。 インバウンド Private Link では、固定 URL として、標準のワークスペース URL 形式ではなく、固定の接続 ID を含むカスタム URL が使用されます。

レプリケーションを設定する

新しいフェールオーバー グループは、 CREATING → INITIAL_REPLICATION → ACTIVEに移行します。 最初のレプリケーション サイクルでは、スコープ内のすべてのデータがセカンダリにコピーされます。 大規模なワークスペースの場合、最初のワークスペース資産のブートストラップには最大 2 週間かかることがあります。 この待機は 1 回限りです。 初期ブートストラップが完了すると、レプリケーションは継続的に実行されます。

レプリケーション中、セカンダリ スコープ内カタログは読み取り専用であり、セカンダリ ワークスペースではコンピューティングを使用できません。 セカンダリに書き込まずに検証クエリを実行するには、Azure Databricksセカンダリ リージョンに個別の読み取り専用モニター ワークスペースを使用することをお勧めします。

フェールオーバー グループを作成するには:

  1. アカウント コンソールで、[ 回復性] をクリックします。
  2. 安定した URL を使用する場合は、[ 安定した URL ] タブをクリックし、[ 安定した URL を作成する] をクリックします。 名前を入力し、現在のプライマリ ワークスペースを選択して、安定した URL を作成します。 元のワークスペース URL ではなく、ダウンストリーム クライアント (JDBC、ODBC、Azure Databricks Web UI、ダイレクト API 要求) を安定した URL でポイントします。
  3. [ フェールオーバー グループ ] タブをクリックし、[ フェールオーバー グループの作成] をクリックします。
  4. フォームに入力します。
    • フェールオーバー グループ名: フェールオーバー グループに対して選択した名前。
    • プライマリ ワークスペース: プライマリであるワークスペース。
    • セカンダリ ワークスペース: セカンダリ リージョン内のワークスペース。
    • ワークスペース資産をレプリケートする (省略可能): 既定ではオフ。 有効にすると、ノートブック、ジョブ、SQL ウェアハウス、クラスター、ダッシュボード、ファイル、フォルダー (およびその ACL) がプライマリからセカンダリにレプリケートされます。 両方のワークスペースで Mission Critical アドオンを有効にする必要があります。 ワークスペース資産のレプリケーションを有効にした場合、Azure Databricksは、初期レプリケーションの完了時にセカンダリ内の既存のスコープ内資産をすべて削除します。 スコープ外の資産は影響を受けません。
    • 安定した URL (省略可能): 手順 2 で作成した安定した URL。
    • レプリケーション スコープ: レプリケートするカタログ。 このフィールドを使用するには、事前にプライマリ ワークスペースを選択する必要があります。
    • ストレージ マッピング: レプリケートされたカタログがプライマリ リージョンで使用する外部の場所ごとに、そのストレージ パスをセカンダリ リージョンで作成した対応する外部の場所にマップするエントリを追加します ( 要件を参照)。 プレフィックス一致のワイルドカードとして * を使用できます。
  5. [ フェールオーバー グループの作成] をクリックします。

たとえば、Azure ストレージ マッピングでは、abfss://data@primary.dfs.core.windows.net/*がabfss://data@secondary.dfs.core.windows.net/*にマップされる場合があります。

マネージド DR によって作成されたリソース

フェールオーバー グループを作成すると、マネージド DR は、レプリケーション パイプラインがリージョン間でデータをコピーするために使用する補助 Unity カタログ リソースをプロビジョニングします。 プライマリメタストアとセカンダリメタストアの両方で、マネージド DR によって以下が作成されます。

  • 他のリージョンのワークスペースを指す 接続 。
  • レプリケートされた各カタログに対する外部カタログ。 外部カタログは、他のリージョンの対応するカタログを参照します。

これらのリソースは、カタログ エクスプローラーで独自のカタログと共に表示されます。 これらは、Azure Databricks のディザスター リカバリーによって作成および管理されていることが記載されたコメントを見ることで識別できます。

Important

既定では、メタストア管理者のみがこれらのリソースを変更または削除できます。 DR が作成する接続または外部カタログは削除しないでください。 いずれか 1 つを削除すると、フェールオーバー グループのレプリケーションが中断されます。

固定ワークスペース ID

一部のツールでは、 Databricks Terraform プロバイダーや Databricksアセット バンドルなど、URL ではなくワークスペース ID によってワークスペースが識別されます。 各安定した URL には、現在のプライマリに解決される 安定したワークスペース ID があるため、これらのツールはフェールオーバー後もアクティブなワークスペースをターゲットにし続けます。 ツールがワークスペース ID を要求する場合は常に、通常のワークスペース ID を使用するのと同じ方法で、安定したワークスペース ID を使用します。

安定したワークスペース ID を見つけるには、 Databricks CLI を使用してアカウントの安定した URL を一覧表示し、関連する安定した URL の stable_workspace_id フィールドを読み取ります。

databricks api get /api/disaster-recovery/v1/accounts/<account-id>/stable-urls

Databricks アセット バンドルと Terraform を使用したデプロイ

Databricks Asset Bundles (DAB) と Databricks Terraform プロバイダーは、ワークスペースホスト URL、またはAzure Databricks アカウントのカスタム URL とワークスペース ID の組み合わせによってワークスペースをターゲットにします。 フェールオーバー後も現在のプライマリにデプロイを続けるために、ホストをカスタム URL (ワークスペースごとの元の URL ではなく、安定した URL のホスト部分) に設定し、 フィールドにworkspace_id指定します。 一緒に現在のプライマリに解決されるため、CI/CD パイプラインはフェールオーバー後もアクティブなワークスペースにデプロイされ続け、構成は変更されません。

  • 新しいデプロイ: 最初のデプロイのカスタム URL と安定したワークスペース ID を使用します。
  • 既存のデプロイ: 前の Terraform プロジェクトから、カスタム URL と安定したワークスペース ID で構成された新しいプロジェクトに状態をインポートし、前のプロジェクトを削除します。 既存のプロジェクトを所定の場所に再ポイントしないでください。デプロイでは、作成したリソースがワークスペースごとの元の URL に対して認識されなくなり、再デプロイによって破棄されて再作成されます。
  • DAB: フェールオーバー グループで ワークスペース資産のレプリケーション を有効にします。 バンドルはそのデプロイ状態をワークスペースに格納し、その状態はワークスペース資産レプリケーションの一部としてのみ新しいプライマリに到達します。

Note

フェールオーバー後、最初の再デプロイ時に、新しいプライマリには存在しないため、マネージド DR でレプリケートされないリソースが再作成されます。 レプリケートされたリソースはそのまま残ります。 マネージド DR の機能とレプリケートしない機能の 制限事項 を参照してください。

レプリケーションを監視します

[ フェールオーバー グループ ] タブには、各フェールオーバー グループの現在の状態、レプリケーション ポイント、およびアクティブなエラーが表示されます。 可能な状態:

都道府県 Meaning
CREATING フェールオーバー グループがプロビジョニングされています。
INITIAL_REPLICATION 最初のレプリケーション サイクルが進行中です。 フェールオーバーはまだ使用できません。
ACTIVE レプリケーションは安定した状態です。 フェールオーバーが利用可能です。
FAILING_OVER フェールオーバーが進行中です。
FAILOVER_FAILED、CREATION_FAILED、DELETION_FAILED 操作が完了しませんでした。 ガイダンスについては、フェールオーバー グループの状態の詳細を確認してください。

フェールオーバー グループの名前を選択して詳細ページを開きます。 レプリケーションは継続的に実行されますが、レプリケーション ポイントには、スコープ内 のすべての リソースが最後に一緒にコピーされた時刻が表示されます。 個々のリソースの方がより新しい状態である可能性がありますが、レプリケーション ポイント以降の すべての データがセカンダリに存在するとは限らず、フェールオーバー時に失われる可能性があります。

レプリケーションポイントが表示されると、エラーでカバーされていないすべての部分はその時点まで複製されています。 初期レプリケーション時、最初のレプリケーションポイントが存在する前は、フェイルオーバーグループはブロッキングエラーを示すことができますが、完全性を測定することはありません。 管理されたDRが全くサポートしていない資産タイプは、 system.replication.states システムテーブルには表示されません。 制限事項を参照してください。 特定の資産を検証するには、セカンダリで検査してください(「 複製の設定」を参照)。

RPO の過去の傾向を監視し、レプリケーションをブロックしているエラーを確認するには、 system.replication.states システム テーブルに対してクエリを実行します。 レプリケーション システム テーブルのリファレンスを参照してください。 最も一般的なエラー クラスとその解決方法については、「リファレンス」を 参照してください。

フェールオーバーとフェールバック

同じ手順では、計画されたフェールオーバー (DR テスト、スケジュールされたメンテナンス) と計画外のフェールオーバー (リージョンの停止) について説明します。 フェールバックするには、リージョンを逆にして手順を繰り返します。

フェールオーバーを開始すると、Azure Databricks では次のようになります:

  • 安定した URL (アタッチされている場合) を新しいプライマリ リージョンにポイントします。
  • レプリケーションの方向を逆にします。
  • 以前のプライマリでのジョブ スケジュールを一時停止します。
  • フェールオーバー グループを FAILING_OVER から INITIAL_REPLICATION に移行します。

フェールオーバーするには:

  1. フェールオーバーが開始されていることをチームに通知します。

  2. 計画フェールオーバーの場合のみ:

    1. プライマリ ワークスペースで、実行中のすべてのクラスターを終了し、すべての SQL ウェアハウスを停止します。
    2. プライマリへの書き込みが停止したことを確認し、レプリケーションが追いつくのを待ちます。 確認するには、フェールオーバー グループの詳細ページを開き、 レプリケーション ポイント が書き込みを停止してから数秒以内であることを確認します。

  3. アカウント コンソールで、[ 回復性 ] → [ フェールオーバー グループ] をクリックし、フェールオーバー グループの名前をクリックします。

  4. [ フェールオーバー] をクリックします。

  5. 新しいプライマリ リージョンを選択し、確認します。 フェールオーバーは数分で完了します。

  6. 新しいプライマリで、フェールオーバー前に実行されていたコンピューティングを開始します。 レプリケートされたクラスターと SQL ウェアハウスはそれぞれ、 TERMINATED および STOPPED 状態の新しいプライマリに到着します。

  7. 新しいプライマリで、必要なジョブ スケジュールを手動で再開します。 以前のプライマリのスケジュールは既に一時停止されています。

安定した URL を介して接続されたクライアントは、フェールオーバー後も引き続き動作します。 元のワークスペース URL を引き続き使用するクライアントを、安定した URL または新しいプライマリのワークスペース URL に再ポイントします。

Important

計画外のフェールオーバーでは、最後のレプリケーション ポイントの後にプライマリに書き込まれたデータが失われる可能性があります。 データ損失が RPO 目標値の範囲内に収まっていることを確認してください。

Tip

1 四半期に 1 回など、フェールオーバーを定期的にテストします。そのため、チームは実際の停止前の手順を理解しています。

マネージド DR を破棄する

  1. アカウント コンソールで、[フェールオーバー グループ→回復性] をクリックし、フェールオーバー グループの名前をクリックして削除します。 ワークスペースでフェールオーバー グループがアクティブになっている間は、Mission Critical をオフにすることはできません。
  2. Mission Critical レートで課金を停止するには、[ アドオン ] タブから各ワークスペースで Mission Critical をオフにします。

制限事項

マネージド DR には、次の制限があります。

  • レプリケートされない: 具体化されたビュー、ストリーミング テーブル、Lakeflow パイプライン、マネージド ボリューム データ (メタデータのレプリケート)、Unity カタログとワークスペースのシークレット、ML モデル、エンドポイントを提供するモデル、ベクター検索インデックス、デルタ共有、発行済みの AI/BI ダッシュボード (ドラフトのレプリケート)、および Lakeflow パイプライン外の Spark 構造化ストリーミング。 行フィルターまたは列マスクと ABAC タグ付きリソースを含むテーブルは、システム テーブルで レプリケートに失敗 したというフラグが設定され、フェールオーバー グループのスコープからリソースを削除するまで、これらのエラーは RPO を保持します。
  • 外部エンジンからのマネージド テーブルの書き込みでは、検出可能性が制限されています。 Managed DR は、Azure Databricks コンピュートによる書き込みに起因する Unity Catalog マネージド テーブルへの変更を検出します。 Iceberg REST Catalog などのオープン API を介して外部 (Azure Databricks以外の) エンジンからレプリケートされたマネージド テーブルへの書き込みが検出されない可能性があるため、それらの書き込みがセカンダリにレプリケートされず、フェールオーバー中に失われる可能性があります。 マネージド DR を使用してレプリケートするテーブルの場合は、Azure Databricksコンピューティングを使用して書き込みます。
  • 対象範囲内のセカンダリ カタログは読み取り専用です。 読み取り専用属性は、レプリケートされたエンティティにのみ適用されます。 マネージド DR スコープ外のセキュリティ保護可能なリソースに対して独自のレプリケーションを設定することもできます。 ただし、マネージド DR が有効な間は、セカンダリ ワークスペースでコンピュート処理を実行できません。そのため、そのセカンダリ ワークスペースで自前のレプリケーション パイプラインを運用することは制限されます。
  • セキュリティ保護可能な Unity カタログの名前を変更すると、セカンダリで削除と再作成がトリガーされます。 マネージド テーブルの場合、名前の変更により、次のサイクルでテーブル データが再レプリケートされます。 安定した状態のレプリケーション中に名前を変更しないでください。
  • UNDROP はセカンダリに伝達されません。
  • 最初のワークスペース資産ブートストラップは、大規模なワークスペースでは最大 2 週間かかる場合があります。
  • マネージド DR で使用される ワークスペース ストレージ アカウントでワークスペース ストレージ ファイアウォールを使用するには、手動で構成する必要があります。 Azure Databricks がデータをレプリケートできるようにするには、ストレージ ファイアウォールで該当するコントロール プレーンの IP アドレスを許可する必要があります。 要件を参照してください。

Reference

リソースをレプリケートできない場合、フェールオーバー グループは、影響を受けるリソースを識別するメッセージと共に、 system.replication.states システム テーブルにエラー クラスを表示します。 次のセクションでは、最も一般的なエラー クラスとその解決方法について説明します。 基になる問題を修正すると、レプリケーションが自動的に回復します。

DR_MISSING_DEPENDENCY

資産はセカンダリに存在しない依存関係を参照するため、資産をレプリケートできません。 サブクラスは、不足している依存関係の種類を識別し、 DR_MISSING_DEPENDENCY.CATALOG、 .SCHEMA、 .TABLE、または .RESOURCEとして表示されます。 解像度は、それらすべてで同じです。

  1. 依存関係がないため、プライマリでも資産が壊れているかどうかを確認します。 その場合は、プライマリ内の資産を修正または削除します。
  2. 資産がプライマリで有効な場合、依存関係はどのフェールオーバー グループのレプリケーション スコープにも含まれていないか、またはこのフェールオーバー グループまたは別のフェールオーバー グループのスコープ内にありますが、レプリケートに失敗しました。 依存関係がスコープ内にない場合は、フェールオーバー グループの レプリケーション スコープ を編集してレプリケートします。 依存関係が既にスコープ内にある場合は、レプリケーションをブロックしているエラーの system.replication.states を確認し、そのエラーを解決します。
DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

マネージド DR は、フェールオーバー グループのストレージ マッピングを資産のソース ストレージの場所に適用することで、レプリケートされた各資産を配置する場所を決定します。 マッピングは、場所と正確に一致するか、子パスも含むプレフィックスとして一致します。 このエラーは、ソース ストレージの場所に対応するマッピングがないことを意味するため、マネージド DR は、資産を配置するセカンダリの場所を判断できません。 外部テーブルとボリュームの場合、マッピングが不足している場合は、プライマリとセカンダリで同じ場所の URI が使用されていることを意味します。 メッセージ内の storage_location は、マップされていない ソース パスです。

  1. アカウント コンソールで、[ 回復性 ] → [ フェールオーバー グループ] に移動し、フェールオーバー グループを編集します。
  2. [ ストレージ マッピング] で、メッセージ内のソースの場所をカバーするようにマッピングを追加または拡大します。 子パスを対象にするには、親パスをマップし、プレフィックス一致の /* サフィックスを追加します。 ストレージ マッピングを参照してください。
  3. セカンダリ メタストア内の外部の場所が、マッピングのターゲット パスを既にカバーしているのを確認します。 フェールオーバー グループは、ターゲットが既存の外部の場所の下にないマッピングを拒否するため、存在しない場合は、最初にその外部の場所を作成します。 Unity カタログを使用したクラウド オブジェクト ストレージへの接続を参照してください。
DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

ストレージ マッピングによって、レプリケートされた資産がセカンダリ内のターゲット パスに解決されましたが、セカンダリ メタストア内の外部の場所がそのパスをカバーしないため、Unity カタログには資産のデータを配置する場所がありません。 メッセージ内の storage_location は、発見された セカンダリ (ターゲット) パスです。

これは通常、次の 2 つのうちいずれかを意味します。以前はそのパスをカバーしていた外部ロケーションが削除されたか範囲が狭められた、または新しくレプリケートされたアセットが、どの外部ロケーションでもカバーされていないセカンダリ パスに解決されることです。 2 番目のケースは、たとえば、どのストレージ マッピングにも対応しないストレージ パスの下に、プライマリに外部テーブルを作成する場合に発生します。 その後、マネージド DR はテーブルの元のパスにフォールバックします。セカンダリ メタストア内の外部の場所はカバーされないため、データを配置する場所はありません。

  1. メッセージの storage_locationから、発見されたセカンダリ パスを特定します。
  2. 拡張する既存の外部の場所、または作成する新しい場所など、セカンダリ メタストア内のどの外部場所がそのパスを対象とするかを決定します。
  3. 既に存在する外部の場所でパスが解決されるようにフェールオーバー グループの ストレージ マッピング を調整するか、(そのストレージ資格情報を使用して) 外部の場所を作成し、それを指すマッピングを拡張します。 Unity カタログを使用したクラウド オブジェクト ストレージへの接続を参照してください。
DR_INTERNAL_ERROR

レプリケーション中にシステム側の障害が発生しました。 アクションは必要ありません。システムは自動的に回復します。 問題が単独で解決しない場合は、Azure Databricksサポートにお問い合わせください。

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

マネージド DR は権限と共にビューをレプリケートしますが、他のカタログ内のオブジェクトを参照するビューでは、そのビューが所有者の特権で実行されるため、その所有者がセカンダリ内の参照先オブジェクトにアクセスできる必要もあります。 このエラーは、所有者がセカンダリに対するアクセス権を持たないため、参照先オブジェクトに対して権限を付与する必要があることを意味します。

  1. ビューが参照するオブジェクトとビューの所有者を検索します。 参照されるオブジェクトは、定義内で完全修飾名 catalog.schema.object として表示されます。権限の付与は所有者に対して行う必要があります。所有者は、Catalog Explorer の 所有者 フィールドから確認することもできます。

    SHOW CREATE TABLE <catalog>.<schema>.<view>;

  2. セカンダリで、参照されている各オブジェクトに対する所有者の現在の特権を確認します。 テーブルを読み取るには、カタログに USE CATALOG 、スキーマに USE SCHEMA し、テーブルに SELECT する必要があります。

    SHOW GRANTS `<view_owner>` ON CATALOG <ref_catalog>;
SHOW GRANTS `<view_owner>` ON SCHEMA <ref_catalog>.<ref_schema>;
SHOW GRANTS `<view_owner>` ON TABLE <ref_catalog>.<ref_schema>.<ref_table>;

  3. 参照されている各オブジェクトに対して、ビュー所有者に不足している権限を付与します。

    GRANT USE CATALOG ON CATALOG <ref_catalog> TO `<view_owner>`;
GRANT USE SCHEMA ON SCHEMA <ref_catalog>.<ref_schema> TO `<view_owner>`;
GRANT SELECT ON TABLE <ref_catalog>.<ref_schema>.<ref_table> TO `<view_owner>`;

  4. ビューが参照するすべてのカタログがフェールオーバー グループの レプリケーション スコープに含まれているので、セカンダリにも存在することを確認します。

詳細については、「 Unity カタログでの権限の管理」を参照してください。

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

リージョン間のテーブル データ レプリケーション中に、セカンダリ ワークスペースのサーバーレス コンピューティングはソース ストレージからデータを読み取り、ストレージはネットワーク接続を拒否しました。ストレージ ファイアウォールまたはネットワークルールでブロックされているか、必要なプライベート エンドポイントが見つからないか未承認です。

「要件」の説明に従って、ソースおよびセカンダリ ストレージAzure Databricksサーバーレス ネットワーク アクセスが許可されていることを確認します。

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

マネージド DR では、セカンダリ ワークスペースのサーバーレス コンピューティングを使用してデータをコピーします。サーバーレス コンピューティングは許可されていません。 これは通常、アカウントまたはワークスペースに対してサーバーレスがオフになっているか、ワークスペースが対象ではないことを意味します。

  1. セカンダリ ワークスペースが対象であることを確認します。 サーバーレス コンピューティングは、サポートされているリージョンの Unity カタログ対応ワークスペースで既定で使用できます。 「サーバーレス コンピューティングに接続する」を参照してください。
  2. アカウント全体でのオプトアウトを確認します。アカウントコンソールで、設定 → 機能の有効化 に移動して、サーバーレスのトグルが表示されており、オフになっているか確認します。
  3. 必要なスコープに対してサーバーレスを有効にします。 対象となるすべてのワークスペースを有効にするには、アカウント管理者がアカウント レベルのサーバーレス トグルをオンにします。 セカンダリ ワークスペースのみを有効にするには、アカウント レベルのトグルをオフのままにし、ワークスペース管理者にワークスペースの プレビューからサーバーレスを有効にします。
  4. 使用可能なトグルがない場合、または有効にした後もサーバーレスが実行されない場合は、Azure Databricks アカウント チームにお問い合わせください。
DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

マネージド DR がセカンダリ内のマップされたターゲット パスにレプリケート されたオブジェクトを作成すると、Unity Catalog は、既存の外部の場所、以前または部分的なセットアップから残っているセキュリティ保護可能なリソース、管理された場所、ワークスペースの既定の (DBFS) ストレージなど、そこに既に存在するストレージと重複しているため、パスを拒否します。

  1. パスを占有するものを特定します。

    カタログ エクスプローラーで、外部の場所、マネージド ストレージの場所、および外部テーブルとボリュームを確認して、パスがターゲット パスをカバーまたは重複しているオブジェクトを見つけます。

  2. 競合するオブジェクトがパスを所有しないようにする必要がある場合は、削除します。 一般的な原因は、以前のセットアップで残っている外部テーブルまたは外部ボリュームです。不要になった場合は削除します。 パスをカバーしない外部の場所である場合は、削除するか再定義します。

  3. それ以外の場合は、フェールオーバー グループのストレージ マッピングを、重複しない専用のターゲット パスに再ポイントします。 広範なバケット ルートよりも特定のサブパスを優先し、ワークスペースの既定 (DBFS) ストレージを回避します。

DR_UNSUPPORTED_FEATURE

資産は、マネージド DR がレプリケートできない機能を使用します。 サブクラスは、サポートされていない機能を識別し、たとえば、 DR_UNSUPPORTED_FEATURE.ABAC_POLICYとして表示されます。 このエラーを解決するには、2 つの方法があります。

  1. プライマリ ワークスペースの資産からサポートされていない機能を削除します。
  2. 機能を削除できない場合は、フェールオーバー グループの レプリケーション スコープから資産を削除することを検討してください。

DR の概念とベスト プラクティスについては、「 ディザスター リカバリー」を参照してください。

  • Last updated on