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

備考

プレビュー

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

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

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

要件

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

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

• アカウントレベルの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/*にマッピングできます。

安定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目標内に収まっていることを確認してください。

ヒント

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

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

レプリケーションエラーは、アカウントコンソールの Resilience セクションにあるフェールオーバーグループの詳細ページと、system.replication.states システムテーブルに表示されます。最も一般的なエラーを以下に示します。

エラー	解決方法
外部ロケーションが不足しています	セカンダリメタストアに不足している外部ロケーションを作成するか、パスを含めるようにフェールオーバーグループのストレージマッピングを更新します。
ネットワーク設定エラー	セカンダリワークスペースのネットワーク接続設定（必要なネットワーク接続構成および承認済みプライベートエンドポイントを含む）を確認します。
依存関係がない	フェイルオーバーグループ内のビューは、フェイルオーバーグループにないカタログに依存しています。依存関係カタログを追加するか、依存ビューを削除します。
リクエスト数の上限を超えました	システムは自動的に再試行します。エラーが続く場合は、Databricksサポートにお問い合わせください。
ソースが不足しています	情報提供。そのアセットはプライマリにもう存在しません；対応は不要です。

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

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

制限事項：

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

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

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