ディザスタリカバリを管理する

注記

ディザスタリカバリはプライベートプレビュー中です。プライベートプレビュー期間中、AWSでのクロスリージョンレプリケーションのみで利用でき、管理はUIのプロジェクト設定から行います。お客様のAccountで有効にするには、ワークスペース管理者に依頼してDatabricksの担当者にご連絡いただく必要があります。

プライベートプレビュー期間中、ディザスタリカバリは本番運用での使用を目的としたものではありません。

このガイドでは、プロジェクトのディザスタリカバリを有効にする方法、フェイルオーバーまたはフェイルバックをTriggerする方法、およびリカバリBranchを調査する方法について説明します。ディザスタリカバリの仕組みと高可用性との違いについては、ディザスタリカバリを参照してください。

Lakebase プロジェクト管理者（CAN_MANAGE アクセス制御リスト（ACL）を持つ者）のみが、ディザスタリカバリを有効または無効にしたり、フェイルオーバーをトリガーしたりできます。CAN_MANAGEを持つユーザーを確認するには、プロジェクトの 設定の**プロジェクトのアクセス許可**セクションを確認してください。

ディザスタリカバリは 2 つのワークスペースにまたがるため、各タスクは特定のワークスペースで実行されます。

タスク	実行場所
有効または無効にする	プライマリワークスペース内のプライマリプロジェクト
Trigger フェイルオーバーを	セカンダリ ワークスペース内のセカンダリ プロジェクト
フェールバック	元のプライマリ ワークスペース（現在はセカンダリ）内の元のプライマリ プロジェクト
リカバリーBranchを検査する	フェールバック後の元のプライマリーワークスペース内の元のプライマリープロジェクト

タスク	実行場所
有効または無効にする	プライマリワークスペース内のプライマリプロジェクト
Trigger フェイルオーバーを	セカンダリ ワークスペース内のセカンダリ プロジェクト
フェールバック	元のプライマリ ワークスペース（現在はセカンダリ）内の元のプライマリ プロジェクト
リカバリーBranchを検査する	フェールバック後の元のプライマリーワークスペース内の元のプライマリープロジェクト

前提条件

• Lakebaseオートスケールプロジェクト。 Lakebase Provisionedで作成されたプロジェクトは、ディザスタリカバリを有効にする前にAutoscalingに移行する必要があります。Lakebase オートスケールへのアップグレードをご覧ください。
• 異なるリージョンにある2つのワークスペース。 同じリージョン内のワークスペースは、レプリケーション ペアとしてサポートされていません。
• 適格なレプリケーションターゲットとしてのセカンダリ ワークスペース セカンダリ ワークスペース は、お客様の アカウント の適格なレプリケーションターゲットのリストに含まれている必要があります。プライベートプレビュー中、Databricks のアカウント担当者がディザスタリカバリを有効にすると、これをセットアップします。

注記

プライベートプレビュー中に、アカウント担当者に以下の情報を提供して、レプリケーション グループを設定できるようにしてください。

• アカウント ID: アカウント コンソールで見つけます
• プライマリワークスペースID: プライマリLakebaseプロジェクトが配置されているワークスペース
• セカンダリワークスペースID：セカンダリLakebaseプロジェクトが実行されるワークスペース
• Lakebase プロジェクト ID: ディザスタリカバリを有効にする前に、プロジェクトはすでに存在している必要があります。

ワークスペース ID を見つけるには、ワークスペースオブジェクトの識別子を取得するを参照してください。Lakebase プロジェクト ID は、Lakebase コンソールのプロジェクト リストに表示されるプロジェクトの project_id です。

ディザスタリカバリは顧客管理キー (CMK) と連携します。CMKで暗号化されたプロジェクトは、他のプロジェクトと同様にリージョン間でレプリケートされます。

ディザスタリカバリを有効にする

プロジェクト管理者は、ホストしているワークスペースで、 プライマリ プロジェクト からレプリケーションを有効にします。

1. プライマリワークスペースで、プロジェクトを開き、 設定 を選択してください。
2. 「 Cross-Workspace Replication 」セクションで、 プライマリワークスペース を確認してください。これは、プロジェクトをホストするワークスペースに設定されており、変更できません。
3. 「Secondary」セクションで、セカンダリプロジェクトが実行されるワークスペースを選択します。
4. 保存して有効にする を選択します。

Lakebase は、レプリケーショングループを作成し、プライマリからセカンダリへの定期的なレプリケーションを開始します。

セカンダリ ワークスペース で、Lakebase は Primary と同じ名前のセカンダリプロジェクトを作成します。それを見つけるには、セカンダリ ワークスペース に切り替えて Lakebase コンソールを開きます。新しいプロジェクトは、**オートスケールデータベース プロジェクト** リストに表示されます。

セカンダリプロジェクトにはプライマリプロジェクトのすべてのBranchが含まれており、各Branchには独自のリージョンEndpointがあります。定期的なレプリケーション中、このセカンダリプロジェクトは読み取り専用です。そのコンピュートはアイドル状態のままで、フェイルオーバーによって昇格されるまで接続できません。Branch構成（コンピュート範囲と高可用性を含む）はプライマリからコピーされるため、フェイルオーバー時に一致するコンピュートが即座に起動できます。

フェイルオーバーをTriggerします

Project Admin はセカンダリ ワークスペースから Trigger します。そのため、プライマリリージョンが利用できない場合でも起動できます。フェイルオーバーは即時です。Lakebase はセカンダリを新しいプライマリに昇格し、元のプライマリでの書き込みの受け入れを停止します。

To Trigger a failover:

1. セカンダリ ワークスペースで、セカンダリ プロジェクトを開き、その プロジェクト ダッシュボード に移動します。
2. プロジェクト設定 で、 セカンダリを昇格 を選択します。
3. 「昇格」 ダイアログで、 「フェイルオーバー」 を選択します。フェイルオーバーは、このコピーを直ちに昇格させます。まだこのワークスペースにレプリケートされていないトランザクションは、それと共に昇格されません。Lakebaseはそれらをrecovery Branchとして保持し、フェイルバック後に調整します。
4. 「このプロジェクトを昇格することを確認します。この操作によりダウンタイムが発生する可能性があります。」 を選択し、 「昇格」 を選択します。

フェイルオーバーにはダウンタイムが発生します。元のプライマリは直ちに書き込みを停止し、新しいプライマリはコンピュートの起動とクエリ可能になるまで利用できません。新しいプライマリの接続文字列を使用して新しいプライマリに接続するように設定するまで、アプリケーションは停止したままになります。具体的には、フェイルオーバー後：

• セカンダリプロジェクトが新しい Primary になります。Lakebase は、元の Primary からコピーされたブランチ構成を使用して、リージョン Endpoint をアクティブ化し、各 Branch のコンピュートを起動します。
• 元のプライマリは書き込みの受け入れを停止します。ワークスペースが利用可能になると、Lakebase はコンピュートをシャットダウンします。その上の 同期テーブルまたはLakebase チェンジデータフィードパイプライン はすべて終了します。
• アプリケーションは、新しいプライマリのEndpointに再接続する必要があります。各リージョンには独自のEndpointがあります。そのため、トラフィックを再開する前に、アプリケーションの接続設定を更新し、新しい認証トークンを取得してください。新しいプライマリの接続文字列とトークンをセカンダリプロジェクトの**接続**ダイアログから取得します。「データベースに接続する」を参照してください。

実際の障害発生時だけでなく、いつでもフェイルオーバーをTriggerできます。これは、DR訓練をランし、再接続プロセスをリハーサルするために使用し、アプリケーションの接続文字列を更新して新しいトークンを取得することで、実際の障害が発生する前にその有効性が確認されるようにします。

元のリージョンにフェイルバックします

そのリージョンが復旧した後、フェールバックによってワークロードが元のリージョンに戻ります。ディザスタリカバリのライフサイクルにおいて、フェイルオーバーは、障害発生時にセカンダリリージョンで稼働するための緊急措置です。フェイルバックは、元のリージョンが正常に戻った後で、通常のトポロジに戻るための計画的な措置です。フェイルバックはオプションです。元のリージョンを再びプライマリにしたい場合に実行します。

フェイルバックは個別の操作ではありません。逆方向へのフェイルオーバーのランです。元のプライマリリージョンが復旧すると、そのプロジェクトはセカンダリとしてレプリケーショングループに再参加し、現在のプライマリから元のリージョンへのレプリケーションが再開されます。フェイルバックは障害時ではなく計画的な操作として実行されるため、まずレプリケーションを完全に追いつかせてから、データ損失なし (RPO=0) でフェイルバックすることができます。これを行うには、現在のプライマリへの書き込みを停止し、昇格させる前にレプリケーションの遅延がゼロになるまで待機します。詳細については、次のステップを参照してください。

Promote ダイアログには、 Switchover も近日公開予定のオプションとして記載されています。スイッチオーバーは現在のプライマリーへの書き込みを停止し、すべてのトランザクションがレプリケートされるのを待ち、単一のステップで昇格します。そのため、書き込みの停止とフェールオーバーを個別のステップとして行う必要はありません。

フェイルバックするには：

1. 元のリージョンが追いつく間、新しいトランザクションが作成されないように、現在のプライマリでの書き込みトラフィックを停止します。これはアプリケーションから実行します。たとえば、ライターサービスを一時停止するか、アプリケーションを読み取り専用モードまたはメンテナンスモードにするなどです。Lakebaseは書き込みを停止しません。
2. レプリケーションの遅延がゼロになるまで監視し、すべてのトランザクションが元のリージョンにレプリケートされたことを確認します。
3. 元のプライマリワークスペースから、プロジェクト（現在セカンダリとして機能しています）を開き、そのダッシュボードで「 Promote secondary 」を選択してください。これは、フェイルオーバーに使用したのと同じ操作です。「 Promote 」ダイアログで、「 Failover 」を選択し、確認してください。
4. アプリケーションを構成して、接続文字列と新しい認証トークンを使用して元のプライマリに接続します。これらを元のプライマリプロジェクトの [接続] ダイアログから取得します。データベースに接続するを参照してください。

フェールバック後：

• 元のリージョンが再び Primary になり、もう一方のリージョンはアイドル状態の Secondary に戻ります。
• 元の障害発生前にレプリケートされなかったトランザクションがある場合、Lakebaseはそれらを元のプライマリ上のリカバリーBranchとして表示します。「リカバリーBranchの検査と調整」を参照してください。

リカバリBranchの検査および調整

リカバリーBranchは元のプライマリプロジェクト上に存在するため、元のプライマリワークスペースで確認します。プロジェクトにリカバリーBranchがある場合、その Branches ページには、最近のフェイルオーバーから存在するリカバリーBranchの数を報告するバナーが表示され、データの相違を検査するように促されます。表示するには、 「View project branches」 を選択してください。リカバリーBranchは、相違が検出された場合にのみ表示されます。

「Branch」 ページでは、分岐元のBranch名に-recoveryのサフィックスが付加された回復Branchが表示されます。そのステータス**タグ**は、同期プロセスにおける現在の位置を示します。

• ホーム同期保留中 ：Branchがまだホームリージョンにレプリケートされていないため、差異を特定できません。タグにカーソルを合わせると、検査は時期尚早であることが説明されます。これは、フェイルオーバー直後でフェイルバック前の状態です。Branchが同期するのを待ちます。
• 検査 ：Branch はホームリージョンに同期され、調整の準備ができています。

リカバリBranchに「Inspect」が表示されたら：

1. 元のプライマリプロジェクトで、「 Branch 」ページを開いてください。
2. 停止前にセカンダリにレプリケートされなかったトランザクションを特定するために、リカバリBranchをクエリーします。リカバリBranchは通常のBranchであるため、他のBranchをクエリーするのと同じ方法でクエリーします。
3. データを手動で調整してください。データの分岐方法はお客様のみがご存じのため、LakebaseはリカバリーBranchを本番運用Branchに自動的にMergeしません。調整方法を参照してください。
4. 完了したらリカバリーBranchを削除してください。

リカバリBranchが自動的に削除されることはありません。Lakebaseは、ご自身でBranchを削除するまで分岐履歴を保持します。

調整方法

リカバリBranchには、フェイルオーバーの瞬間に元のプライマリに存在した時点のデータが、まだレプリケートされていないトランザクションを含めて保持されます。本番運用のBranchには、レプリケートされたデータとフェイルオーバー後に書き込まれたデータが保持されます。整合性調整とは、リカバリBranchにのみ存在するものを特定し、それらをどうするかを決定することです。

リカバリ Branch と本番運用 Branch は、それぞれ独自の Endpoint を持つ個別のデータベースであるため、それらをまたいでクエリーするのではなく、比較することになります。分岐したデータを見つけるいくつかの方法:

• 最新の行を確認します。 レプリケートされなかったトランザクションは停止前に書き込まれた最後のものであるため、不一致は最新の行に集中しています。テーブルに Timestamp 列がある場合、リカバリー Branch をクエリーして、フェールオーバー前の数分間に書き込まれた行を探します。
• ハイウォーターマークを比較します。 シーケンスまたは増分 ID を持つテーブルの場合、リカバリー Branch 上の最大値を本番運用 Branch と比較します。リカバリー Branch 上の高い値は、レプリケートされなかった行を示しています。
• 行数を比較します。 本番運用よりもリカバリBranchの方が多くの行を持つテーブルには、調査すべき未レプリケートの挿入があります。

不一致の行を特定したら、テーブルごとにそれらを調整する方法を決定します。不足している行を本番運用に再挿入するか、更新を再適用するか、または不要な変更を意図的に破棄します。

ディザスタリカバリを無効にする

プロジェクト管理者は、プライマリワークスペースのプライマリプロジェクトでディザスタリカバリを無効にします。これは、有効にした場所と同じ場所です。

1. プライマリワークスペースで、プロジェクトを開き、 設定 を選択してください。
2. Cross-Workspace Replication セクションで、 Disable replication を選択します。

無効にすると、レプリケーショングループが削除され、レプリケーションが停止します。その後は、プライマリワークスペース内のプロジェクトにのみアクセスが維持されます。セカンダリプロジェクトは、セカンダリワークスペースから削除されます。

追加のリソース

• ディザスタリカバリ — 概念、フェイルオーバー動作、未サポート事項
• 高可用性 — リージョン内での自動フェイルオーバー
• プロジェクトのアクセス許可を管理する — ディザスタリカバリを管理するために必要なCAN_MANAGE ACL