Lakebase ディザスタリカバリ (DR)
ディザスタリカバリはプライベートプレビュー中です。プライベートプレビュー中は、AWSでのみクロスリージョンレプリケーションで利用可能です。アカウントのディザスタリカバリを有効にするには、ワークスペース管理者からDatabricksアカウント担当者にご連絡いただくよう依頼してください。
プライベートプレビュー期間中、ディザスタリカバリは本番運用での使用は想定されていません。
Lakebase ディザスタリカバリ (DR) は、プロジェクトのデータを別のリージョンにあるセカンダリーワークスペースにレプリケートし、単一のコンピュート障害やアベイラビリティゾーン (AZ) 障害ではなく、停止を含むリージョン全体の障害から保護します。Lakebaseは現在、定期的なレプリケーションを提供しており、追加のコンピュートを実行することなく、データを別のリージョンに同期させます。定期モードは、リージョンレベルの停止から保護する必要があるが、リージョンが利用できないことにそれほど敏感ではないユースケース (例：RPOウィンドウが数分の範囲の場合) 向けです。セカンダリープロジェクトをプライマリーにするには、手動でフェイルオーバーをTriggerする必要がありますが、この動作のスクリプトを構築することもできます。
このページでは、Lakebase ディザスタリカバリの仕組みを説明します。これを有効にしてフェイルオーバーまたはフェイルバックをTriggerするには、ディザスタリカバリの管理を参照してください。
プライベートプレビュー中は、UIのプロジェクト設定からディザスタリカバリを管理します。ディザスタリカバリ APIs は利用できますが、変更される可能性があります。
ディザスタリカバリの仕組み
ディザスタリカバリは、プロジェクトのプライマリーワークスペースと別のリージョンにあるセカンダリーワークスペースをペアリングし、レプリケーショングループを形成します。Lakebaseは、コミットされたデータをプライマリーからセカンダリーに定期的にレプリケートします。セカンダリーのコンピュートはフェイルオーバーが発生するまでアイドル状態を維持するため、常時稼働のスタンバイに対して費用を支払うことはありません。レプリケーションはストレージレイヤーで行われるため、セカンダリーのコンピュートを実行して、レプリケートされたデータを受信する必要はありません。
Lakebaseは、セカンダリがプライマリからどれだけ遅れているかを示すレプリケーションラグ メトリクスを公開しています。ラグは、今すぐフェイルオーバーした場合に失われるデータ量を示し、計画されたフェイルバックの前に、レプリケーションが完全に追いついている（RPO=0）ことを確認する方法です。
ディザスタリカバリ対高可用性
ディザスタリカバリと高可用性は異なる障害ドメインから保護し、ほとんどの本番運用ワークロードは両方を使用します。高可用性は冗長なコンピュートを稼働させ続けるため、コンピュートまたは可用性ゾーンの障害によってデータベースがオフラインになることはありません。ディザスタリカバリは、データのレプリケートされたコピーを別のリージョンに保持するため、リージョン障害が発生した場合にLakebase運用を再開できます。
本番運用環境および重要なアプリケーション向けに、高可用性とディザスタリカバリを組み合わせることで、Lakebaseプロジェクト向けのより回復力のあるデプロイメントモデルを構築できます。
高可用性 | 災害復旧 | |
|---|---|---|
保護対象 | リージョン内でのコンピュートまたはアベイラビリティゾーンの障害。 | リージョン全体の障害（停止を含む）。 |
スコープ | 1つのリージョン内のアベイラビリティゾーン間 | リージョン全体で |
冗長なリソース | 他のゾーンですでに実行中のスタンバイ コンピュート インスタンス | セカンダリワークスペース内のレプリケートされたデータコピー。 |
スタンバイコンピュート。 | 常時稼働し、すぐに引き継ぐ準備ができています | 定期モード: フェイルオーバーまでアイドル状態のため、スタンバイコンピュートの料金はかかりません。 |
フェイルオーバー時のデータ損失 | なし (RPO = 0)、レプリケーションは同期型です | データはプライマリーリージョンに予約されています；リカバリーBranchを通じて後で調整されるまで、データは一貫性がない可能性があります。 |
トリガー | 自動 | 手動 (要件に基づいて自動化を選択できます) |
アプリケーションへの影響 | 同じ接続文字列に再接続します | 新しいプライマリーリージョンの接続文字列を使用して再接続します。 |
高可用性構成はレプリケーショングループの一部としてセカンダリープロジェクトにコピーされるため、フェイルオーバー後も高可用性は維持されます。新しいプライマリで再構成する必要はありません。
フェイルオーバーとフェイルバック。
フェイルオーバーは、書き込みをプライマリからセカンダリに切り替え、セカンダリを新しいプライマリに昇格させます。元のプライマリは書き込みの受け入れを停止します。各リージョンには独自のEndpointがあるため、新しいPrimaryの接続文字列は異なります。フェイルオーバー後、トラフィックを再開する前に、アプリケーションを更新して新しいPrimaryの接続文字列と新しい認証トークンを使用するようにしてください。
フェイルオーバーは常に手動です。レプリケーションが定期的に行われるため、セカンダリーのデータがプライマリーより遅れる可能性があり、常に最新のコミット済みトランザクションを保持しているとは限りません。そのため、それをプロモートすることはビジネス上の決定となります。すなわち、少し古いコピーでサービスを再開し、最近のトランザクションは、調整するまでリカバリBranchに繰り延べられることを受け入れることを選択するということです。Lakebaseはそのようなトレードオフをユーザーのために行いません。そのため、Lakebaseプロジェクト管理者があらゆるフェイルオーバーをTriggerします。
フェイルバックは、元のプライマリーリージョンが回復してセカンダリーとしてレプリケーショングループに再参加すると、同じフェイルオーバーメカニズムを逆方向に実行します。フェイルバック中にRPO=0を達成するには、まず現在のプライマリーで書き込みトラフィックを停止し、フェイルバックする前にレプリケーションが完全に追いつくようにします。
Recovery Branch
すべてのトランザクションがセカンダリにレプリケートされる前にリージョンが利用できなくなった場合、未レプリケートのトランザクションは保持されます。Lakebaseは、元のPrimary上で、分岐したタイムラインをリカバリーBranchとして保持します。リカバリーBranchは、分岐が検出されるまで隠れたままになり、フェイルバック後、元のPrimaryがオンラインに戻るとアクセスできるようになります。Lakebaseは通知を表示し、分岐したタイムラインを検査できます。データをいつ調整するかはユーザーが決定し、LakebaseがリカバリーBranchを自動的にMergeまたは削除することはありません。
リカバリBranchを検査して調整するには、リカバリBranchの検査と調整を参照してください。
サポートされていないこと
次の表は、プライベートプレビュー期間中に利用が制限されるか、まだ提供されていない機能と構成の一覧です。一部は今後のリリースで予定されており、その他はディザスタリカバリの範囲外です。
機能 | ステータス |
|---|---|
CLIとAPI | プレビュー APIs は利用可能ですが、プライベートプレビュー期間中は変更される可能性があります。 |
クロスリージョン読み取りレプリカ | まだ利用できません。セカンダリのコンピュートは定期モードでアイドル状態のままであり、フェイルオーバーが発生するまで読み取りを提供できません。 |
スイッチオーバー（RPO=0 の制御されたフェイルオーバー） | まだサポートされていません。制御されたフェイルオーバーを計画する必要があります。 |
グローバルEndpoint | まだサポートされていません。フェイルオーバー後、リージョンのEndpointへの接続を管理する必要があります。 |
同一リージョン、ワークスペース間のレプリケーション | サポートされていません。プライマリとセカンダリは異なるリージョンにある必要があります。 |
PrivateLink | まだサポートされていません。PrimaryワークスペースとSecondaryワークスペース間のレプリケーション トラフィックは、パブリックインターネットを介して転送され、転送中に暗号化されます。 |
フェイルオーバーでのLakehouse統合
同期テーブルとLakebase チェンジデータフィードパイプラインは、どちらもフェイルオーバー時に終了し、自動的に再開されません。フェイルオーバー後にそれらを手動で再構成します。それらが処理するデータは異なる動作をします。
- 同期テーブル (lakehouseからLakebaseへ)。同期されたデータはセカンダリプロジェクトにレプリケートされるため、フェイルオーバー後に新しいプライマリ上に存在します。パイプラインのみ再構成する必要があります。
- Lakebase チェンジデータフィード (Lakebaseからlakehouseへ)。Deltaデータはレプリケートされません。ディザスタリカバリがDeltaテーブルをレプリケートしないためです。
追加のリソース
- ディザスタリカバリを有効にしてフェイルオーバーをTriggerするには、ディザスタリカバリの管理をご覧ください。
- 高可用性によるリージョン内自動フェイルオーバー
- リカバリBranchが通常のBranchとどのように関連するかを理解するために、データベースBranchを参照してください。