メインコンテンツまでスキップ
に最終更新

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

備考

プレビュー

この機能は パブリック プレビュー段階です。

管理されたディザスタリカバリ（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の状態で複製されます。セカンダリのジョブスケジュールは一時停止されます。

上記のセクションに記載されていないものは、レプリケートされません。詳細については、 制限事項 を参照してください。

要件​

  • ミッションクリティカル ワークスペース アドオンは両方のワークスペースで有効になっています。「両方のワークスペースでミッションクリティカルを有効にする」を参照してください。

  • 両方のワークスペースでサーバレスコンピュートが有効になっています。ほとんどの Unity Catalog が有効になっているワークスペースでは、サーバレスコンピュートはデフォルトで利用可能です。サーバレスコンピュートへの接続を参照してください。

  • レプリケートする予定のカタログが使用するすべての外部ロケーションに対する すべての権限 を持つアカウント管理者ロール。

  • アカウントレベルのSSO が**すべてのワークスペース**で有効化されており、SCIM を介してIDがアカウントに同期されるため、ユーザー、グループ、およびサービスプリンシパルが両方のリージョンに存在します。

  • 安定したURLについては：Databricksドメイン用にプロビジョニングされたカスタムURL（アカウントチームにお問い合わせください）およびアカウントレベルのOAuth。

  • プライマリと同じDatabricksアカウントおよび同じクラウド上にあり、セカンダリリージョンにあるセカンダリワークスペースとUnity Catalogメタストア。セカンダリワークスペースは、プライマリのネットワーク、Private Link、および顧客管理キー構成と一致している必要があります。セカンダリメタストアは、レプリケートされたカタログと名前を共有するカタログを含んではなりません。ワークスペースアセットのレプリケーションの場合、Databricks は初回レプリケーションの完了時に、セカンダリワークスペース内の既存の範囲内アセットを削除します。範囲外のアセットは影響を受けないので、セカンダリワークスペースは空である必要はありません。

  • プライマリカタログで参照されるそれぞれに対応する、セカンダリリージョン内の外部ロケーションとストレージ資格情報。Managed DR は外部ロケーションまたはストレージの資格情報を自動的にレプリケートしません；セカンダリで作成する必要があります。

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

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

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

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

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

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

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

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

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

  1. アカウントコンソールで、 「Resilience」 をクリックします。

  2. 安定URLを使用する予定がある場合は、安定URLタブをクリックし、次に安定URLを作成をクリックします。名前を入力し、現在のプライマリワークスペースを選択し、安定URLを作成してください。元のワークスペースURLの代わりに、安定したURLにダウンストリームクライアント（JDBC、ODBC、Databricks Web UI、直接のAPIリクエスト）を指定します。

  3. 「**フェイルオーバーグループ**」タブをクリックし、次に「**フェイルオーバーグループを作成**」をクリックしてください。

  4. フォームにご記入ください：

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

  5. 「フェイルオーバーグループの作成」 をクリックします。

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

DRが作成する管理対象リソース​

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

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

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

重要

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

レプリケートされたリソースの所有権​

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

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

安定URLを使用する​

安定URLは常に現在のプライマリワークスペースを指すため、安定URL経由で接続するクライアントは、フェイルオーバー後に再設定する必要がありません。以下のダウンストリームクライアントを、元のワークスペースURLではなく、安定URLに指定してください。

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

安定URLはフロントエンド (インバウンド) PrivateLinkでサポートされていますが、URL形式は標準形式とは異なります。

元のワークスペースURLは機能し続けますが、フェイルオーバー後も有効ではありません。Databricks では、クライアントを安定URLへ移行することをお勧めします。

複製を監視​

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

状態

意味

CREATING

フェイルオーバーグループがプロビジョニング中です。

INITIAL_REPLICATION

最初のレプリケーションサイクルは進行中です。フェイルオーバーはまだ利用できません。

ACTIVE

レプリケーションは定常状態です。フェイルオーバーが利用可能です。

FAILING_OVER

フェールオーバーが進行中です。

FAILOVER_FAILED、CREATION_FAILED、 DELETION_FAILED

操作は完了しませんでした。ガイダンスについては、フェイルオーバーグループのステータス詳細をご確認ください。

フェイルオーバーグループの名前をクリックして、詳細ページを開きます。レプリケーション時点は、スコープ内のすべてのリソースが最後にコピーされた時期を示しています。レプリケーションポイント以降に書き込まれたデータは、セカンダリに存在しない可能性があり、フェイルオーバー時に失われる可能性があります。

履歴RPOトレンドとアセットごとのレプリケーションエラーについては、system.replication.states システムテーブルをクエリします。複製 システムテーブル リファレンスを参照してください。

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

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

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

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

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

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

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

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

  3. アカウントコンソールで、**Resilience** → **Failover groups** をクリックし、その後、フェイルオーバーグループの名前をクリックします。

  4. 「フェイルオーバー」をクリックしてください。

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

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

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

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

重要

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

ヒント

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

一般的なレプリケーションエラー​

system.replication.statesシステムテーブルで、フェイルオーバーグループの状態を監視することができます。テーブルには、フェイルオーバーグループごとの現在のエラーのサマリーが含まれています。以下の表に、最も一般的なエラーを頻度が高い順に示します。

エラークラス

解決方法

DR_INTERNAL_ERROR

一時的な、またはシステム側の障害。システムは自動的に再試行します。問題が自動的に解決しない場合は、Databricksサポートにお問い合わせください。

DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

アセットの基盤となる外部ロケーションはセカンダリ メタストアに登録されていません。セカンダリリージョンに不足している外部ロケーションを作成するか、パスを含むようにフェールオーバーグループのストレージマッピングを更新してください。

DR_MISSING_DEPENDENCY.TABLE

アセット（通常はビュー）が、フェイルオーバーグループの一部ではないテーブルを参照しています。テーブルをフェイルオーバーグループに追加するか、依存するアセットを削除してください。

DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

スキーマまたはそのマネージドロケーションには、プライマリリージョンとセカンダリリージョン間でストレージマッピングがありません。フェイルオーバーグループにスキーマのストレージマッピングを追加します。

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

ビューの所有者は、ビューが依存するクロス カタログ オブジェクトに対する権限がないため、セカンダリでビューを作成できません。必要な許可がセカンダリに存在するかどうか確認し、必要に応じて手動で付与してください。

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

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

制限事項：​

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

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

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

このページの見出し