ボーダーレス Lakehouse は、カタログ メタデータのクロスリージョン レプリケーションと障害復旧をサポートしています。
この構成では、Cloud Storage のデュアルリージョン バケットまたはマルチリージョン バケットでバックアップされたカタログが必要です。
始める前に
-
BigLake API を有効にします。
API を有効にするために必要なロール
API を有効にするには、
serviceusage.services.enable権限が必要です。プロジェクトを作成した場合は、オーナーロール（roles/owner）を介してこの権限がすでに付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール（roles/serviceusage.serviceUsageAdmin）を介してこの権限を取得できます。ロールを付与する方法をご覧ください。
必要なロール
Lakehouse ランタイム カタログで Iceberg REST カタログ エンドポイントを使用するために必要な権限を取得するには、管理者に次の IAM ロールを付与するよう依頼してください。
-
カタログ ユーザー アクセス、ストレージ アクセス、カタログの認証情報ベンディング モードの管理などの管理タスクを実行します。
- プロジェクトに対する BigLake 管理者 （
roles/biglake.admin） - Cloud Storage バケットに対するストレージ管理者 （
roles/storage.admin）
- プロジェクトに対する BigLake 管理者 （
-
認証情報ベンディング モードでテーブルデータを読み取る: プロジェクトに対する BigLake 閲覧者 （
roles/biglake.viewer） -
認証情報ベンディング モードでテーブルデータを書き込む: プロジェクトに対する BigLake 編集者 （
roles/biglake.editor） -
非認証情報ベンディング モードでカタログ リソースとテーブルデータを読み取る:
- プロジェクトに対する BigLake 閲覧者 （
roles/biglake.viewer） - Cloud Storage バケットに対する Storage オブジェクト閲覧者 （
roles/storage.objectViewer）
- プロジェクトに対する BigLake 閲覧者 （
-
認証情報ベンディング モード以外でカタログ リソースを管理し、テーブルデータを書き込む:
- プロジェクトに対する BigLake 編集者 （
roles/biglake.editor） - Cloud Storage バケットに対する Storage オブジェクト ユーザー （
roles/storage.objectUser）
- プロジェクトに対する BigLake 編集者 （
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
レプリケーションと障害復旧のワークフロー
クロスリージョン レプリケーションと障害復旧を使用するには、次の一般的な手順を行います。
- レプリケーション ステータスを表示する: 現在のプライマリ リージョンとセカンダリ リージョンを特定して、フェイルオーバーのターゲット リージョンを決定します。
- 同期ステータスを確認する: プライマリ リージョンとセカンダリ リージョンの現在の状態を確認して、移行の準備ができていることを確認します。
- フェイルオーバー モードを選択する: ソフト フェイルオーバー（計画メンテナンスに最適）またはハード フェイルオーバー（緊急復旧に最適）のいずれかを選択します。
- フェイルオーバーを開始する: 選択したモードに対応するコマンドを実行して、プライマリ リージョンとセカンダリ リージョンを切り替えます。
フェイルオーバーの準備
現在のプライマリ リージョンを特定し、セカンダリ リージョンの同期ステータスを確認します。次に、フェイルオーバーを開始します。
レプリケーションのステータスを表示する
カタログが複製されるリージョンを確認するには、次の gcloud biglake iceberg catalogs describe コマンドを実行します。
gcloud biglake iceberg catalogs describe CATALOG_NAME
CATALOG_NAME は、カタログの名前に置き換えます。
同期ステータスを確認する
フェイルオーバーを開始する前に、gcloud biglake iceberg catalogs failover コマンドを使用して、セカンダリ レプリカの同期ステータスを確認します。
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--validate_only \
--primary-replica PRIMARY_REPLICA_REGION
次のように置き換えます。
CATALOG_NAME: カタログの名前。PRIMARY_REPLICA_REGION: 新しいプライマリ レプリカとして指定するリージョン。
フェイルオーバーを開始する
障害復旧機能では、メタストア レプリケーションを使用してプライマリ リージョンとセカンダリ リージョンを指定します。すべてのテーブル コミット メタデータはプライマリ リージョンから提供され、セカンダリ リージョンに複製されます。フェイルオーバー オペレーションを使用して、カタログのプライマリ リージョンとセカンダリ リージョンを切り替えることができます。
ソフト フェイルオーバー
ソフト フェイルオーバーを開始するには、次の gcloud biglake iceberg catalogs failover コマンドを実行します。
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--primary-replica PRIMARY_REPLICA_REGION
次のように置き換えます。
CATALOG_NAME: カタログの名前。PRIMARY_REPLICA_REGION: 新しいプライマリ レプリカとして指定するリージョン。
ハード フェイルオーバー
ハード フェイルオーバーを開始するには、次の gcloud biglake iceberg catalogs failover コマンドを実行します。
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--primary-replica PRIMARY_REPLICA_REGION \
--conditional-failover-replication-time=REPLICATION_TIMESTAMP
次のように置き換えます。
CATALOG_NAME: カタログの名前。PRIMARY_REPLICA_REGION: 新しいプライマリ レプリカとして指定するリージョン。REPLICATION_TIMESTAMP: レプリケーションのチェックポイントとして機能する RFC 3339 タイムスタンプ。レプリケーション プロセスでは、レプリカにこの時点までにコミットされたすべてのデータが含まれていることが確認されます。レプリカにこのタイムスタンプの前にコミットされたすべてのデータが含まれていない場合、コマンドは失敗します。レプリケーションの遅延に関係なくフェイルオーバー プロセスを強制的に実行するには、このタイムスタンプを過去の遠い日付に設定します。注: この機能がプレビュー版の期間中、REPLICATION_TIMESTAMP は Cloud Storage ファイルではなく、カタログ メタデータのみを追跡します。データ損失の下限を維持するには、Cloud Storage のデータの可用性と耐久性に関するドキュメントをご覧ください。