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

管理されたディザスタリカバリ（DR）により、Databricksデプロイメントがセカンダリリージョンに複製されるため、リージョンの停止から数分で復旧できます。Databricks は、レプリケーションパイプライン、セカンダリでのレプリケートされたカタログの状態、およびフェイルオーバープロセスを管理します。レプリケーションスクリプトの作成や維持は不要です。

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

重要

マネージド DR はゲート付きです。Databricks アカウントチームを通じてアクセスを申請してください。承認されると、Databricks はアカウントでマネージド DR を有効にします。

マネージドディザスタリカバリとは何ですか？

マネージドDRは、お客様が既に運用しているワークスペースとメタストアの上に構築されています。プライマリリージョンとセカンダリリージョンにそれぞれ1つずつ、合計2つのDatabricksワークスペースがあり、さらに各リージョンに1つのメタストアがあります。マネージド DR その後：

選択されたカテゴリをプライマリからセカンダリへ継続的にレプリケートします。Unity Catalog メタデータとマネージドテーブルデータ、およびノートブック、ジョブ、SQLウェアハウス、クラスター、ACL などのワークスペースアセットは、どちらも個別にオプションです。
現在のプライマリを常に指し示す単一の接続文字列であるオプションの**安定URL**を提供することで、クライアントはフェイルオーバー後に再構成なしで機能し続けることができます。
DRテストや実際の障害のために、必要なときにフェイルオーバーをトリガーできるようになります。

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

複製されるもの

Managed DR は、レプリケーションサイクルごとに以下をレプリケートできます。両方のカテゴリはオプションなので、いずれかまたは両方を有効にできます。

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

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

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

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

要件

プライマリーリージョンとセカンダリーリージョンの両方にある、Enterprise プランのワークスペース。
ミッションクリティカルワークスペースアドオンは両方のワークスペースで有効になっています。「両方のワークスペースでミッションクリティカルを有効にする」を参照してください。
両方のワークスペースでサーバレスコンピュートが有効になっています。ほとんどの Unity Catalog が有効になっているワークスペースでは、サーバレスコンピュートはデフォルトで利用可能です。サーバレスコンピュートへの接続を参照してください。
レプリケートする予定のカタログが使用するすべての外部ロケーションに対する すべての権限 を持つアカウント管理者ロール。
アカウントレベルのSSO が**すべてのワークスペース**で有効化されており、SCIM を介してIDがアカウントに同期されるため、ユーザー、グループ、およびサービスプリンシパルが両方のリージョンに存在します。
安定したURLについては：Databricksドメイン用にプロビジョニングされたカスタムURL（アカウントチームにお問い合わせください）およびアカウントレベルのOAuth。
プライマリと同じDatabricksアカウントおよび同じクラウド上にあり、セカンダリリージョンにあるセカンダリワークスペースとUnity Catalogメタストア。セカンダリワークスペースは、プライマリのネットワーク、Private Link、および顧客管理キー構成と一致している必要があります。セカンダリメタストアは、レプリケートされたカタログと名前を共有するカタログを含んではなりません。ワークスペースアセットのレプリケーションの場合、Databricks は初回レプリケーションの完了時に、セカンダリワークスペース内の既存の範囲内アセットを削除します。範囲外のアセットは影響を受けないので、セカンダリワークスペースは空である必要はありません。
プライマリカタログで参照されるそれぞれに対応する、セカンダリリージョン内の外部ロケーションとストレージ資格情報。Managed DR は外部ロケーションまたはストレージの資格情報を自動的にレプリケートしません；セカンダリで作成する必要があります。

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

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

セカンダリワークスペースによって使用されるIAMロールに付与された、複製されたカタログが参照するすべての外部ロケーションに対するすべての権限

両方のワークスペースでミッションクリティカルを有効化

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

アカウントコンソールで、[ ワークスペース ] をクリックして、次にワークスペースをクリックしてください。
[ アドオン ]タブをクリックします。
ミッションクリティカル カードで、トグルをオンにし、確定します。

セカンダリワークスペースで繰り返します。

オプション: 安定したURL

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

Databricks Web UI です。
SQLウェアハウスへのJDBCおよびODBC接続。
直接の REST API リクエスト。

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

たとえば、安定したURLは<my-custom-url>.databricks.com/?c=stable_connection_idの形式になります。「マネージドディザスタリカバリを備えたワークスペースのインバウンドプライベートリンクを構成する」を参照してください。

レプリケーションのセットアップ

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

レプリケーション中、セカンダリのスコープ内カタログは読み取り専用であり、セカンダリワークスペースではコンピュートは利用できません。セカンダリに書き込まずに検証クエリを実行するには、Databricks は、セカンダリリージョンに個別の読み取り専用モニタリングワークスペースを推奨しています。

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

アカウントコンソールで、 「Resilience」 をクリックします。
安定URLを使用する予定がある場合は、安定URLタブをクリックし、次に安定URLを作成をクリックします。名前を入力し、現在のプライマリワークスペースを選択し、安定URLを作成してください。元のワークスペースURLの代わりに、安定したURLにダウンストリームクライアント（JDBC、ODBC、Databricks Web UI、直接のAPIリクエスト）を指定します。
「**フェイルオーバーグループ**」タブをクリックし、次に「**フェイルオーバーグループを作成**」をクリックしてください。
フォームにご記入ください：
- **フェイルオーバーグループ名**：フェイルオーバーグループに付ける名前です。
- プライマリワークスペース ：主要なワークスペースです。
- セカンダリワークスペース：セカンダリリージョンにあるワークスペースです。
- ワークスペースアセットをレプリケート （オプション）：デフォルトではオフです。プライマリからセカンダリへのノートブック、ジョブ、SQLウェアハウス、クラスター、ダッシュボード、ファイル、およびフォルダー（およびそれらのACL）のレプリケーションを有効にします。両方のワークスペースでミッションクリティカルアドオンが有効化されている必要があります。ワークスペース資産レプリケーションを有効にすると、Databricks は、初期レプリケーションが完了したときに、セカンダリで既存の適用範囲内の資産を削除します。スコープ外のアセットは影響を受けません。
- 安定URL（オプション）：ステップ2で作成した安定URLです。
- レプリケーション範囲 ：複製するカタログこのフィールドを利用可能にするには、プライマリワークスペースを選択する必要があります。
- ストレージマッピング ：レプリケートされたカタログがプライマリリージョンで使用する外部ロケーションごとに、そのストレージパスを、セカンダリリージョンで作成した対応する外部ロケーションにマッピングするエントリを追加します (要件を参照してください)。* をプレフィックスの一致にワイルドカードとして使用できます。
「フェイルオーバーグループの作成」 をクリックします。

例えば、AWSストレージマッピングはs3://primary-bucket/data/*をs3://secondary-bucket/data/*にマッピングできます。

マネージドディザスタリカバリによって作成されたリソース

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

別のリージョンにあるワークスペースを指す**接続**です。
レプリケートされた各カタログ用の**フォーリンカタログ**。フォーリンカタログは、他のリージョンの対応するカタログを参照します。

これらのリソースは、カタログエクスプローラーでお客様自身のカタログとともに表示されます。Databricks ディザスタリカバリによって作成および管理されているというコメントによって、それらを識別できます。

重要

デフォルトでは、メタストア管理者のみがこれらのリソースを変更または削除できます。DRが作成および管理する接続やフォーリンカタログを削除しないでください。どちらかを削除すると、フェイルオーバーグループのレプリケーションが破損します。

安定したワークスペースID

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

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

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

Databricks Asset BundlesとTerraformを使用したデプロイ

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

新規デプロイ ：最初のデプロイからのカスタムURLと安定したワークスペースIDを使用します。
既存のデプロイ: 以前のTerraformプロジェクトから状態を、カスタムURLと安定したワークスペースIDで構成された新しいプロジェクトにインポートし、その後、以前のプロジェクトを削除します。既存のプロジェクトをその場で再指定しないでください。デプロイは、元のワークスペースごとのURLに対して作成したリソースを認識しなくなるため、再デプロイするとそれらを破棄して再作成します。
DABs: フェイルオーバーグループで ワークスペースアセットのレプリケーション を有効にする。バンドルはデプロイ状態をワークスペースに保存し、その状態はワークスペースアセットのレプリケーションの一部としてのみ新しいプライマリに到達します。

注記

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

複製を監視

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

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

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

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

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

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

同じ手順は、計画的フェイルオーバー（DRテスト、スケジュールされたメンテナンス）と計画外フェイルオーバー（地域的な障害）の両方に適用されます。フェイルバックするには、リージョンを反転させて手順を繰り返します。

フェールオーバーをトリガーすると、Databricks は:

安定URLが関連付けられている場合、それを新しいプライマリリージョンに設定します。
レプリケーションの方向を反転させます。
元プライマリでジョブスケジュールを停止します。
フェイルオーバーグループを FAILING_OVER を通じて INITIAL_REPLICATION へ移行します。

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

フェイルオーバーが開始されることをチームに通知してください。
計画的フェイルオーバーの場合のみ:
1. プライマリワークスペースで、すべての稼働中のクラスターを終了し、すべてのSQLウェアハウスを停止してください。
2. プライマリへの書き込みが停止していることを確認し、その後、レプリケーションが追いつくのを待ってください。確認するには、フェイルオーバーグループの詳細ページを開き、**レプリケーションポイント**が書き込みを停止した時刻から数秒以内であることを確認してください。
アカウントコンソールで、**Resilience** → **Failover groups** をクリックし、その後、フェイルオーバーグループの名前をクリックします。
「フェイルオーバー」をクリックしてください。
新しいプライマリーリージョンを選択し、確認します。フェイルオーバーは数分で完了します。
新しいプライマリで、フェイルオーバー前に実行されていたコンピュートを開始してください。レプリケートされたクラスターとSQLウェアハウスは、それぞれTERMINATEDとSTOPPEDの状態で新しいプライマリに到着します。
新しいプライマリで必要なジョブスケジュールを手動で再開してください。元のプライマリのスケジュールは既に一時停止されています。

安定URL経由で接続しているクライアントは、フェイルオーバー後も引き続き機能します。元のワークスペースURLをまだ使用しているクライアントは、安定したURLか新しいプライマリのワークスペースURLのいずれかに向け直してください。

重要

計画外のフェイルオーバーの場合、最終複製時点以降にプライマリに書き込まれたデータは失われる可能性があります。発生した損失がRPO目標内に収まっていることを確認してください。

ヒント

実際の障害が発生する前にチームが手順に習熟できるように、四半期に一度など定期的にフェイルオーバーをテストしてください。

マネージド DR のティアダウン

アカウントコンソールで、 Resilience → Failover groups をクリックし、次にフェイルオーバーグループの名前をクリックして削除してください。フェイルオーバーグループがワークスペースでアクティブである間は、ミッションクリティカルをオフにすることはできません。
ミッションクリティカルの料金での請求を停止するには、**アドオン**タブから各ワークスペースでミッションクリティカルをオフにします。

制限事項：

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

レプリケートされないもの: マテリアライズドビュー、ストリーミングテーブル、Lakeflow パイプライン、マネージドボリュームデータ (メタデータはレプリケートされます)、Unity Catalog とワークスペースシークレット、機械学習モデル、モデルサービング Endpoint、ベクトル検索インデックス、Delta シェア、公開済み AI/BI ダッシュボード (下書きはレプリケートされます)、Lakeflow パイプライン外部の Spark Structured Streaming。行フィルターまたは列マスクと ABACタグ付きのリソースを持つテーブルは、システムテーブルで「**レプリケートに失敗しました**」とフラグが付けられます。これらの失敗により、フェールオーバーグループのスコープからリソースを削除するまで RPO が遅延します。
対象のセカンダリカタログは読み取り専用です。読み取り専用はレプリケートされたエンティティにのみ適用されます。マネージドDRスコープ外のセキュリティ保護対象について、独自のレプリケーションを引き続き設定することが可能です。ただし、マネージドDRが有効になっている間はセカンダリワークスペースでコンピュートを実行することはできません。そのため、そこでのDIY (自作) レプリケーションパイプラインの運用が制限されます。
Unity Catalog のセキュリティ保護可能なオブジェクトの名前を変更すると、セカンダリで削除と再作成が実行されます。マネージドテーブルの場合、名前の変更によって、次のサイクルでテーブルデータが再レプリケートされます。定常状態のレプリケーション中に名前の変更は避けてください。
UNDROP セカンダリにはプロパゲートされません。
アカウントあたりのカタログは最大300個です。
アカウントあたりのフェイルオーバーグループは最大100個です。
大規模なワークスペースの場合、ワークスペースアセットの初期ブートストラップには最大2週間かかることがあります。

リファレンス

リソースをレプリケートできない場合、フェイルオーバーグループはsystem.replication.statesシステムテーブルにエラークラスを提示し、影響を受けるリソースを特定するメッセージを添えます。以下のセクションでは、最も一般的なエラークラスとそれらを解決する方法について説明します。根本的な問題を修正した後、レプリケーションは自動的に復旧します。

DR_MISSING_DEPENDENCY

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

依存関係の不足により、プライマリでもアセットが破損しているかどうかを確認します。その場合は、プライマリでアセットを修正または削除してください。
アセットがプライマリで有効な場合、依存関係はどのフェイルオーバーグループのレプリケーションスコープにも含まれていないか、またはこのフェイルオーバーグループまたは別のフェイルオーバーグループのスコープ内にあるにもかかわらず、レプリケーションに失敗しています。依存関係がスコープ内にない場合は、フェイルオーバーグループのレプリケーションスコープを編集して、それもレプリケートするようにしてください。依存関係がすでにスコープ内にある場合は、レプリケーションをブロックしているエラーについてsystem.replication.statesを確認し、そのエラーを解決してください。

DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

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

アカウントコンソールで、**Resilience** → **Failover groups** に移動し、フェイルオーバーグループを編集します。
**ストレージマッピング**の下で、マッピングを追加または拡張して、メッセージ内のソースロケーションをカバーするようにします。子パスをカバーするには、親パスをマッピングし、プレフィックスの一致のために/*サフィックスを追加します。「ストレージマッピング」を参照してください。
セカンダリメタストア内の外部ロケーションがすでにマッピングのターゲットパスをカバーしていることを確認します。フェイルオーバーグループは、ターゲットが既存の外部ロケーション配下にないマッピングを拒否するため、存在しない場合はまずその外部ロケーションを作成してください。「Unity Catalog を使用してクラウドオブジェクトストレージに接続する」を参照してください。

DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

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

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

メッセージのstorage_locationから、カバーされていないセカンダリパスを特定してください。
セカンダリメタストアのどの外部ロケーションがそのパスをカバーすべきかを決定します。拡張する既存の外部ロケーション、または新しく作成する外部ロケーションのいずれかです。
フェールオーバーグループのストレージマッピングを調整して、パスが既存の外部ロケーションの下に解決されるようにするか、外部ロケーション（そのストレージ資格情報を含む）を作成し、マッピングを拡張してそれを指すようにしてください。「Unity Catalog を使用してクラウドオブジェクトストレージに接続する」を参照してください。

DR_INTERNAL_ERROR

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

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

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

ビューが参照するオブジェクトとビューの所有者を検索します。参照されるオブジェクトは、定義で完全修飾されたcatalog.schema.object 名前として表示されます。付与は所有者に行う必要があり、これはカタログエクスプローラーの**所有者**フィールドからも読み取ることができます。
SQL
```
SHOW CREATE TABLE <catalog>.<schema>.<view>;
```
セカンダリで、参照されている各オブジェクトに対する所有者の現在の権限を確認してください。テーブルを読み取るには、そのカタログに対するUSE CATALOG、そのスキーマに対するUSE SCHEMA、およびそのテーブルに対するSELECTが必要です。
SQL
```
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>;
```

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

SQL
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>`;

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

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

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

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

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

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

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

セカンダリワークスペースが適格であることを確認してください。サーバレスコンピュートは、サポートされているリージョンのUnity Catalog対応ワークスペースでデフォルトで利用できます。「サーバレスコンピュートに接続する」を参照してください。
アカウント全体のオプトアウトを確認します。アカウントコンソールで、**設定**→**機能の有効化**に移動し、サーバレストグルが存在し、オフになっているかを確認します。
必要なスコープでサーバレスを有効にします。すべての対象となるワークスペースを有効にするには、アカウント管理者がアカウントレベルのサーバレス切り替えをオンにします。セカンダリワークスペースのみを有効にするには、アカウントレベルの切り替えをオフのままにし、ワークスペース管理者にワークスペースの**[プレビュー]**からサーバレスを有効にしてもらいます。
トグルが利用できない場合、または有効にしてもサーバレスがまだ実行されない場合は、Databricks アカウントチームにお問い合わせください。

DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

マネージド DR がセカンダリでマッピングされたターゲットパスにレプリケートされたオブジェクトを作成する際、既存の外部ロケーション、以前または部分的なセットアップで残されたセキュリティ保護可能なオブジェクト、マネージドロケーション、またはワークスペースのデフォルト (DBFS) ストレージなど、そこに既に存在するストレージと重複するため、Unity Catalog はそのパスを拒否します。

パスを占有しているものを特定してください。

ストレージパスの競合の解決を参照してください。
競合するオブジェクトがパスを所有すべきでない場合、削除します。一般的な原因は、以前のセットアップで残された外部テーブルまたは外部ボリュームです。不要になった場合は削除してください。パスをカバーすべきでない外部ロケーションである場合、削除または再定義します。
そうでない場合は、フェールオーバーグループのストレージマッピングを専用の重複しないターゲットパスに再指定してください。広範なバケットルートよりも特定のサブパスを優先し、ワークスペースのデフォルト (DBFS) ストレージは避けてください。

DR_UNSUPPORTED_FEATURE

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

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

DRの概念とベストプラクティスについては、ディザスタリカバリをご覧ください。

マネージド ディザスタリカバリとは何ですか？​

複製されるもの​

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

要件​

両方のワークスペースでミッションクリティカルを有効化​

オプション: 安定したURL​

レプリケーションのセットアップ​

マネージドディザスタリカバリによって作成されたリソース​

安定したワークスペースID​

Databricks Asset BundlesとTerraformを使用したデプロイ​

複製を監視​

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

マネージド DR のティアダウン​

制限事項：​

リファレンス​